Migration from firebase
I've made an app with firebase an ionic react (javascript). It's not in production yet, but I'm getting close, and not liking the pricing. I've seen a lot of noise online, and I know this place might be a little biased, but I just am wondering what makes supabase actually better.
My app currently uses auth, firestore, and i would like to use functions but those are paid only on firebase and I'm not ready to buy a paid plan if I might switch to supabase.
So, my question is, is supabase pricing better for these? Are there any links so that I can see price comparisons for myself? And, does the supabase storage work just as real time as firestore? Additionally, one of things I like about firebase was its offline caching for firestore. Does supabase support that?
Thanks in advance everyone
4 Replies
Supabase gives you access to a relational database with no per query costs and ability to control the amount of data you get back. One column for instance instead of the entire row. The filters/sorting etc are much more robust.
Pricing is mainly on egress from the database and file storage along with a small cost for database storage. There are no ingress charges. You can see all this in the pricing comparison. You can also see the edge function free and cost for more there.
I left Firebase 2 years ago because the pricing was not going to pan out for filtering/searching note data as it was per row accessed. Also no textsearch was a big issue. Supabase realtime is not as rubust as Firebase realtime. It is a single filter (not query) on a table. You can have multiple tables/filter combos being monitored. There is no built in support for offline, you would have to handle this on your own. You can also self host if costs ever get out of control.
I left Firebase 2 years ago because the pricing was not going to pan out for filtering/searching note data as it was per row accessed. Also no textsearch was a big issue. Supabase realtime is not as rubust as Firebase realtime. It is a single filter (not query) on a table. You can have multiple tables/filter combos being monitored. There is no built in support for offline, you would have to handle this on your own. You can also self host if costs ever get out of control.
Thank you so much, I really appreciate all these answers so quickly
I took a look at the pricing, and hands down I would much rather use supabase's pricing than firebase. My only concern is that my app is built with the "key-value ideology" that firestore lends itself to, each user gets a doc where a bunch of arbitrary data is stored. Some keys store strings, some keys store objects, some numbers, etc.
From what I can tell supabase does not have this, it is purely a relational database. What is the standard way to store assorted user data like mine in supabase? Is it viable to create a table per user? Or is there a better way to do it?
I do love the pricing a lot more though, when I'm ready for production I will probably go with the pro plan and there is no way I would ever exceed 250gb egress, and no cost per query is amazing
I've always been relational database but went to Firebase as I wanted to escape managing my own servers. So I can't fully relate to the tie to key:data. But I had a notes database with free form json data some of it fixed and some variable based on what the user selects and the type of note. When I moved to SB I kept the entire note in a jsonb column for flexibility and ability to still search if I had to. But I split out 10 or so common or important search "keys" and also made them columns. Like "vintage", "varietal", "title" so they could be more quickly searched with indexed columns in a relational database fashion.
Also by going with this approach I can show a list of the key columns mentioned in a screen and do high performance searches (like on year, or title). All I download is those key columns so egress is low for the potential 100's of matches as the user filters. Then when they select a note, I download the entire 1 to 2k note jsonb data. This is what killed me on Firestore. I need all the matches for a filter to show the user their notes, but only need 100 bytes per note to display to them in the list. Firestore charged me for all match queries and all 2k of data per note,just to display a few columns like title and year.
I think I got a prototype of my app running with supabase mostly working. I wish I just started with supabase, this is way better. Now I don't have to constantly stress about minimizing reads and writes!
For the key value thing, since most of my data storage was just objects, I setup a few columns with type jsonb and some extra columns for the ones that weren’t objects. I also wrote a little helper class to retrieve data from the rows through a key value like api so I wouldn’t have to refactor my whole codebase
I’m sure there are better ways to do this but I’ll get there eventually, this is a good starting point