Source: https://www.hype-stack.dev/stacks/supabase-alternatives # Supabase Alternatives: Rent Another Backend, or Own One > 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 | | Firebase | Appwrite | PocketBase | Convex | A template you own | | --- | --- | --- | --- | --- | --- | | What it is | Google's hosted backend: a document database, auth, storage, functions, built for mobile first. | An open-source backend you host or rent: database, auth, storage, functions, with SDKs and a console. | One Go binary with SQLite, auth, files and an admin UI. Tiny to run. | A reactive backend in TypeScript: functions and a database that push updates to the client. | A Hono backend on Postgres you run anywhere, with the app, admin and mobile apps around it. | | The database | Firestore, a document store. Different shape from Postgres, which is the migration. | Its own database layer over a relational store, through its SDK. | SQLite on one machine. Fast, simple, single-node. | Its own document database, queried from functions. | Postgres, through Prisma migrations and Kysely queries. Any host. | | Where logic lives | Security rules and cloud functions. | Permissions on the console plus functions. | Rules on collections plus Go or JS hooks. | TypeScript functions, all of it. | TypeScript routes and modules, tested like any code. | | Leaving later | Hard. Data and auth are platform-shaped. | Possible: self-host the same thing. | Easy: it is one binary and one file. | Export exists; the reactive model does not travel. | Nothing to leave. Move the containers and the database URL. | | They win when | The app is mobile-first and Google's ecosystem is already in play. | You want Supabase's shape with a host you choose, or your own server. | A small app, one server, and you value simplicity over scale. | The product is realtime and collaborative by nature. | The app is a product: accounts, organizations, billing, and a year of life ahead of it. | 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?** - **Rent another backend:** 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 - **Own the backend:** 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 routes** Add 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 screens** The shells, auth pages, settings and billing screens exist. The screens your customers pay for are yours. - **Realtime, if you need it** WebSockets 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](/stacks/nextjs-supabase-boilerplate), and the framework question on its own in [Next.js Alternative](/stacks/nextjs-alternative). The auth half of what you replace is in [Better Auth SaaS Template](/stacks/better-auth-saas-template).