Supabase or Firebase: which one you can leave

The property that decides this choice is not the feature list — it is exit. Supabase puts an ordinary Postgres database at the centre, so the data has a shape another host could run. Firebase puts a document store at the centre, and its client SDK is the shape: you write documents, not rows, and the rules guarding them are in a language only Firebase evaluates. The answer flips when the application must work offline on a phone.

What is the data model, and can you take it with you?

Supabase is Postgres. Tables, foreign keys, joins, transactions, a migration history kept as SQL files, and the same engine you could run on any managed Postgres host or a server you own. A full export is the database's own dump, and a second team can restore it without knowing which vendor produced it.

Firebase's Firestore is a document store: collections of documents, nested by path, with indexes you declare and queries limited to what those indexes support. It suits a screen-shaped application — a feed, a chat, a profile — and stops suiting one that needs a report joining four things. What an export gives you is documents, not a schema another engine accepts: the relationships live in your application code, so a migration is a rebuild.

What does a client talking straight to the database do to your rules?

Both products let the browser or the phone speak to the database directly, and both make you write the authorization somewhere else than the request handler. That is the point of them, and it is also the risk.

In Supabase the guard is row-level security: SQL policies attached to each table, evaluated by Postgres, written in the same language as the schema and testable with a query. The published key ships in the browser bundle, so a table with no policy is a public table; the default is open until somebody closes it.

In Firebase the guard is a rules file: a separate language, evaluated per document, unable to call your own code. A query is rejected unless the rules prove it stays inside what the user may read — hence "rules are not filters".

Either way, authorization is a second codebase deployed on its own schedule, and the part of a project least often reviewed. OWASP's authentication guidance is written for servers, but the rule underneath transfers: the decision belongs where the data is, and anything that costs money needs a check the client cannot skip.

How much do auth and file storage cost you at exit?

This is the part teams underestimate, because it is invisible while it works.

Auth is the hardest thing to move: user records, password hashes, verified phone numbers, the identities linked to Google or Apple, and the sessions people hold. Ask before signing what a full export contains — records with hashes, or a list of addresses. That decides whether leaving is a weekend or a quarter.

File storage is easier and still not free. Supabase keeps files in an S3-compatible bucket with policies in SQL, so a copy can be pulled with ordinary tools. Firebase Storage is backed by a bucket you can reach too, but the download URLs handed to the app are vendor-shaped, and every stored URL has to be rewritten when the host changes.

The quiet trap is phone sign-in: SMS delivery is a commercial arrangement per country, not a feature flag. Confirm that verification messages reach Algerian numbers before you design a registration flow around them.

When is offline-first the deciding factor?

If the application must keep working in a basement, a delivery van or a wilaya with one bar of signal, Firebase is ahead. Its client SDKs persist data locally and reconcile when the connection returns — behaviour that is part of the product, not something you add.

With Supabase the same outcome is achievable, but you build the sync: a local store, a queue of pending writes, conflict rules, and a decision about two devices editing one record. That is a real feature with a real cost.

For a back-office system used on a laptop with a connection, offline is a requirement nobody has. Say which one you have before comparing anything else.

What does the whole choice look like side by side?

Dimension	Supabase	Firebase
The data model	Postgres: tables, joins, transactions	Firestore: documents, declared indexes
What an export gives you	A database dump another host can restore	Documents to rebuild elsewhere
Where authorization lives	SQL policies inside the database	A rules language evaluated per document
Offline behaviour	You build the sync layer	Built into the client SDK
What to verify yourself	Which export includes users and files	What a full auth export contains

How should a team decide?

1. Write the five questions the business will ask of this data in a year. If one needs a join, that is a mark against documents.
2. Decide whether the app must work offline. If it must, test that path before anything else.
3. Ask both vendors, in writing, for a full export: schema, data, users, files. Compare answers, not marketing pages.
4. Restore that export into a fresh environment and hand it to somebody who has never seen the project. If they cannot run it, you measured the exit.
5. Only then compare SDKs, dashboards and terms, with the exit cost written in.

Where this goes wrong

• Rules written last. The prototype ships with an open table, then a launch date arrives, and the policies are written in a hurry by whoever is free.
• The admin panel using the public key. A dashboard is built on the same key as the app, and every visitor can read what the dashboard reads.
• The vendor dashboard treated as reporting. Nobody builds the report the accountant needs, because a console once showed a number.
• Storage URLs stored in the database. The files move, the URLs stay, and every image breaks at once.
• Quotas discovered in production. A limit nobody read is reached during a campaign.

What this advice leaves out

No prices appear here, deliberately. Both are sold in tiers that change, and a figure here would be stale before it ranked. The last row of the table is the one to open in another tab.

This also leaves out the cost of self-hosting, the question of where data physically sits, and the case where a server and a database you manage is the honest answer — more common than the tooling conversation suggests. We build applications on both, resell neither and take no commission, so the comparison above carries no commercial interest.

We build the database as the part you keep and the vendor as the part you can replace, because the exit is the design decision.