Open source Firebase alternatives: Supabase, Appwrite, PocketBase and Nhost

What does a Firebase alternative need to cover?

Firebase bundles a database, authentication, file storage, serverless functions, hosting and realtime updates behind client SDKs. Teams leave for different reasons: vendor lock-in, a document database that fights relational data, or the need to host data in a specific place.

An open source backend-as-a-service should cover at least the database, auth and storage with decent SDKs. Realtime subscriptions and functions are the next most important pieces.

The biggest design decision is the database model. It shapes how you query, how you secure data and how painful future migrations will be.

Also consider who will operate it. A backend you self-host becomes a production database you are responsible for, including backups, upgrades and security patches.

Which open source Firebase alternatives are worth comparing?

Licences here are mostly permissive, which is good news for commercial products. Still, check each component, because some stacks combine several projects with their own terms.

Supabase: Postgres with batteries

Supabase wraps Postgres with an auto-generated REST API, authentication, storage, realtime change streams and edge functions. Access control is written as Postgres row-level security policies, so the rules live next to the data.

Because it is plain Postgres underneath, you can use SQL, extensions and ordinary migration tools, and you can leave later with a standard database dump. That exit path is its strongest argument against lock-in.

Self-hosting uses Docker Compose with a gateway, auth service, storage API, realtime server and more. It works well, but plan for more operational surface than a single binary.

Supabase also offers a managed cloud with the same APIs, so you can develop against the hosted version and self-host later, or the reverse, without rewriting client code.

Its local development tooling runs the whole stack on your machine, which makes migrations and tests reproducible across the team.

Appwrite, PocketBase and Nhost: when they fit better

Appwrite presents databases, auth, storage, functions and messaging through a unified API and SDKs for many platforms. It suits teams that like Firebase’s developer experience and do not need raw SQL.

PocketBase is a single executable with an embedded SQLite database, auth, file storage, realtime subscriptions and an admin UI. You can also use it as a Go framework and add your own code. For small products it is hard to beat on simplicity.

Nhost gives you Postgres with a Hasura-generated GraphQL API, plus auth, storage and functions. If your frontend is built around GraphQL, it removes a lot of boilerplate.

Each backend has a natural sweet spot. Supabase suits SaaS products with relational data, reporting and AI features, since Postgres extensions such as pgvector make embeddings a table away. PocketBase suits internal tools, prototypes and small apps where one binary is a feature.

Appwrite fits mobile-first products that want consistent SDKs across platforms. Nhost fits frontends already built around GraphQL and generated types.

Whatever you pick, keep business logic in a layer you control, such as functions or your own API, so a future move does not require rewriting the whole client.

PocketBase deserves a note on maturity: check its release notes and versioning policy before production use, and pin the version you deploy so upgrades happen on your schedule.

Nhost’s value depends on how much you like GraphQL. Teams that prefer REST often find Supabase’s approach more natural for the same Postgres foundation.

How to choose step by step

Keep the evaluation small. One feature built end to end reveals more about a backend than a week of reading comparison posts.

• Sketch your data: many related tables point to Postgres-based options.
• Decide how you will host: managed cloud, your own servers, or both over time.
• Estimate scale honestly; most apps never outgrow a single well-sized server.
• Check SDK support for every client platform you ship: web, iOS, Android, Flutter.
• Prototype one real feature, including auth and a permission rule, in your top two picks.
• Test backups and a restore before production, not after an incident.

How much does it cost to run?

Self-hosted, the software is free and the cost is servers plus operations. PocketBase can run on a very small virtual machine. Supabase’s full stack needs more memory because of its many services, and Postgres itself benefits from generous RAM.

Most of these projects also offer managed hosting. A common path is to start managed, then self-host once the data model and traffic are stable, or the reverse when operations become a distraction.

Budget time for monitoring too. Disk usage, slow queries and failed backups need alerts, whichever platform you pick.

For a first production launch, a managed database with automated backups often removes the riskiest part of self-hosting while you keep the rest under your control.

Common mistakes and where it breaks

Security policies deserve tests of their own. Write a few queries as an anonymous user and as a normal user, and confirm they fail where they should.

Rate limits are another gap. Public endpoints for sign-up and password reset need protection, or bots will use them to send mail or probe accounts.

• Shipping with row-level security disabled or with overly broad policies.
• Putting the service or admin key in client code, which bypasses every rule.
• Choosing PocketBase for a workload that needs several app servers writing at once.
• Treating realtime as a message queue and hitting connection limits.
• Skipping migrations tooling and editing production schemas by hand.
• Forgetting that self-hosted auth needs working SMTP for sign-up and password reset emails.

Migrating away from Firebase

Moving Firestore data to a relational database means reshaping nested documents into tables. Do the modelling work first; a direct copy of document structures into JSON columns tends to recreate the old problems.

Authentication is the trickiest part. Plan how users will keep their accounts, whether through password hash import where supported or through a forced reset. RepoLoot’s catalog lists starter kits built on these backends, which can shorten the rewrite considerably.

Migrate in stages where you can. Moving one feature or one collection at a time, with both backends live, reduces risk compared with a single weekend cutover.

Storage files move more simply. Copy them to the new bucket, update references in the database and keep the old bucket read-only until you are confident nothing still points at it.

How do they compare feature by feature?

All four cover the basics, but details differ. Use this as a starting checklist and confirm against current documentation, since these projects ship new features frequently.

Frequently asked questions

Is Supabase a true open source Firebase alternative?

Yes, most of Supabase’s components are open source under permissive licences and it can be self-hosted with Docker. It differs from Firebase by using Postgres, a relational database, instead of a document store, which many teams consider an advantage for structured data.

When is PocketBase the right choice?

PocketBase fits small to medium apps, prototypes, internal tools and side projects that run on one server. It ships as a single binary with SQLite, auth, storage and realtime built in. Choose something else if you need several servers writing to one database.

Can I self-host Appwrite?

Yes. Appwrite is designed to be self-hosted with Docker and is released under the BSD-3-Clause licence. It provides databases, authentication, storage, functions and messaging through one API, with SDKs for web, mobile and server platforms, and a managed cloud if you prefer.

Which alternative is easiest to migrate away from later?

Postgres-based options such as Supabase and Nhost are generally easiest to leave, because your data sits in a standard database you can dump and restore anywhere. Tools with their own storage layer need an export step and more reshaping during migration.