Qavren DB
One Postgres, a schema and a login role per app, and Postgres grants as the wall between them.
A dozen products meant a dozen managed Postgres projects, a dozen bills, and a dozen sets of credentials to rotate. Consolidating them is easy. Consolidating them without letting one app read another's data is the actual work.
What it is
Qavren DB is one Postgres for every Qavren app. A single hosted Supabase Pro project replaces the per-app project sprawl. This repo owns the parts that matter: schema-per-app provisioning as code, hard grant-level isolation, backups, and the migration playbook.
The companion piece is Qavren Auth, which owns identity. This one owns data.
What it does well
Postgres privileges are the wall, not RLS. One schema and one login role per app. The role owns its schema and holds zero grants anywhere else. Isolation doesn't depend on every query carrying the right policy context — it depends on the app's credentials being unable to name another app's tables.
Pure Postgres surface. No Supabase Auth, no exposed schemas, no anon keys, no PostgREST, Realtime, Storage, or Edge Functions. The attack surface is a database port.
Two connection paths, on purpose. Runtime traffic goes through the transaction pooler; migrations and DDL run in session mode as the app's own role, from the app's own repo. Nothing centralizes schema ownership away from the team that owns the schema.
A new tenant in about a minute. One provisioning command creates the schema and role, prints the connection string and generated password exactly once, and is a no-op on re-run. The manifest gets committed; the password never does.
Isolation that's tested, not asserted. A Pester suite covers isolation, lockdown, idempotency, and validation — the whole point of the design is the part that gets verified.
Backups in two layers. Supabase's daily backups plus a nightly per-schema pg_dump to Cloudflare R2, covering both the production and test projects.
What runs on it
TrailTold, Synap, Kairis, and the apps being migrated behind them, across prod, test, and local environments. ReCharacter is planned. Each arrives as a committed manifest.
What it looks like in practice
A new product needs a database. Two commands provision its schema and role in the test and prod projects. The generated password goes straight into that repo's GitHub secrets. The app connects through the pooler at runtime and runs its own migrations in session mode. If that app's credentials are ever leaked, the blast radius is one schema, because Postgres itself will not let those credentials reach anything else.
What it's not
It's not multi-tenancy within an app. This is isolation between Qavren apps; how each app separates its own users is that app's problem.
It's not a hosted service anyone else uses.
Status
In production, with a repurposed legacy project enrolled as the dedicated test target and both projects covered by nightly per-schema backups to R2. Migration of existing apps is ongoing — TrailTold is enrolled, Kairis has been made schema-agnostic, Synap has cut over from its own sidecar Postgres. Tech: Supabase Pro (Postgres 17, pgvector) + Supavisor pooling + PowerShell provisioning tooling + Pester.