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.

Comments

[Rashim Narayan Tiku]

You haven't added the biggest price factor for Supabase which is "Bandwidth" and "DB scalability".

1. "Bandwidth": You won't run out of MAUs or DB storage, but you would easily cross the 5gb bandwidth mark, after which 25$ plan is your only option.
2. "DB scalability": Free tier gives you micro DB which has very less concurrent connections allowed, scaling it again will cost you paid plan + extra compute costs.

Supabase have very smartly advertised to bring in customers, but you realize after you get in that "there's no such thing as a free lunch".

[Anuj Kaithwas]

Hi,
Thanks for the post. I however have a question about authentication. If my app uses social authentication, firebase offers only 50k MAU while the pro plan for Supabase offers 100K MAUs. Would you then prefer to use Supabase Auth and Firestore DB? How would you approach this problem where you are going to have a lot of users using the app(+100,000 per month) and you want the power of RDBMS because you want to build an analytical platform for your app and app transactions?

[Nicolò Curioni]

Hi, interesting post, but I have a question, I’m developing a diary app, for iOS/iPadOS and also macOS/watchOS, but I’m uncertain if use Firebase or Supabase. My app let the end user’s to edit the note content, with textView text styles, like different colors, fonts, formats and also add images inside the text, but, can I use Firebase or Supabase?
Have you some advice’s?

Thanks,

Nicolò Curioni
iOS Developer

[Matthew Harris]

Yes you can store both easily. There is a limitation with the nosql firebase that each record can be a maximum of 1mb (I think thats the limit). That is a ton of text to allow per note but its worth considering.

You can also split a document over multiple records with a bit of creative coding, if you do need to go beyond those extreme limits. If you want to learn more about strategies for nosql I would recommend looking up Fireship on YouTube who has some good videos.

[shaoyanji]

pssssst....pocketbase

[codingjlu]

Thanks for the great article! I was searching this on Google because I wanted to see the pricing comparison, and you've covered that just well. Thanks again!