Database
Every project is a real Postgres database. This page in the portal — and in these docs — is specifically the schema catalog: a view-only browser over Tables, Functions, Triggers, Indexes, Enumerated Types, Extensions, Policies, and Roles. It's for seeing what already exists, not authoring — create or change any of it through SQL Editor or a migration.
The database is the part of a stack you are least likely to replace and most likely to regret choosing badly, so shovelbase doesn't put a proprietary data layer in front of it. A project is an ordinary Postgres instance: your schema is standard SQL, your queries are standard SQL, and the things Postgres is good at — joins, transactions, constraints, JSON columns, full-text search, extensions — are all available rather than approximated.
That has two practical consequences. Existing knowledge and tooling transfer directly: psql, a GUI client, an ORM, and any Postgres tutorial on the internet all work unchanged. And it is a genuine exit — the direct connection string plus pg_dump gives you a portable database, not an export in someone's bespoke format.
It also means the platform's other features are Postgres features: permissions are row-level security, the REST API is a reflection of your schema, and auth.uid() is a function you can call in a default or a check constraint.
| Catalog page | What it lists |
|---|---|
| Tables | Every table in every schema, with row estimates |
| Functions | Postgres functions (not edge functions — see Functions in Platform) |
| Triggers | Triggers attached to tables |
| Indexes | Indexes, including the ones RLS and foreign keys rely on |
| Enumerated Types | enum types defined in the schema |
| Extensions | Installed Postgres extensions |
| Policies | RLS policies — see Permissions for how to write them |
| Roles | Database roles, including anon/authenticated/service_role |
| Surface | Availability |
|---|---|
| Portal UI | View-only catalog across all eight categories above |
| CLI | None — introspect with psql (below) or Postgres' own information_schema |
| SDK / HTTP | Not applicable — this is schema introspection, not app data |
Direct connection
Project Settings → Database shows a Postgres connection string, database name, and user — full owner access, no RLS applied. It's meant for one-off inspection with psql or a GUI client, not for app traffic (which should go through the REST API and anon/service keys so RLS and connection pooling both apply). See Table Editor for the psql command.
Backups
Also on Project Settings → Database: a pg_dump runs automatically every night at 03:00 UTC, and the three most recent dumps are kept. Back up now takes one on demand. Restoring rebuilds the project's database from a chosen backup and briefly restarts its services — other projects are unaffected. There's no CLI or SDK surface for backups; it's a portal (and, underneath, an ops-scheduled) operation only.
Three things worth planning around:
- One dump per day. Backups are stored under the date they were taken, so Back up now replaces the dump already taken today rather than adding a fourth. Reaching for it after noticing a mistake can therefore overwrite the good copy from that morning — if something has gone wrong, restore first, and take manual backups before destructive work (a big migration, a bulk delete), not after.
- Roughly three days of history. Only the three most recent daily dumps are kept, so a problem you don't notice until Thursday may have no clean Monday to go back to.
- Whole-database granularity. A restore rewinds everything to that dump's moment — it can't recover one bad table while keeping the rest current.
If you need longer retention or finer recovery, take your own pg_dump over the direct connection on your own schedule and keep it wherever you keep backups.