Backend and hosting
Firebase vs Supabase
Start with the data model. Choose Firebase with Firestore if your app fits collections of documents and you want to use Firebase client SDKs. Choose Supabase if you want Postgres tables, SQL joins, and database-level access policies.
Documentation reviewed
At a glance
| What to compare | Firebase | Supabase |
|---|---|---|
| Data model | Cloud Firestore stores documents in collections and supports nested subcollections. | Each project has a Postgres database with tables, relationships, and SQL queries. |
| Client access | Use Firestore Security Rules to govern document reads and writes from web and mobile clients. | Use Postgres row-level security policies to control access to rows through the Supabase Data API. |
| What to prototype | Model a screen around its document queries and test who can read and write each document. | Model the same screen with related tables, then verify each role can access only the rows it needs. |
Which should you use?
Choose Firebase if…
Your data already fits a document model and your client uses Firebase SDKs and Firestore rules.
Choose Supabase if…
Your data has many relationships or your team needs SQL queries, joins, and database constraints.
Before you switch
For a Firestore-to-Supabase move, map one collection and its subcollections to tables first. Recreate the access rules as row-level security policies, then test an authorized user and a user who should be denied. This comparison focuses on Firestore within Firebase.
Common questions
- Can Firestore security rules be reused in Supabase?
- Plan to rewrite them as Postgres row-level security policies. Test ownership, team membership, and denied access with separate test accounts.
- Do Firestore subcollections have a direct Postgres equivalent?
- Map them according to how you query and update the data. A child table with a foreign key is a good starting point for independently queried child records.