By Maciej Pyrc, who maintains Hype Stack.Published .
Most lists of Supabase alternatives are other backends you rent. One option they skip is a backend you own, and it is the right answer for a specific kind of app.
Supabase gives you Postgres, auth, file storage, edge functions and realtime behind a dashboard and a client SDK, open source and self-hostable. For a prototype, an internal tool or a small team that does not want to run a backend, it is a very good deal, and most people searching for supabase alternatives are not leaving because it is bad. They are leaving because something about the shape stopped fitting: logic that lives in row-level security policies nobody on the team can read, a project that cannot move, a bill that scales with the thing they built, or a product that needs organizations, billing and an admin app on top of the primitives.
This page sorts the alternatives by which of those problems they solve. The last section is the option the other lists leave out, and it is what we make, so read it knowing that.
Why people leave, and what that says about the replacement
The four complaints
Logic in policies
Row-level security and database functions are powerful and invisible. A permission bug lives in SQL nobody on the frontend team opens, and testing it means a database.
The project is the lock-in
The code is portable. The project, its auth users, storage buckets and edge functions, is the thing you cannot lift out in an afternoon.
Usage scales the bill
Fine while the app is small. Less fine when the thing you built works and the meter is tied to it.
Primitives are not a product
Users, yes. Organizations with roles, subscriptions, an admin screen and the emails around them are yours to build, on every platform in this category.
The first two complaints point at a different kind of backend. The third points at self-hosting or a flat-cost option. The fourth is not solved by any hosted backend, because they all stop at the same line.
The alternatives, by what you are leaving for
Two more worth naming without a column. Neon is serverless Postgres and nothing else; pair it with an auth library such as Better Auth and you have the database half of Supabase with none of the rest, which suits developers who wanted Postgres and not a platform. Nhost is Supabase's shape over Hasura, for teams who think in GraphQL.
Self-hosting Supabase is an alternative too
Supabase is open source, and the whole platform runs from a Docker Compose file. That removes the usage bill and the project lock-in in one move, and it is the right call when the only complaint was cost. What it does not remove is the operational work: a dozen services, upgrades, backups, and a team that now owns a platform rather than an app. If that sounds like more than the app deserves, the answer is a smaller backend, not a bigger one.
The option the lists leave out
Rent a different backend, or own one?
The problem was Supabase specifically: the data model, the pricing tier, the SDK.
- Firebase, Appwrite, PocketBase or Convex, depending on the row above that bit you
- Same shape as before: primitives you compose, a product you still build on top
The problem was the shape: logic you cannot test, a project you cannot move, a product the primitives do not cover.
- A Hono backend on Postgres, in your repository, with auth, organizations and billing as packs
- Deploys as two containers to any host; the database is any Postgres, Supabase's own included
Supabase's database is a fine Postgres. Many people who leave the platform keep the database and move the logic.
Hype Stack is the second branch. It is an MIT template: React with TanStack Router on the frontend, Hono with Prisma and Kysely on Postgres behind it, an admin app and an Expo mobile app, typed end to end. The parts Supabase hands you as primitives arrive here as packs you install into the repository: Better Auth with organizations, invitations and roles; Stripe subscriptions with webhook handling that re-syncs from Stripe; an admin app with user and organization screens; notifications with the email layer. Logic lives in routes and modules you can read and test. The database is whichever Postgres you give it a URL for.
What you write yourself after the install
- Your tables and routesAdd models to the Prisma schema next to the ones that ship, migrate, write the Hono routes. The frontend SDK picks up the types without a codegen step.
- The product screensThe shells, auth pages, settings and billing screens exist. The screens your customers pay for are yours.
- Realtime, if you need itWebSockets are wired with typed events, but what to push and when is a product decision, and Convex's model is the better fit if realtime is the whole product.
What is not in the box: there is no hosted dashboard, no one runs it for you, and storage is an S3-compatible bucket you point it at rather than a managed file browser. A team that chose Supabase because nobody wanted to run anything should read that twice before switching.
Which one, in one paragraph each
Keep Supabase when the complaint is a feature request, not the shape; it ships fast and the team knows it. Take Firebase when the app is mobile-first and already in Google's world. Take Appwrite or self-hosted Supabase when the only problem is who runs it. Take PocketBase for a small app on one server. Take Convex when realtime is the product. Take a template you own when the app is a business with accounts, billing and a long life ahead, and the backend has to be code your team can read, test and move.
If the Supabase project came with a Next.js frontend, the move is covered in Next.js Supabase Boilerplate Alternative, and the framework question on its own in Next.js Alternative. The auth half of what you replace is in Better Auth SaaS Template.