Firebase or Supabase? Choosing a Backend for a Mobile App

When you start a mobile app, the backend is the earliest decision you make and the latest one you can change. If you pick wrong, you feel nothing for the first three months; the problem shows up in month six, when you want to change your data model.

I have used both, and here is what I can tell you: this is not a "which one is better" question, it is a "what shape is my data" question. Below I go through where the two genuinely differ, and then the five questions I ask myself when choosing.

The core difference: documents or tables?

Firebase's database, Firestore, is a document database. You store your data as nested JSON objects. There is no schema — you can add a field today and drop it tomorrow, and nothing objects.

Supabase, on the other hand, is PostgreSQL. A real relational database: tables, columns, types, foreign keys and SQL. You have to define a schema.

That single difference drives everything else:

Where Firebase really shines

You should think of Firebase not as a "database" but as a bundle of everything a mobile app needs. Authentication, database, file storage, notifications, crash reporting, analytics and remote configuration — all in one console, all talking to each other.

Three things stand out for me:

• Offline support: The Firestore mobile SDK caches data on the device. Even when the user is stuck on the subway with no connection, the app keeps working, and it syncs itself once the connection is back. Writing that by hand takes weeks.
• Crashlytics: Whose phone your app crashed on, on which screen, on which line — you see all of it. That is half of surviving after release.
• Push notifications: Setup really does take 20 minutes.

Where Supabase really shines

Supabase's appeal comes down to one thing: there is a real PostgreSQL behind it. Which means when you need to ask a complicated question about your data, you can just ask it.

A query like "give me this month's 10 best-selling products with their categories, excluding the returned ones" is an architectural problem in Firestore; in Supabase it is a single SQL statement.

• Row Level Security: The authorization rules live inside the database. You write "a user can only see their own rows" once, and it holds no matter which client the request comes from.
• A predictable bill: A fixed monthly plan. In Firestore, if you design a list screen badly, you can rack up hundreds of reads on every open — and that goes straight onto the bill.
• No lock-in: Open source. If you want to move to your own server tomorrow, what you have is a standard PostgreSQL database.

The 5 questions I ask before choosing

When deciding on a concrete project, I work through these five questions in order. Usually the answer is obvious by the third one.

1. Is my data relational?

Draw the model on paper. If there are more than three entities with arrows between them (user → order → product → category, say), lean toward PostgreSQL. If it is just a single user's own records, Firestore will be comfortable.

2. Does the app have to work without a connection?

If the answer is "yes", Firebase starts with a strong advantage. You can get this with Supabase too, but you will be the one doing the work.

3. What questions will I be asking a year from now?

It is not today's screens that decide this, it is your future reports. If you are going to ask things like "which user group has the higher retention rate?", you will need SQL.

4. How predictable does the budget need to be?

If it is a client project and you have to quote a fixed monthly cost, Supabase's plan model makes your life easier. If it is your own product and traffic is uncertain, Firebase's free tier is very generous at the start.

5. Does anyone on the team know SQL?

This is the question people overlook. Supabase's power comes from SQL; if you are not going to write SQL, you cannot use half of that power.

Traps I fell into with both

Whichever one you pick, two mistakes are common to both:

So what do I use?

Both. On my own mobile apps — the ones where the user holds their own data and the app has to work offline — Firebase's bundle does the job for me; I especially do not want to set up something separate for Crashlytics and notifications.

On the e-commerce project I am working on, though, I am on the Supabase side. Modeling the relationships between orders, products, variants, stock and returns in a document database would have been torture.

Choosing a backend is not a matter of loyalty. Pick whatever fits the shape of your data — and make that decision on day one, not three months in.

• Firebase
• Supabase
• PostgreSQL
• Firestore
• Backend
• Architecture