Supabase alternatives
Sorted by the reason you are leaving, because most reasons trace back to how row-level security was written, not the platform.
The verdict
For teams outgrowing Supabase, Neon fits when you want Postgres and nothing else, Firebase fits mobile-first realtime apps, and AWS-native fits compliance-heavy scale, but most teams unhappy with Supabase are misusing row-level security or Edge Functions and should fix that first.
We run Supabase in four production systems and have hit both edges hard. Supabase's own docs warn that a policy reading user metadata is unsafe, because a signed-in user can change that metadata. Edge Functions also cap CPU time at 2 seconds and memory at 256MB per request. That limit stays the same on every plan.
Neither of those is a reason to leave. They are reasons to write tested policies and put heavy work on a separate worker. The genuine reasons to leave are narrower, and this page ranks them by which one actually applies to you.
How we judged these
Verified
Supabase runs four client systems for us: Shift Link, Trading CoPilot, ExtraaJe and Lexpair. We also run Neon-backed Postgres in production for TrialTriage, and AWS-native Postgres (RDS) across most of our client fleet. Firebase is evaluation, not production experience. We have marked it that way rather than implying otherwise.
Options were included only if they are a genuine like-for-like replacement. Each is a managed backend or database a real product could be built on. None is a point tool that fixes one complaint alone.
- What carries over
- Whether the underlying data model is standard SQL or a proprietary shape you would have to redesign.
- Access control model
- Whether row-level rules live in the database or get rebuilt as application code.
- Compute ceiling
- What happens to a request that runs long or needs real memory.
- Exit cost
- What survives if you leave this platform too.
The field
| Platform | Best for | Data model | Row-level security | Self-host |
|---|---|---|---|---|
| Supabase (incumbent) | Postgres plus a backend, out of the box | Standard Postgres | Built in, database-enforced | Yes |
| Neon | Teams who want only the database | Standard Postgres | None; you write it | No (managed only) |
| Firebase | Mobile-first, realtime-heavy apps | Document store (Firestore) | Rules engine, not SQL | No |
| AWS-native (RDS + Cognito or similar) | Compliance-heavy scale | Standard Postgres | None built in; you assemble it | N/A, managed AWS |
Ranked, by why you are leaving
- 01
Neon ↗
Serverless Postgres, with branching, and nothing else
The right move when your team already owns a backend and Supabase's bundled auth, storage and realtime are unused weight. We run Neon-backed Postgres for TrialTriage, behind a NestJS API we wrote ourselves. Branching per environment is genuinely useful for a team with a real CI pipeline.
You give up database-enforced row-level security. Every access rule becomes application code your engineers must write and test, not a policy Postgres checks on every query.
Best for
- A backend team that will write and own its own auth and access logic
- Multiple environments that benefit from instant database branching
Not for
- Teams who want access rules enforced by the database rather than by an API route
- Anyone hoping to skip writing a backend
Fastest path for a mobile app with realtime sync
Choose it when the app is mobile-first, the data is naturally document-shaped, and offline sync matters more than relational queries. Firestore's client SDKs and Google's mobile tooling remove real setup work on day one.
The data model is the cost. Firestore is document-shaped, not relational, so a product that grows relationships between records fights the database instead of using SQL. Moving off Firebase later means redesigning the data model. Exporting rows is the easy part.
Best for
- Mobile apps needing offline-first sync
- Document-shaped data with few relationships
Not for
- Relational data that will grow joins over time
- Anyone who wants a SQL exit path
RDS, Cognito and the rest, assembled yourself
The answer when procurement or compliance says the workload must sit inside one AWS account, under AWS's own security tools. We run RDS Postgres this way across most of our client fleet where that rule applies.
Nothing is bundled. Auth, storage, realtime and row-level policy enforcement are each a separate service you wire together and maintain. Supabase's whole pitch is that this wiring is done for you, so moving here is trading convenience for control.
Best for
- A procurement or compliance requirement naming AWS specifically
- Workloads already living inside the same AWS account
Not for
- Teams who chose Supabase specifically to avoid assembling infrastructure
- Anyone without an engineer who owns AWS full time
What each move actually costs you
Effort, not money. What carries over, what gets rebuilt, and what you lose for good.
| Moving to | Carries over | Gets rebuilt | Lost for good |
|---|---|---|---|
| Neon | The schema, as a Postgres dump | Auth, storage, realtime, every access rule | Database-enforced row-level security |
| Firebase | The idea, not the schema | The entire data model, as documents | SQL joins and standard Postgres tooling |
| AWS-native | The schema, as a Postgres dump | Auth, storage, realtime, access enforcement, each as its own service | The bundled convenience Supabase was chosen for |
Supabase and Neon, both in production
Common questions
01What does migrating off Supabase actually cost?
The schema carries over as a standard Postgres dump. What gets rebuilt is auth, storage, realtime and every row-level policy, since none of those move with a database export. Expect to rewrite the access layer, not the data.
02Is Supabase vs Firebase the same question as Supabase vs Neon?
No. Firebase is a different data model entirely, document-shaped rather than relational, so that choice is about your data. Neon is the same Postgres underneath, so that choice is only about whether you want the bundled backend.
03Why is a raw self-hosted Postgres setup not on this list?
It answers a different question. Everything here is a managed platform a small team can run without owning database operations. Self-managing Postgres from scratch removes every convenience Supabase bundles, and the complaint was usually about one of them.
Related
- the full Supabase review, from four production systems →Where row-level security goes wrong, and where it holds up.
- Supabase vs Firebase →The relational-versus-document question, in full.
- hire Supabase developers →For teams staying and want the row-level security done right.
- building a SaaS MVP →Where a Postgres backend choice fits in a first build.
