Open-source alternatives to Firebase

Most “Firebase alternative” advice skips the only thing that actually makes this migration painful: Firestore is a NoSQL document store, and every option below moves you to a relational model — Postgres for Supabase and nhost, embedded SQLite for PocketBase. The work isn’t standing up a new backend — all four below do that well — it’s reshaping a denormalised, document-shaped data model into tables (or deciding not to). Get that decision right and the rest is straightforward. Get it wrong and you spend a month fighting your own schema.

Supabase — the default, and the one that forces the data-model question

Supabase (102.7k stars, the most in this list by a wide margin, Apache-2.0) is the feature-complete answer: Postgres, auth, storage, realtime subscriptions, edge functions, self-hostable or managed. Apache-2.0 is a clean, permissive license with no asterisk — the easiest licensing story here. The reason it is the default is breadth: it covers the most Firebase surfaces in one project. But it is also the project that confronts you most directly with the NoSQL→SQL reshape, because you are now in a relational world with foreign keys and row-level security. That is more upfront design than Firestore asked for, and more power once you are through it. If your data was already fairly relational underneath the Firestore document wrapping, this is the obvious move.

PocketBase — the single-binary antidote to Firebase’s sprawl

PocketBase (58.4k stars, Go, MIT) is the one I reach for when the project is small and Firebase felt like overkill. It is one Go binary with embedded SQLite covering auth, file storage, and realtime — you scp it to a $5 VPS and you have a backend. MIT licensed, the cleanest possible terms. For a side project, an MVP, or a mobile app with modest concurrency, this is dramatically less to operate than Supabase. The honest ceiling: it is SQLite, single-node, so it is not the pick for an app expecting high write concurrency or horizontal scale. Know which side of that line you are on.

Appwrite — the closest “platform” feel for multi-platform apps

Appwrite (56.1k stars, TypeScript, BSD-3-Clause) is the one whose shape most resembles Firebase as a console-driven platform with first-class SDKs across web, iOS, Android, Flutter, and more. If what you valued about Firebase was the breadth of official client SDKs and a console UI rather than the specific database, Appwrite ports that mental model most directly. BSD-3-Clause is permissive and embedding-friendly.

nhost — only if you specifically want GraphQL

nhost (9.1k stars, TypeScript, MIT) is essentially “Supabase but with Hasura GraphQL on top of Postgres”. It is the right pick only if your frontend was already built around GraphQL and you want that to be the primary API surface. For everyone else, Supabase’s larger community and broader feature set make it the safer bet at the same Postgres foundation.

The features with no replacement

Be clear-eyed about what does not come over: Crashlytics, Performance Monitoring, and Firebase’s A/B testing / Remote Config have no direct open-source equivalent in any of these. If those were part of your stack, you will be wiring up Sentry (or similar) and a feature-flag service separately. Plan for them as line items, not afterthoughts — they are genuinely the stickiest part of the Google ecosystem.