Open-source alternatives to Firebase: 4 backend-as-a-service tools compared
Every one of these replaces a hosted backend with services you run, and what you give up in exchange is not a bill but a set of upgrades, backups and restarts you now schedule. supabase/supabase is the one most readers should look at first, because it keeps Postgres as the source of truth and generates the API layer instead of asking you to write one.
What Firebase does, and why people look elsewhere
Firebase is Google's hosted backend for apps: a document database, authentication, file storage, serverless functions and hosting behind client SDKs.
- proprietary database APIs (Firestore and Realtime Database) that no other host runs
- usage-based billing that is hard to predict once an app grows
- data and functions run only in Google's cloud
The candidates at a glance
| Project | Licence | Maintenance | Language | GitHub stars | Install |
|---|---|---|---|---|---|
| supabase/supabase | Apache-2.0Permissive: commercial use allowed | Commits in the last dayLast push November 7, 2026 | TypeScript | 114,639 | Command documented |
| appwrite/appwrite | BSD-3-ClausePermissive: commercial use allowed | Commits in the last dayLast push November 7, 2026 | TypeScript | 57,890 | See analysis |
| pocketbase/pocketbase | MITPermissive: commercial use allowed | ArchivedLast push October 26, 2026 | Go | 61,608 | See analysis |
| nhost/nhost | MITPermissive: commercial use allowed | Commits in the last six monthsLast push November 7, 2026 | Go | 9,375 | Command documented |
Each alternative in detail
supabase/supabaseThe Postgres development platform for web, mobile and AI applications.
- Best for
- You want Postgres to stay the source of truth and would rather have the API layer generated than written. The README lists hosted Postgres, authentication, auto-generated REST, GraphQL and realtime subscriptions, database and edge functions, file storage and a dashboard, reached through one client library.
- What you give up
- You are adopting several services at once: PostgREST, GoTrue, an Elixir Realtime server, a storage API over S3, pg_graphql and an Envoy edge proxy, each with its own configuration and its own failure mode. The model also asks your team to learn row level security and the auth service rather than a simpler key check. And there is no single install command in our analysis, because supabase/docker is a directory of services you assemble yourself.
- First install step
- Full setup guide
npx only-allow pnpm
appwrite/appwriteAppwrite® - complete cloud infrastructure for your web, mobile and AI apps. Including Auth, Databases, Storage, Functions, Messaging, Hosting, Realtime and more
- Best for
- You want auth, databases, storage, functions, messaging and web hosting behind one API, and you would rather run one container than wire five services together yourself. The README documents a single Docker command, with docker-compose, Kubernetes, Docker Swarm and Rancher as alternatives.
- What you give up
- The database is not SQL. Our analysis of Appwrite describes structured storage built around databases, tables and rows rather than a SQL engine, so there are no joins and no schema migrations, and the repository documents no path to one. Two release caveats matter too: the install image is pinned to 1.9.6 while the most recent release listed is 2.0.0-rc.1, a release candidate, and the README documents a Docker API version mismatch that occurs when the CLI inside the image is newer than your host engine.
pocketbase/pocketbaseOpen Source realtime backend in 1 file
- Best for
- One executable and one SQLite file is the entire deployment. It suits internal tools, prototypes and single-tenant services, and Go teams that want to register HTTP routes around an existing backend, with realtime subscriptions, file and user management and an admin dashboard built in.
- What you give up
- The README carries an explicit warning that PocketBase is still under active development and that full backward compatibility is not guaranteed before v1.0.0, so an upgrade can change behaviour under you. It is single-node by nature, with no horizontal write scaling and no Postgres wire protocol, which our analysis lists as reasons not to adopt it. Build targets are limited to what the pure Go SQLite driver supports, and the JavaScript and Dart SDKs are the only official clients.
nhost/nhostThe Open Source Firebase Alternative with GraphQL.
- Best for
- Your team already thinks in SQL tables and wants a GraphQL layer, auth and file storage without assembling them one at a time. PostgreSQL, Hasura, auth, storage and Node.js functions sit behind one CLI and one JavaScript client, and the CLI tracks database migrations and Hasura metadata locally.
- What you give up
- Our analysis of Nhost is explicit that this is not a drop-in Firebase migration, so an existing Firestore data model does not transfer across. There is no offline-first document sync either, which is the feature many Firestore apps lean on hardest. Self-hosting is a docker-compose example you assemble, on top of PostgreSQL, Hasura metadata and object storage that your team then operates, and that compose file rather than the README is what defines the real requirements.
- First install step
- Full setup guide
brew install nhost/tap/nhost
What each project wraps, and what none of them replicates
Firebase is Google's hosted backend for apps: a document database, authentication, file storage, serverless functions and hosting behind client SDKs. The reasons people leave are equally specific. The database APIs, Firestore and Realtime Database, are proprietary and no other host runs them. Billing follows usage, which gets hard to predict once an app grows. And the data and the functions run only in Google's cloud.
The four projects here answer that in three different shapes.
Two of them keep a SQL database at the centre. supabase/supabase puts Postgres under PostgREST, GoTrue, an Elixir Realtime server, a storage API over S3, pg_graphql and an Envoy proxy, and generates REST and GraphQL from your schema. nhost/nhost makes the same bet with a different API layer: PostgreSQL behind Hasura, with auth, storage and Node.js functions, all reached through one JavaScript client.
One of them replaces the database with a container runtime. appwrite/appwrite offers auth, databases, storage, functions, messaging and hosting, where the database is structured storage over databases, tables and rows rather than a SQL engine.
One of them is a single process. pocketbase/pocketbase is a Go executable with an embedded SQLite database, realtime subscriptions, file and user management and an admin dashboard, distributable as a Go module you build into your own binary.
What is missing across all four deserves the same attention. There is no Firestore-compatible server here, and there is no offline-first document sync, because those two things are what the proprietary API actually is. Projects that emulate the Firebase wire protocol for migration testing are not on this list, because emulating a protocol is not the same as replacing a backend, and a compatibility shim that only exists during a migration is work you still own. Choosing among these four means accepting a SQL or tabular data model and rebuilding the client around it.
Choosing by scenario: a solo developer, a small team, a company with residency rules, a GraphQL team
The four differ most in what they assume about your team size and your SQL skills.
A solo developer with an internal tool or a prototype should look at pocketbase/pocketbase. One executable, one SQLite file, an admin dashboard, and realtime subscriptions if the app needs them. The cost is the pre-1.0 warning, which matters more for a product than for a tool only your team uses, and the fact that scaling writes across nodes is not on the table.
A small team shipping a real product has two sensible routes. supabase/supabase if the team is comfortable with Postgres and wants the tightest fit between database and API, because the schema is the API and row level security does authorisation in the database. appwrite/appwrite if the team would rather not write SQL at all and wants a documented product for each capability, at the price of giving up joins.
A company with data residency or compliance requirements is looking for the same thing in all four: the database inside your own network. The decision then turns on operations. supabase/supabase means Postgres plus a set of side services around it. nhost/nhost means Postgres plus Hasura metadata plus object storage. appwrite/appwrite means one container that you still have to patch. None of them reduces to a single process, and pretending otherwise is how these migrations go wrong.
A team that thinks in GraphQL, or that already has Hasura experience, should look at nhost/nhost first. It is the only one of the four whose primary API is GraphQL, and the CLI workflow of nhost init followed by nhost up tracks database migrations and Hasura metadata, which is a real advantage when several people are changing the schema.
What each stack asks you to run and keep patched
The install commands on this page make the operational differences visible, including where they mislead.
appwrite/appwrite has the shortest documented path. One docker run, an installer entrypoint, a console on http://localhost, and the README points at a public docker-compose.yml and .env for production. The catch the README documents is the Docker API version mismatch: if the CLI inside the image is newer than the host engine, the install fails and you pass DOCKER_API_VERSION to pin it. It also ships a pinned 1.9.6 image while 2.0.0-rc.1 sits in the release list, so decide which line you run.
supabase/supabase has no single install command in our analysis, because supabase/docker is a set of services rather than a program. What you operate is a Postgres instance, an Elixir Realtime server, an S3-compatible store for files, an edge proxy and a dashboard, plus the database itself. The README also states that client libraries are modular, and its table marks which ones are official, so confirm the SDK you plan to use is listed there.
nhost/nhost shows brew install nhost/tap/nhost on this page, and that is the CLI, not the server. The README sends self-hosting to a docker-compose example, and our analysis of Nhost is explicit that this file, not the README, is what defines what you need. Under it sit PostgreSQL, Hasura with its metadata to track, object storage and Node.js functions.
pocketbase/pocketbase has no install command in our analysis, but the README describes downloading a prebuilt executable and running it with serve, or vendoring the module into your own main.go. Either way the runtime footprint is one process. What you give up is any way to scale it horizontally.
Licence terms, and how little they differ
On paper this is the easiest decision on the page, and it is worth saying why that is less useful than it looks.
supabase/supabase is Apache-2.0. nhost/nhost and pocketbase/pocketbase are MIT, and the PocketBase README goes further, stating you are free to do what you want with it, including offering it as a paid service. appwrite/appwrite is BSD-3-Clause. All four are permissive, and all four let you run a modified version without publishing your changes.
The AGPL case that appears on other self-hosted lists does not appear here, which removes a decision that often stalls a company review. What it does not remove is the obligation that usually kills a project like this: you now operate the thing. A permissive licence tells you that running a modified Supabase inside your network is fine. It does not tell you who patches Postgres when a release needs one.
Two practical notes sit alongside the licences. Both PocketBase and Appwrite ship versions that are worth pinning deliberately rather than tracking automatically: PocketBase warns that backward compatibility is not guaranteed before v1.0.0, and the newest Appwrite release listed is a release candidate. Neither is a licence problem, and both are upgrade-planning problems, which is where a permissive licence offers no help either.
Moving the data across is a project of its own
The part of a Firebase migration that is usually underestimated is the data model, and the four candidates all push you in the same direction on it.
A Firestore collection is a tree of documents with nested maps and arrays. A Postgres table is a set of rows with declared columns. A records API over tables and rows, as appwrite/appwrite provides, sits in between but has no nesting. Converting between them is not a schema translation, it is a rewrite of every query, every security rule and every offline listener in the client, and none of the four tools does that work for you.
What makes the move tractable is that the target is a database you own. With supabase/supabase or nhost/nhost you can load the exported documents into tables, add the columns you need, and serve the app from SQL, and at any point the data is a database dump rather than a vendor export. That reversibility is the argument for moving even when the rewrite is unpleasant.
The things worth budgeting for are the ones no tool automates: the security model, which is row level security in Postgres rather than rules in a document store, and the realtime layer, which listens to Postgres replication in supabase/supabase rather than to a document stream. Plan the second rewrite before you start, because it is the one that touches every screen in the app.
Bottom line
Pick pocketbase/pocketbase for internal tools and prototypes where one process and one SQLite file are the point, supabase/supabase for a product team that wants Postgres as the source of truth, appwrite/appwrite when nobody on the team wants to write SQL, and nhost/nhost when GraphQL is already how your team works. Before committing, confirm the SDK you plan to use is listed as official, decide whether you are running a release candidate, and write down who patches Postgres.
Sources
Was this useful?