Supabase Alternatives: Pick the Shape First, Then the Product

There are three genuinely different answers to what do I use instead of Supabase: another bundled backend-as-a-service, a managed database plus your own backend, or a single-binary backend you run yourself. The products only matter once you have picked one of those.

Comparison articles list the same names in a slightly different order and rarely say what would make you choose differently. That is because the products inside a category are close substitutes — the interesting decision happens one level up, at the shape of the thing.

So: three shapes, what each is good at, what it costs you, and which products live in each.

Shape one: another bundled backend-as-a-service
Shape two: a managed database plus a backend you write
Shape three: run the whole thing yourself
A decision path that fits in a paragraph
How this fits the rest of the stack
FAQ

Shape one: another bundled backend-as-a-service

You want the same deal — database, auth, storage, generated API, realtime — from a different provider. Reasons include pricing, a free tier that fits better, self-hosting support, or a data model that suits you more.

The main options, and the actual distinctions between them:

Firebase. The oldest and the most complete for mobile. Document-oriented rather than relational, tight SDK integration for iOS and Android, and an offline story nothing else matches. The trade is a query model that fights you as relationships grow, and pricing that scales with reads.
Appwrite. Open source, self-hostable as a Docker Compose stack, with a broad SDK ecosystem across languages. Closest in spirit to Supabase, with its own database rather than plain Postgres.
PocketBase. A single Go binary with SQLite embedded. Genuinely one file. Astonishingly simple to deploy and to reason about, and the simplicity is real rather than marketing. The limits are equally real: one process, one file, and SQLite’s write concurrency.
Convex. A reactive backend where queries update automatically and functions are the unit of logic rather than SQL. A different mental model, open-sourced with self-hosting support added later.
Neon. Serverless Postgres with branching, which is a database rather than a bundle — it belongs here only because people reach for it as a replacement for the Postgres half.

What you keep with any of these: speed to a working prototype. What you keep with all of them: a schema-driven API, and business logic that has to live in database policies, edge functions, or the client.

Shape two: a managed database plus a backend you write

This is the unbundled option, and it is the one the lists usually skip because it does not have a logo. You run a managed Postgres or MySQL, and you write an API in whatever language your team already uses.

What you give up is real, and worth naming: a generated CRUD API, a drop-in auth service, and a storage service with signed URLs. Those are days of work you now do yourself, and for a prototype that is a genuinely bad trade.

What you get back:

Business logic in ordinary code. Testable with your normal test runner, reviewable in a normal pull request, debuggable with a normal debugger. Row-level security policies are powerful and they are not any of those things.
Transactions across operations. A multi-step operation that must succeed or fail as a unit is a transaction in a backend and a puzzle in a policy layer.
Third-party keys that never reach a browser. The backend holds them and makes the calls.
No generated API surface you did not design. A schema-derived API exposes your table structure as your public contract, which couples your storage layout to your clients permanently.
Portability. Postgres is Postgres. Your backend is your code. There is no proprietary layer to reimplement.

The point at which this becomes the better trade is fairly predictable: when authorisation stops being users can read their own rows and starts involving roles, teams, ownership transfer, or anything a colleague has to reason about.

Auth specifically no longer requires building from scratch. Dedicated identity providers handle the hard parts — sessions, MFA, social login, token rotation — and integrate with any backend, so the choice is not between a bundle and writing password hashing yourself.

Shape three: run the whole thing yourself

Postgres in a container, your API beside it, object storage somewhere, and an identity provider or a library for auth.

This is the right answer less often than its advocates suggest, and more often than the bundled-service articles admit. It is correct when data residency demands it, when you already operate databases in production competently, or when your requirements are specific enough that every bundle is a fight.

It is the wrong answer when the honest driver is avoiding a subscription. The subscription is not the expensive part — backups you have tested, monitoring that wakes someone, upgrades rehearsed on staging, and certificate renewal that does not lapse are the expensive part, and they cost the same whether or not you enjoy them.

The middle position, which suits a lot of teams: a managed database, because that is the piece where operational mistakes are permanent, and your own code for everything above it, because that is the piece where you want control.

A decision path that fits in a paragraph

Prototype, deadline this week, logic is mostly CRUD. Stay on a bundle. Any of them. The differences are smaller than the time you would spend comparing.
Mobile-first with offline sync as a requirement. Firebase, honestly. Nothing else has that story.
You want open source and self-hosting, and you like the bundled model. Appwrite, or PocketBase if your scale genuinely fits one process and one file.
Substantial business logic, multi-tenant authorisation, or workflows with state. Managed Postgres plus your own backend. The bundle will fight you.
Regulatory or residency constraints. Self-hosted, and budget the operations honestly.
You are here because of a surprise bill. Diagnose before migrating. Unbounded reads, missing indexes and a chatty client cost the same on every platform, and a migration that carries the same access pattern carries the same bill.

That last one is the most common reason people start reading these lists and the least likely to be solved by the list.

How this fits the rest of the stack

The through-line is that the database is the part you should be most careful about and the part that travels best. Postgres tables move; a generated API layer and an auth service do not. So the decision that compounds is where your logic lives, not which dashboard you log into.

RunxBuild is built for the unbundled shape. Managed MySQL and Postgres come with backups, user management, connection limits and private networking, and a web service in Node, Next.js, Python, Go, Ruby, Java, .NET or Docker deploys from the same GitHub repository beside the database — with environment variables, persistent storage, build and runtime logs in one place, rollback to the previous deploy, and autoscaling between plan bounds you set. Your authorisation logic is code you can test rather than policies you hope are right. To see what a service, a managed database and storage add up to before committing, the RunxBuild hosting calculator puts each on its own line.

Useful related references:

FAQ

What is the closest open-source alternative to Supabase?

Appwrite is the nearest in spirit — open source, self-hostable as a Docker Compose stack, with database, auth, storage and functions bundled and a broad SDK ecosystem. PocketBase is a different kind of answer: a single Go binary with embedded SQLite, far simpler to run, with the concurrency limits that implies.

Should I use Firebase instead?

If the product is mobile-first and needs offline sync, yes — nothing else matches that. The trade is a document model that gets awkward as relationships grow, and pricing tied to read volume. For a relational, web-first application, a Postgres-based option usually fits better.

Is it worth building my own backend instead of using a BaaS?

It depends on where your complexity is. If the application is mostly CRUD with per-user access rules, a bundle is faster and the generated API is a genuine saving. Once authorisation involves roles, teams or ownership transfer, or you need transactions across several operations, ordinary backend code is easier to test, review and debug than a policy layer.

Can I migrate my data off Supabase?

The database, yes — it is standard Postgres, so a dump and restore moves it anywhere Postgres runs. What does not travel is the generated REST layer, the auth service and the storage service. Plan for rewriting those against your own backend or a replacement provider rather than expecting a lift-and-shift.

I am switching because of a surprise bill. Will another platform fix it?

Probably not on its own. Unbounded queries, missing indexes and a client that fetches more than it needs cost roughly the same everywhere. Diagnose the access pattern first — if you migrate the same behaviour to a new platform, you generally migrate the bill with it.