Database and REST

Each project is a separate Postgres 17 database, not a schema in a shared one. You get an owner role for SQL and migrations, plus the anon, authenticated and service_role roles that the API uses.

Use the dashboard to work with it: the Table editor for rows, the SQL editor for queries and saved snippets, and the Database pages for tables, columns, indexes, functions, triggers and extensions.

Connect with psql

The project settings show a connection string. Reveal it, then connect with any Postgres client.

psql "postgresql://postgres:<password>@<db-host>:5432/<project>"

You can reset the database password from the same page.

Tables, views and functions in the exposed schemas (public by default) are served at /rest/v1. The API understands the PostgREST conventions that supabase-js uses, so you rarely call it by hand.

// filters, ordering and pagingconst { data } = await vulcbase  .from("orders")  .select("id, total, customer:customers(name, email)")   // embed a related table  .gte("total", 100)  .in("status", ["paid", "shipped"])  .order("created_at", { ascending: false })  .range(0, 24); // upsertawait vulcbase.from("profiles").upsert({ id: user.id, name: "Ana" }, { onConflict: "id" });

The same call with curl:

curl "$VULCBASE_URL/rest/v1/orders?select=id,total&total=gte.100&order=created_at.desc&limit=25" \  -H "apikey: $VULCBASE_ANON_KEY" \  -H "Authorization: Bearer $USER_ACCESS_TOKEN"

The API docs page in the dashboard lists every table and function of your project with ready-to-copy examples.

You can choose which schemas are exposed and the maximum number of rows per request in the project's API settings.

Write a Postgres function and call it with rpc(). Mark it security definer only when you understand what it exposes.

create function open_todos_count() returns bigintlanguage sql stable as $$  select count(*) from todos where not done;$$;

const { data } = await vulcbase.rpc("open_todos_count");

The API connects as the role in the request's JWT. Without a policy, a table with RLS enabled returns nothing to anon and authenticated. Add policies in the SQL editor or on the Policies page.

alter table profiles enable row level security; create policy "read own profile" on profiles for select to authenticated using (auth.uid() = id);create policy "update own profile" on profiles for update to authenticated using (auth.uid() = id);

The SQL editor can run a query as anon, authenticated (with claims you supply) or service_role, so you can test a policy before you rely on it.

Turn extensions on from Database, Extensions. Available extensions: vector, pg_trgm, unaccent, hstore, ltree, fuzzystrmatch, btree_gin, btree_gist, intarray, tablefunc, pg_stat_statements, isn, cube, earthdistance, uuid-ossp, pgcrypto and citext.

Schedule SQL with a cron expression from the Cron jobs page. Each job shows its next run and the last ten runs with their result.

-- schedule: 0 3 * * *delete from sessions where expires_at < now();

On the Webhooks page, choose a table and the events (insert, update, delete), then give a URL, method and optional headers. Vulcbase sends the change to your URL and keeps a list of recent deliveries with their status, so you can see what failed.

On paid plans a backup is taken every night and kept for 7 days (Pro) or 30 days (Team). You can also take a backup yourself at any time, and download any backup as a standard Postgres dump.

To restore, pick a backup on the Backups page and confirm. Vulcbase takes a safety backup of the current state first, so a restore can be undone.

The Logs page lists REST, auth, storage and realtime requests with method, path, status, duration and role, and can filter to errors. The usage view shows database size, storage, monthly active users and requests against your plan.