Cost Estimate: Migration from Firebase
Hello Folks,
I'm actually new supabase, but heard about it from couple of my friends, therefore I'm looking at as potential alternative that could totally replace lots of over costing firebase apps,
When it comes supabase features when compared to firebase, I'm totally intrigued, but now I'm kind last place where I need to estimate the cost of operation when it compares to firebase.
When it comes one of my primary app that's hitting around 10M Reads and 1M Writes Every Day or Every Other Day, Therefore Based on that I'm looking for estimated cost on Supabase and I would love to know more about how the Pro Usage Based Plan Works as well.
I appreciate, if anyone can hop in and explain the above problem, Thanks
4 Replies
You basically pay for fixed size CPU/memory size to handle the query load. Almost impossible to guess at coming from Firebase but you can see the CPU pricing on the pricing page and experiment on a free instance to get a feel.
Otherwise it is egress of data. There is no read/write query charge.
If you use realtime you need to look at the pricing closely as that is nothing like Firebase.
I moved from Firestore to Supabase because the charge per queried row and inability to control what data I actually downloaded would kill me on pricing. With Supabase/Postgres you can read just one column from your table if you want. Also the filtering of SQL versus Firestore (think partial text) was also killing me.
Your query rate is totally dependent on the complexity of the query and size of the table and indexing . Also read/write from firebase was measured by records. In Supabase you are really talking about query cost and the number of records per query can be a small impact depending on the query.
@garyaustin Thanks a lot for explanation, I'm 90% convinced to migrate but I know we can't compare cost of the both system in a apples to apples way, but I'm kind worried if the cost of operation would be higher once the migration is done, already Firebase is operation cost extremely high for me, if the supabase goes beyond, it's hard to handle
I understand. You are coming from a totally different charging environment based on records read and written with little control of the data you are forced to access. I would assume egress would be less for Supabase as you don't need to fetch all the row's columns and only the rows you need. The tradeoff is you ARE billed at a fixed rate for the size of your instance CPU/Memory and that is hard to estimate coming from a Non-SQL database. You always have option to selfhost if things get too big, but that brings with it managing your own environment.
Yeah, having it as Open Source, has the option self host. That's a major advantage on my case. Let me do trial run for next few weeks with supabase and let's decide afterwards. Thanks a lot man for swift response, I appreciate that