Firebase vs Supabase

Firebase's advantage is that it is a whole mobile platform, not a database. Crashlytics, Analytics, Cloud Messaging, Remote Config, A/B testing and App Distribution are all there, they all work, and they are all wired into the same project. If you are shipping an iOS and Android app, that bundle is worth more than any single technical property of the datastore.

Supabase's advantage is that it is Postgres. Relational modelling with real foreign keys, joins that don't require denormalising your entire schema, extensions, and a migration path off the platform that is a pg_dump rather than a rewrite.

The deciding question is usually your data shape, not your framework. Firestore is a document store that charges per document read, which pushes you toward denormalisation and duplicated data kept in sync by Cloud Functions. That is a reasonable model for feeds and chat and user profiles. It is a painful model for anything with many-to-many relationships, reporting, or a finance-shaped correctness requirement.

Our call for most new web products is Supabase, because most new web products have relational data and a team that already knows SQL. For mobile-first products where offline is a first-class requirement, Firebase's client SDKs remain the best in the business and Supabase has nothing that matches Firestore's offline persistence out of the box.

The second-order consideration is Google. Firebase is a Google product with everything that implies — excellent infrastructure, and a company with a track record of deprecating things. Supabase is open source, self-hostable, and much younger.

Firestore is a hierarchical document store. Documents live in collections, may contain subcollections, and queries are shallow by design — there are no joins. You model by duplicating: a chat message stores the sender's display name and avatar URL, because fetching the user document for every message would double your read count. When the user changes their avatar, a Cloud Function fans out and rewrites every message they've ever sent, or you accept stale data.

That is a legitimate architecture. It is also a decision you cannot easily reverse, and it gets more expensive to reverse the longer the project runs.

Postgres does the opposite. You normalise, you join, and the database enforces referential integrity. Adding a new access pattern is a new query, not a new denormalised collection plus a backfill plus a sync function. The cost is that you have to think about indexes and connection pooling, and that Supabase's realtime layer is weaker than Firestore's (see below).

A practical heuristic: write down the five queries your app will run most. If none of them need data from more than one collection at a time, Firestore is comfortable. If three of them are joins, you will fight Firestore for the life of the project.

Firebase bills Firestore per document read, write and delete, plus storage and egress. This is the single most important operational fact about it. A screen that renders a list of 50 items costs 50 reads every time it loads, per user. Add a realtime listener and every change to any of those documents costs another read. Teams are routinely surprised not by their storage bill but by a UI that innocently re-reads a collection on every navigation.

The mitigations are real — aggressive caching, bundle loading, denormalised counters instead of counting documents, and careful listener scoping — but they are engineering work that exists purely to manage the billing model.

Supabase bills like a server: a flat fee per project on paid plans, compute sized by instance, then storage and bandwidth. A query that returns 50 rows costs the same as one returning 1 row, as far as your invoice is concerned. You can run a badly written query a million times and your bill won't move; your CPU graph will, and that is a more familiar failure mode for most engineers.

Neither model is inherently cheaper. Firebase is cheaper for spiky, low-traffic apps that would otherwise pay for idle compute. Supabase is dramatically cheaper for read-heavy apps, and it is far easier to forecast, which matters more than the absolute number to most teams.

Firestore listeners are the mature product here. They work offline, they queue local writes and replay them on reconnect, they resolve conflicts with last-write-wins, and the client SDK maintains a local cache that survives app restarts. For a mobile app used on a train, this is not a nice-to-have.

Supabase Realtime streams Postgres logical replication over a websocket. You subscribe to table changes with optional filters and receive row-level events. It is fast and it is simple, but it is not offline sync: there is no local persistence layer, no write queue, and no conflict resolution. Teams that need offline on Supabase reach for an external local-first layer — ElectricSQL, PowerSync, or a hand-rolled cache — and that is a meaningful amount of extra work.

If offline-first is on your requirements list, this section alone probably decides the comparison. If your app assumes connectivity, both are adequate and you should decide on the data model instead.

Supabase is open source under a permissive licence and can be self-hosted. Most teams never will, but the option changes the negotiation: if pricing moves against you, you have somewhere to go, and the Postgres underneath moves to any provider.

Firebase cannot be self-hosted, and Firestore's query semantics do not exist anywhere else. Migrating off means exporting JSON and rebuilding your data layer against something relational — the same class of work as leaving Convex, and usually larger because Firebase projects tend to be older.

Against that, Firebase's surrounding platform has no equivalent on the Supabase side. Cloud Messaging for push, Crashlytics for crash reporting, Remote Config for feature flags, App Check for abuse prevention. On Supabase you assemble those from other vendors. That is more choice and more invoices.

Longevity cuts both ways. Google has deprecated a lot of products, and Firebase's own history includes retired pieces. Supabase is a venture-funded startup, which is its own kind of risk — mitigated, but not eliminated, by the open-source escape hatch.