Data · We run it ourselves
A relational database with real transactions: either every part of a change lands or none of it does.
Most of what a company calls a reporting problem is a modelling problem wearing a chart. If two systems can disagree about the same number, no dashboard above them will settle the argument.
01
Transactional integrity is not a feature to be added later. When money, stock and a booking have to agree, a database that can hold them in one atomic change is the difference between a bug and a reconciliation meeting.
02
Constraints belong in the schema rather than in whichever service remembered to check. A rule enforced in application code is a rule enforced until the next integration writes directly.
03
Row-level security puts the access rule next to the data it protects, so a new client of the same table cannot quietly widen it.
04
We run it under Supabase where a managed platform is the right trade, and under our own Prisma schema with versioned migrations where it is not. Both are Postgres, which keeps the exit open in either direction.
An entry that cannot point at something you can open, run or read does not compile. That is a property of the type, not a promise in a paragraph.
Invariant
This is the database in the engineering sense — schema, transactions, migrations, recovery from a backup or a replica. It is not data recovery from failed hardware: a dead disk or a broken RAID array is a laboratory job with a clean room, and when that is the actual problem the right answer is a recovery lab rather than us.