all posts

The best Supabase alternatives in 2026

Ajay Kumar··9 min read

The reason a Supabase migration goes badly is that people plan it as a database move. It isn't. Supabase is Postgres plus auth, plus object storage, plus realtime, plus auto-generated APIs, plus edge functions — and your app is probably using at least three of them without a clear boundary between them.

So the useful framing is: which pieces do you actually need to replace, and can you replace them one at a time? Usually yes, and that's a much better plan. I build PandaStack, which is relevant to the database and compute pieces only — I'll keep it to those.

Start by working out what you use

  • The database — plain Postgres. The easiest piece to move, because it's standard.
  • Auth — users, sessions, OAuth providers, and JWTs whose claims your row-level security policies read.
  • Row-level security — policies written against the JWT that Supabase Auth issues. This is the tightest coupling in the whole product.
  • PostgREST — the auto-generated REST API your client calls directly from the browser.
  • Storage — object storage with access rules, again tied to auth.
  • Realtime — Postgres change subscriptions pushed over WebSockets.
  • Edge functions — Deno functions for server-side logic.
Row-level security plus a client that queries the database directly is the coupling that makes migrations hard. If your browser talks to PostgREST and your security lives in RLS policies reading auth.uid(), then replacing auth means rewriting your security model and your data-access layer simultaneously. Plan that as its own project, not a step in a migration.

Replacing the database

This part is genuinely easy, because it's ordinary Postgres. Neon if you want branching and scale-to-zero compute. RDS or Aurora if you want the boring, dependable, extremely well-understood option. Crunchy or Timescale if you want Postgres specialists. A per-database microVM platform — mine included — if you need control over extensions or hard isolation between tenants' data.

Two things to check before you dump anything: extension parity, since Supabase enables a broad set including pgvector and pg_cron that not every destination has, and the auth schema. Supabase keeps its users in an `auth` schema inside your database, so a plain dump brings user records with it — useful if you're keeping the data, and something to handle deliberately if you're not.

Replacing auth

This is the piece with real switching cost, because you're moving password hashes, sessions, and identity links to OAuth providers. Options: Auth0, Clerk, WorkOS, Keycloak, Ory, or your own implementation on top of a library.

The sequencing that works: run both systems in parallel, issue tokens from the new provider while continuing to accept old ones, migrate password hashes if the new provider supports your hash format (most support bcrypt), and expire the old sessions gradually. A hard cutover logs everyone out simultaneously, which is a support incident and an unnecessary one.

Replacing row-level security and PostgREST

If you're keeping direct-from-browser database access, you keep RLS and you need your new auth provider to issue JWTs your policies can read — signed with a key Postgres trusts, containing the same claims. That's doable and fiddly.

The alternative, which many teams choose during this migration, is to put an API layer in front of the database and move authorisation into it. That's more code and a much more conventional architecture: your server holds the credentials, your policies are application code you can test, and the browser never talks to Postgres. If you were already finding RLS policies hard to reason about, this migration is a reasonable moment to make that change — just don't pretend it's a small one.

# The database half is standard Postgres work
pg_dump --no-owner --no-acl \
  --schema=public \
  "$SUPABASE_URL" > public.sql

# Check what you depend on before restoring anywhere
psql "$SUPABASE_URL" -c "SELECT extname, extversion FROM pg_extension ORDER BY 1;"

# Restore into the new database, then verify row counts table by table
psql "$NEW_DATABASE_URL" < public.sql

Storage, realtime, and functions

  • Storage: any S3-compatible object store, with signed URLs replacing Supabase's access rules. Straightforward, but audit which paths were public — this is where accidental exposure happens during a migration.
  • Realtime: either a hosted realtime service, or your own WebSocket server consuming Postgres logical replication. The second is more work than it sounds, mostly around reconnection and replay.
  • Edge functions: any serverless platform, or a long-lived server if the functions were never function-shaped. Deno-specific APIs need translating.

What about self-hosting Supabase?

It's open source and it runs. The honest caveat: self-hosted Supabase is a stack of services — Postgres, GoTrue, PostgREST, Realtime, Storage, Kong — and you now operate all of them, including upgrades where the pieces must stay compatible. Teams do this successfully for data-residency requirements. Doing it purely to save money frequently costs more in engineering time than the bill did.

The short version

Don't migrate Supabase. Migrate one product at a time, database first because it's ordinary Postgres and lowest risk, auth second and in parallel rather than as a cutover, and treat RLS-plus-direct-client-access as its own architectural decision rather than a migration step. If all you actually wanted was Postgres without the rest, the database move on its own is a weekend, and you can leave everything else where it is while you decide.

Frequently asked questions

Is migrating off Supabase hard?

The database part is easy and the rest is not, which is why migrations go wrong when planned as a single move. Postgres is standard, so a dump and restore into any other provider is ordinary work. Auth, row-level security, PostgREST, storage rules, and realtime are separate products with real switching costs, and they are coupled — your RLS policies read claims from the JWT that Supabase Auth issues, so replacing auth means touching your security model at the same time. Replace one product at a time, starting with the database, and the whole thing becomes a series of small changes rather than one large risky one.

What can replace Supabase Auth?

Auth0, Clerk, WorkOS, Keycloak, and Ory all cover the same ground, as does a self-built implementation on a well-maintained library if your needs are simple. The migration technique matters more than the choice: run both systems in parallel, issue tokens from the new provider while still accepting existing ones, import password hashes if the new provider supports your format — most support bcrypt — and let old sessions expire naturally instead of cutting them off. A hard switch logs every user out at once, which turns a technical migration into a support incident for no benefit.

Should I keep row-level security if I leave Supabase?

Only if you are keeping direct-from-browser database access. RLS exists in that architecture because the client talks to Postgres and the database must therefore enforce authorisation itself. If you keep it, your new auth provider has to issue JWTs signed with a key Postgres trusts and carrying the same claims your policies read — doable, fiddly, and worth prototyping before you commit. Many teams use the migration as the moment to put an API layer in front instead, moving authorisation into testable application code and keeping credentials on the server. That is a better long-term architecture for most products and a genuinely larger project, so scope it honestly.

Is self-hosting Supabase a good idea?

For data residency or regulatory requirements, yes — it is open source and it works. For saving money, usually not. Self-hosted Supabase is not one service but a stack of them: Postgres, GoTrue for auth, PostgREST, Realtime, Storage, and a gateway, all of which you now operate and upgrade in compatible combinations. Teams that do this well treat it as owning a platform, with someone responsible for it. Teams that do it to cut a bill typically discover the engineering time exceeds what they were paying, and end up either back on the hosted version or on a smaller set of unbundled services.

What is the simplest Supabase alternative if I only want Postgres?

Any managed Postgres provider, and the choice comes down to which property you care about. Neon for branching and scale-to-zero compute. RDS or Aurora for the well-trodden, operationally mature option. Crunchy or Timescale for Postgres specialists with generous extension support. A per-database microVM platform if you need extensions outside the usual allowlist or hard isolation between tenants. Before dumping, check extension parity — Supabase enables a broad set including pgvector and pg_cron that not every destination offers — and decide deliberately what to do with the auth schema, which a plain dump will carry along with everything else.

Keep reading

Run code in a microVM in one API call.

49ms p50 cold start. Fork, snapshot, and scale to zero.

Start free
Written by Ajay Kumar, Founder, PandaStack.