Disclaimer: Supabase is a great platform, with by far the largest ecosystem and community.
However, if you're looking to leave, the reasons usually come down to three things:
- The pricing gets non-linear at the exact moment a project starts working
- PostgREST doesn't scale gracefully to complex relational frontends
- You have requirements (self-hosting mandates, a reactive data model, compliance regimes, or AI agent workflows) that the platform doesn't model well
If none of that is your situation, stop reading.
What follows is Nhost, Neon, Appwrite, Convex, Firebase, PocketBase. Not Railway, not Render. Those are infra platforms and comparing them to Supabase doesn't make sense, like comparing a toolbox to a hammer.
Nhost
Nhost is, structurally, very similar to Supabase: Postgres, auth, storage, serverless functions. The difference is the API layer. GraphQL instead of PostgREST, powered by Constellation, their own open-source GraphQL engine written in Go.
If you have a dashboard that needs data from six related tables, a GraphQL query gives you exactly that in one round trip. PostgREST gives you a series of choices: chain multiple requests, write RPC functions that fake the join, or start questioning your data model. It gets unwieldy fast.
The permission system compounds this: role-based row and column access is defined inside the query engine itself, so you're not maintaining separate RLS policies in SQL that drift from your actual auth logic.
Nhost fits naturally for AI agent workflows. Agents touching shared Postgres state get real-time updates via subscriptions, and the permission model means no separate access control layer bolted around your database calls.
Neon
Neon is not a full Supabase replacement. It's a database. That's it. No auth, no storage, no functions, no realtime. If you pick Neon, you're assembling the rest of the backend yourself.
Why would you do that? Because what Neon actually built is genuinely impressive: they separated compute from storage at the Postgres level, which makes database branching possible. A full copy-on-write snapshot of your database in seconds. One branch per pull request, against real data, gone when the PR closes. Databricks acquired them last year and it's continued to develop. It's become the thing other providers benchmark against.
Neon is a good fit if the database itself is your unsolved problem and the rest of your infrastructure is already handled: platforms provisioning a database per customer, CI pipelines that need isolated environments per test suite, teams with existing auth that just want better Postgres without ripping everything else out.
Appwrite
The thing Appwrite does well, genuinely well in a way the other platforms kind of half-ass, is self-hosting. One docker-compose command and you have a full working stack. Not "full working stack but you need to configure eight more things." Actually full, actually working.
This matters more than people give it credit for. Air-gapped environments, healthcare compliance, regions where AWS and GCP are politically complicated, enterprise contracts with data residency clauses that say the words "within the EU" in boldface. Appwrite handles all of this without treating self-hosting as a community project that the founders are vaguely embarrassed by.
Here's the catch, and it's a real one: Appwrite is not Postgres. The data layer is its own collection and document model. Which means no SQL, no pg_dump, no EXPLAIN ANALYZE when a query gets slow, no connecting a BI tool to it. One of the quiet reasons Postgres-backed platforms feel safe is that the escape hatches are all there if you need them. Appwrite closes most of them.
If your team thinks in SQL, you'll notice this within the first week. There's no workaround for it.
If you're building something mobile-first, especially on Flutter, Appwrite's Flutter SDK is one of the best in this space and the SQL thing might genuinely not matter. Different problem, different tradeoffs.
Convex
Almost every comparison article gets Convex wrong, usually by fitting it into a row in a feature table next to Firebase and calling it a document database alternative. It's not that.
The actual model: your backend is TypeScript functions. The data layer is document-relational. The important part, the part that sounds like a detail but isn't, is that queries are reactive subscriptions by default. When data changes, every subscribed client updates. Automatically. Without you writing cache invalidation logic. Without you managing subscription channels. Without you thinking about whether two parts of the UI are looking at stale data from the same table.
End-to-end TypeScript from the schema to the React component means the types aren't generated artifacts you have to remember to regenerate. They're the same code.
When does this matter? Collaborative editors. Live multiplayer state. AI agent applications where multiple processes are writing to shared state concurrently and the UI has to reflect it immediately. Convex makes a whole class of synchronization bugs structurally impossible. Not hard to write — the runtime doesn't let them exist.
When does it not matter? Analytical stuff. Reporting. Anything that needs direct SQL access. Convex's document model won't bend to accommodate an ad-hoc GROUP BY.
The learning curve is also real: the first two weeks are genuinely disorienting. The mental model is different enough from "database + API" that your existing instincts are wrong in subtle ways. Developers who get through that describe the next few months as feeling like they have superpowers. I believe both descriptions. Whether the trade is worth it depends on whether realtime consistency is your actual hard problem.
Firebase
Hard to imagine cases when people move from Supabase to Firebase, but I can't skip this.
If you outgrow Supabase or Nhost and need to leave, your data is Postgres. You run pg_dump, you load it somewhere else, you update your connection strings. It's a project, not a crisis.
If you outgrow Firestore, you're transforming a data model, not migrating rows. The access patterns you built around Firestore's model (the denormalization, the collection structure, the places where you stuffed data into subcollections to avoid a join) don't translate. It's months of work under pressure, usually when the thing that forced the move isn't waiting for you.
That's not a dealbreaker for the right use cases. Offline-first mobile sync where the app needs to work through genuinely unreliable networks and reconcile cleanly when connectivity returns: Firebase is still the best answer here, and it's not close. Simple read-heavy access patterns at scale without relational complexity. Google ecosystem products where auth, analytics, and ML are already in Cloud.
PocketBase
I'll just say it: PocketBase is one of my favorite pieces of software that exists right now.
It's one Go binary. SQLite, realtime subscriptions, auth, file storage, admin UI. Runs on a $5 VPS. ~60k GitHub stars. One maintainer.
That last part is both the appeal and the risk. The total system fits in one person's head, which means deployment is copying a file, the admin UI is actually good, and there are no abstractions hiding from you. For internal tools, admin panels, side projects, prototypes, hobby things that are more complex than a static site: PocketBase is more elegantly suited to these than anything else on this list by a significant margin.
The ceiling is real too. SQLite means single node. There's no path to horizontal scaling, no managed hosting tier for when self-managing gets annoying. There was a meaningful auth-bypass CVE earlier this year, patched quickly and responsibly disclosed, handled well by the maintainer. But "handled well by a single person" is a different risk profile than "handled by a security team at a funded company," and that's a real input to a production decision depending on what you're building.
The failure mode I've watched happen: someone uses PocketBase as a placeholder while the project proves out, then migrates to something "real" after it does. That migration always happens under deadline, always takes longer than anyone estimated, and is always more painful than if they'd made the decision upfront. Better to either commit to it for what it actually is (a complete backend for things that fit on one node, which is honestly a bigger category than people admit) or pick something else from the start.
So How Do You Actually Pick
Start with the data model. This is the decision that matters most and people skip over it to compare pricing tiers instead.
If you need GraphQL, a strong permission layer, or your backend will serve AI agents: Nhost. If you want the most mature REST-based Postgres BaaS with the largest ecosystem: go back to Supabase. If the database is your only unsolved problem and everything else is handled: Neon.
Document-shaped data with stable, simple access patterns: Firebase or Appwrite.
Then self-hosting. If it's a hard requirement, not a nice-to-have: Appwrite or PocketBase. Self-hosted Supabase exists but the full service stack is a real ops commitment. Not a one-afternoon project.
Then realtime. If live synchronization is the core mechanic of what you're building and not just a feature checkbox, actually evaluate Convex. Don't just put it in the table and move on.
Before you commit to anything: run your actual schema through the top two options. Real tables, real auth flow, real queries from the app. Not a tutorial, not a hello world. The places where something breaks or needs a workaround are the information you need, and you won't get it from any comparison article including this one.
Top comments (1)
Great comparison. One thing I’d add is that the choice isn’t only about features anymore. It’s also about operational ownership and exit strategy.
A few platforms that might be worth mentioning:
I’d also add a separate category for “AI-native backends.” The requirements of agent-based systems (memory, event streams, shared state, vector search, tool execution, auditability) are starting to diverge from traditional CRUD applications. The backend choice increasingly depends on whether you’re building software for users, agents, or both.