Postgres, with the boring parts done
Supabase where a product needs a real relational database, auth and realtime without a platform team. It is Postgres underneath, which is why we are comfortable putting client data in it.
Three reasons we build on Supabase
Why Supabase
It gives a small team Postgres, auth, storage and realtime on day one, with no lock-in that matters — the data is standard Postgres and can leave. For heavily regulated workloads we build in your own cloud instead.
→Real Postgres: constraints, transactions, extensions→Row-level security enforced in the database→Auth, storage and realtime without extra services→Branching and migrations that fit a release process→An exit path, because it is standard PostgresSchema and security
We design the schema and the row-level security policies together — most Supabase incidents we are called about are policy mistakes, not database ones.
→Schema design with constraints that hold→Row-level security policies written and tested→Migrations in version control, applied in CI→Roles, keys and service boundaries documented→Backups and restore tested, not assumedProduct features on top
Realtime collaboration, file handling, edge functions and search — built as product features with the same review as the rest of the codebase.
→Realtime features with conflict behaviour defined→Edge functions for webhooks and integrations→Full-text and vector search in the same database→Analytics reads separated from transactional load→Observability on queries, not just uptimeBook a call→Data work you can audit
Schema, policies and migrations live in version control and are reviewed like application code. Nothing in production was applied by hand.
What we run alongside it
A short, deliberate list — each in production on a system we maintain. See the full partner stack.
Clients we work with
Supabase case studies
What we will not do
Supabase is not right for every data problem. These are the jobs we hand back.
$./data-review→