Product

Databases

Every Stackap project can have its own private Postgres database and its own database role, which can reach that database and nothing else.

What it does

Provisioning a database is one API call on a project. It creates a database and a login role for that project alone. The role has no superuser rights, cannot create roles or databases, and can connect only to its own database, which was checked with a cross-database test matrix that tried every project's role against every other project's database.

The connection string is never returned by the API and never shown in the dashboard. It is injected into the app's container as DATABASE_URL when the container starts, and it is stored encrypted like any other secret.

Two things sit on top of the database. A Supabase-compatible data API, served by PostgREST, lets code written against the standard JavaScript client read and write the same tables over HTTP. A table browser in the dashboard lets the project's owner look at tables, page through rows, sort and search, and insert or delete rows.

How it works

The table browser connects as the project's own role, not as an administrator, so it can only see what the app itself could see. Only the owner can write. Every browser write is recorded in the audit log with the column names that changed and never the values.

The data API has been set up and exercised for one project, a real Next.js site, against the kinds of queries a large production codebase makes. Its data was copied across from a Supabase database, 43 tables and about 25,000 rows, with the row counts compared table by table.

Backups are taken from a single consistent snapshot, encrypted, and restore-verified. See backups.
Restores go into a new database, never over the live one.
Each project's database lives in the same Postgres server on the same machine as the apps.

In practice

POST /v1/projects/my-app/database     # provision (once)
GET  /v1/projects/my-app/database      # name and status, never credentials

Early-access scope

The CLI has no database commands yet. The db command is a placeholder, and provisioning is an HTTP call.
All databases share one Postgres server and the machine's memory with every app on it. There is no read replica and no separate database server yet.
No point-in-time recovery. Backups are daily, so a disaster can cost up to a day of data.
The Supabase-compatible data API is set up by the operator and has been run for one project. It does not include sign-in, realtime or serverless functions.
Which Postgres extensions are available has not been documented or tested, so do not assume the ones a hosted product offers.
Moving a database in copies tables and rows only. Functions, triggers and views have to be carried over separately.

Questions

Can I connect with psql?

The database listens on the machine's local and internal networks only; its port is closed to the internet. Reaching it from outside means going through the dashboard's table browser or the data API, or through an SSH tunnel arranged by the operator.

Is it the same as Supabase?

It is the same Postgres and the same data-API engine for the parts it covers. See Supabase vs Stackap for what is missing.

Stackap is in early access. Tell us what you run and we will reply with a straight answer about whether it fits.

Ask for an invitation

Last updated 2026-10-03.