Supabase
A backend
A backend. Postgres, plus auth, storage, realtime, edge functions and row level security, wired together so a lot of apps need no server of their own at all.
Routiq Labs · one job, two tools
Supabase or Neon?
Wrong question.
One is a backend. The other is a database. Almost every “should I move to Neon” is really “do I still need the bundle”, and that has a different answer, a different cost, and a different day to ask it.
Written on production numbers, not benchmarks. No pricing on this page on purpose: it changes every quarter, the architecture doesn’t.
Part I — The short answer
They are not the same category
Comparing them like for like is the mistake. Read what each one actually is first, then the question answers itself.
You don't leave Supabase because Neon is faster. You leave when you stop needing the bundle and start needing the database.
Neon
A database
A database. Postgres, with storage and compute pulled apart so it can branch, autoscale and sleep. No auth, no storage, no realtime. It does one thing.
Part II — Side by side
Nine dimensions
The right-hand column is the one that matters. It says who each row actually favours, and why.
| Dimension | Supabase | Neon | The line |
|---|---|---|---|
| 01What you get | Postgres + auth + storage + realtime | Postgres | The whole comparison in one line. If you use two or more of the extras, this is not a database decision. |
| 02Auth | Built in, tied to RLS | Bring your own | The single biggest lock-in, and the one people forget when they estimate the move. |
| 03Authorisation | Row level security on the table | In your application code | RLS is genuinely hard to give up once your policies encode real rules. Rewriting them as app code is the migration. |
| 04Branching | Preview branches, heavier | Copy on write, near instant | Neon's actual party trick. A real database per pull request, with production-shaped data, that costs almost nothing. |
| 05Idle cost | Instance stays up | Scales to zero | Neon wins clearly for spiky, bursty or many-small-databases workloads. Irrelevant if you serve steady traffic. |
| 06Scaling compute | Resize the instance | Autoscales, storage separate from compute | The architectural difference underneath everything else on this list. |
| 07Storage / files | Included | Not its job | You'd add S3 or R2. Fine, but it is another service and another set of credentials. |
| 08Realtime | Included | Not its job | If you're pushing live updates to a UI, leaving Supabase means building or buying this. |
| 09The data itself | Postgres | Postgres | This is why people think the move is easy. The data is the easy part. It was never the data. |
Part III — The real bill
It was never the data
Both are Postgres, which is exactly why people underestimate this. Here is what actually has to move.
- 01
The data moves in an afternoon
Both are Postgres. It is a dump and a restore. This is the part everyone plans for.
- 02
The auth does not
Users, sessions, providers, password hashes, and every place your code assumed a Supabase session. This is the project.
- 03
The policies do not
Every RLS policy becomes application code. Each one is now a place you can leak another tenant's data by forgetting a where clause.
- 04
The client libraries do not
Every `supabase.from(...)` call becomes a query. Mechanical, tedious, and the exact kind of change that hides one bad filter.
Move, if
- +You already run your own auth, so the bundle is not doing anything for you.
- +You want a real database branch per preview deploy, with production-shaped data.
- +Your traffic is spiky or mostly idle, and paying for a sleeping instance annoys you.
- +You need many databases, one per tenant, and want them to cost nothing when quiet.
- +Your bottleneck is genuinely the database, and you have the query plans to prove it.
Stay, if
- ×You use Supabase auth. This is the whole migration, and it is not a database task.
- ×Your authorisation lives in RLS policies. Moving means rewriting them as application code, in a system where a mistake exposes other people's data.
- ×You use storage or realtime. Those become two more services to run.
- ×You are moving because of a benchmark you read rather than a query plan you have.
- ×Nothing is broken. This is the most common reason, and it is not a reason.
Part IV — The counter-example
Still on Supabase
The reason to move has not arrived here yet, and this is not a toy. These are live numbers from the Postgres behind the clinic apps, pulled the day this page was written.
147,458
patients
558,959
appointments
746,155
rows across the main tables
Real clinics, real bookings, patient messages going out every day. Still Supabase, because auth and RLS are doing more work here than a faster Postgres would. The day that stops being true is the day it is worth moving, and not before.
Keep going
This is one row of the table.
There are eight more.
Database is job one of nine. The same “rent it, own it, or outgrow it” question applies to the other eight, and the answer is usually the boring one.