Cinch is in public alpha.
Compliance & Data Residency
A regulator asks "where is customer X's data?" You need a better answer than "somewhere in a shared Postgres cluster." With Cinch, it's a single, identifiable database you can point to.
Physical isolation, not policy isolation
Row-level security policies are three pages of SQL that your auditor has to verify, your team has to maintain, and your new hire has to understand before they can safely write a query. One missing WHERE clause and you have a data breach.
Per-tenant databases remove the whole category of problem. Each customer's data is physically separate. You can locate it, export it, move it, or delete it independently, without touching anyone else's data.
Compliance ops become database ops
Delete the database. Not "mark rows as deleted." Not "run a retention policy." The data is gone. Verifiably.
Download the customer's database. No custom ETL script. No filtering rows from shared tables. It's already isolated.
Per-database access logs. Know exactly who accessed which customer's data and when. No log filtering required.
Store a customer's database in the required region. Regulations change? Move it. No cross-region replication setup.
What your auditor wants to hear
"Each customer's data is stored in a physically separate database. There are no shared tables. Access control is at the database level, not the row level. Deletion means complete removal of the database — not a soft-delete flag. We can produce a data export for any customer by downloading their database."
That's the whole answer. No footnotes about eventually-consistent deletion pipelines or RLS policy coverage gaps.
Compliance built into the architecture
Per-tenant databases with physical isolation and verifiable deletion.
GET STARTED →