Supabase Vs Firebase Pricing and When To Use Which

Supabase recently appeared on the scene as an attempt to be an open source alternative to Firebase. It's a great product and I've used it in many projects already. I've written about it here and here.

The main difference between Supabase vs Firebase is that Supabase is a SQL database that utilized postgres and Firebase uses a NoSQL document data store.

On my current side project I recently replaced Supabase for Firebase. I'll get into why and some of the pricing differences to consider.

Consideration for Supabase vs Firebase

Firebase has more features, for now

For one, Firebase has been around much longer than Supabase and thus has more features. You can host your app on Firebase, you can also write cloud functions. (Currently I believe Supabase has cloud functions in beta).

Both have great options for objects storage, authentication, and most things you will need as a backend as a service product.

Also, while Supabase is not yet a perfect 1:1 mapping of Firebase, they do seem to be very quickly puting out new features to more closely match Firebase's offerings.

SQL vs NoSQL

This is a big one that I've been considering more. I enjoy relational data and my brain allows me to think about the relationships that SQL allows better than NoSQL document or key/value stores.

I've been doing more of a deep dive into NoSQL and learning about how to structure data with it lately.

With my research, I have decided that for small side projects and MVPs, I will be going with Firebase over Supabase if I truly don't need my data to be relational.

NoSQL (firebase) can often be structured in a way that is more efficient than SQL.

There are drawbacks however. Because you can't write complex queries and joins, you do have to consider how you might want to query your data in the future.

This can be a difficult task. Once you have correctly anticipated the queries your application will need in the future, you actually duplicate that data into another document or collection in the NoSQL data store.

Of course, now you have multiple places to update data too! This sounds like a headache, but with some practice it's actually pretty easy to catch on fast.

After learning some more about how to structure documents in a NoSQL datastore, this performance and scalability is why I have decided that I will typically use Firebase over Supabase.

The other reason is price.

Pricing

Another consideration for the Supabase vs Firebase debate is pricing. Both services offer a generous free tier. But what makes pricing considerations difficult is that scalability always has to be kept in mind.

First, let's go over what each service offers for free in terms of a database and authentication (the two most used services by each) per month.

Supabase:

You get 3 free projects. You get 500 MB of storage. You get 10,000 users through their authentication service.

Firebase:

You get unlimited free projects. You get 1 GB of storage. You get 10,000 users through their authentication service.

Firebase does charge for ingress and egress too. So you get 20,000 free writes per day and 50,000 free reads per day.

Which to choose

Ultimately, when I think about how my projects are going to scale (if they ever needed to) and what I am going to use them for, often NoSQL is just fine for my use cases and I get a better deal with Firebase.

This is because my projects don't often scale to over 20,000 writes per day or 50,000 reads per day. And even if they do, the price is comparable with Supabase's next tier.

This decision allows me to save my limited supabase free projects for when I really need a relational database.