Decision record // Data
Supabase or your own Postgres?
You are choosing between a managed platform that bundles Postgres with auth, storage, realtime and a generated API, and a plain Postgres instance you wire up yourself. The decision feels like it is about scale. At the stage where people ask it, it almost never is.
The call
Supabase, until something it genuinely cannot do forces your hand. Most teams leave years too early. The ones who get hurt are not the ones who stayed: they are the ones who never noticed that row-level security had quietly become their entire authorisation layer.
When each one is right
Supabase
- You are pre-revenue or pre-product-market-fit, and a week spent on infrastructure is a week not spent finding out whether anyone wants this.
- You want auth, file storage and realtime to arrive together rather than be integrated one at a time.
- Nobody on the team wants to be woken up by a database.
- Your access patterns are ordinary: a web app doing reads and writes with some joins.
Your own Postgres
- You have a contractual or regulatory requirement about where data physically lives that the available regions do not satisfy.
- You need an extension, a Postgres version, or tuning the platform does not expose.
- You are hitting connection limits a pooler cannot solve, which usually means serverless functions each opening their own connection.
- Your bill is meaningfully above managed Postgres plus the services you actually use, and you have done that arithmetic rather than assumed it.
What it costs you later
Not the migration. Postgres is Postgres and moving the data is a weekend. The cost is that on Supabase your row-level security policies are your authorisation layer, and they sit directly between the public internet and your tables. The anon key ships in your client bundle by design. If a policy is missing or subtly wrong, the table is readable by anyone who opens dev tools. This is the most common serious defect I find in quickly-built apps, and it is not a flaw in the platform: it is what happens when the security boundary moves somewhere people forget to look. Ask an agent for RLS policies and you will get plausible ones, which is not the same as correct, and the failure is silent because everything works in the demo where you are the only user who exists. Write one test that signs in as tenant B and tries to read tenant A's rows, and run it in CI. That single test is worth more than the entire decision above.
Decisions like this one, on your product
This page is a general answer. Yours has constraints I don't know about. The Founding Engineer is 8 weeks with 5 founders where we make these calls on your actual codebase, and your code gets reviewed every week.
New decision records as I write them
One question, one answer, no hedging. Leave your email and I'll send the new ones. No schedule promises, unsubscribe anytime.