Migrating from Firebase to Supabase
Hey everyone,
Disclaimer: I'm new to Theo's Typesafe Cult
For the last couple of months I've been creating a web app using Nextjs (with page routing for now) , Typescript, Tailwind CSS and Firebase (hosting, auth, firestore, storage).
I'm very near having something usable, but now after seeing a few of Theo's YT videos I realized maybe Firebase wasn't the best choice.
I'm a data analyst with 10+ years of experience, where I've used SQL in many different databases or softwares like BigQuery, Teradata, SAS, even on pyspark; so moving into a relational database would actually make it easier for me, so I'm considering to move to Supabase.
My question to those more experienced in web dev is: would you recommend doing the migration now? or continue with the MVP on Firebase to test if it even has any value and if so then migrate?
I'm also based in Europe so I still need to research how Supabase goes with GDPR.
Any comments would be much appreciated!
6 Replies
I wouldn't say I'm super experienced in webdev, but I did write a fair amount of Firebase for a large project then switched to Supabase afterwards. Reflecting on my experience I think using the non-relational model of Firebase forced me to write a lot of code for more complex queries that could have been much more easily accomplished with Supabase/SQL. Perhaps I'd consider migrating earlier to keep from having to rewrite more code in the future, but also if the deployment timeline of your MVP is urgent then you might as well finish with Firebase and then do the migration later; although once you have real data on your Firestore DB it would be quite a pain moving it off
There are also Firestore frameworks like FireSchema and Typesaurus that will help give you some typesafety with your Firestore queries, although that may not help with your relational problem. I haven't used these myself so idk how good they are
ill add my app started in firebase and (like you) stayed there until i needed better querying
but ill quickly mention that i didnt really leave firebase. i just use it for the things its best at
cloud firestore is awesome for pushing application state directly from the db. cloud storage is more expensive than s3 but the security rules les you limit upload sizes without needing your own server. and firebase auth (while not as comprehensive as supabase) is wayyyy cheaper than pretty much any other option out there.
supabase has a ton more auth providers, but im happy with just 'sign in with google' for now since everyone has that. i believe its also significantly more expensive and the api is similar but not directly compatible
for storage supabase storage seems to be cheaper, but i think its still s3 based so you need to write a bunch of code to use pre-signed urls and things like that
and supabase claims to have 'realtime push with pg notifications' but they really only seem to support ~200 clients connected at once as far as i can tell
it also doesnt push app state, it just pushes transactions, which are much harder to work with IMO
oh and finally. supabase jumps in price from free to $25 per month, as opposed to google which just charges you for usage after you break the free tier
so my app keeps the queryable data / data that needs transactions in supabase. it then pushes app state to firebase to push it out to the clients. auth is in firebase and image storage is in firebase as well
thats just my app, but basically my point is that while i agree with theo that relational databases are generally a better choice, the firebase stuff has things that nobody else has
there is some vendor lock in to be concerned about, but most of the stuff is pretty easy to migrate. supabase has a way to import firebase users. storage can just be downloaded, and firebase has a backup process that allows you to download the whole db in a bulk zip
and ofc you can just query the data 1 object at a time like normal if you want to switch over incrememntally
anyway, thanks for coming to my TED talk
Haha thank you both so much for sharing your experiences! This is exactly what I was after, so I really appreciate it
Tbh there’s none other than myself pushing me to go live, and I didn’t want to make the migration an excuse for postponing the go live…
I think I will spend at least a week or two understanding what a migration will mean, experimenting on migrating smaller parts of the app and see how long it takes to change the code both in the front end and the hooks for the database rules, and evaluating the pros and cons, so thank you both @tcaputi and @IsoPhoenix for highlighting the pros and cons from your experience!
@tcaputi you mention the ~200 clients limit connected at once, and I believe they just launched supavisor (https://supabase.com/blog/supavisor-1-million) which allows up to 1M connections… so this might solve that issue?
Supabase
Supavisor: Scaling Postgres to 1 Million Connections
Supavisor is a scalable, cloud-native Postgres connection pooler. We connected a million clients to it to see how it performs.
I’ll have to look into it. I don’t see where they say explicitly this will help with the real-time stuff which is what my app needed
But I’m about to fall asleep on my phone so I might have missed it
Oh no my bad, I think I misread your comment, I only thought of the 200 connection but didn’t associate it with real time…
Anyways thanks again for sharing your experience, this gives me a lot to think about 🙌🏻