Why I ditched Supabase and moved my backend to Firebase
Some time ago I wrote a story here on Medium, The perfect stack for SaaS, which a lot of people seemed to find useful. In the story, I suggested the use of Supabase for the backend. For me, the use of Backend-as-a-Service products to speed up development is still a no-brainer, and I’m still convinced of the approach. There’s not enough time in a lifetime to become experts in design, frontend and backend. I will gladly outsource that responsibility to a service that does that for me.
Instead of worrying about having an app running on your own server, and setting up each API request individually to do even simple CRUD operations, in a Backend-as-a-Service, the API is usually embedded in a simple NPM package that you import to your project. Once you do that, you can access all CRUD operations from an object like this:
const { data } = await supabase.from(‘projects’).select(‘id, name’);// This will print a list of comma-separated list of projects
console.log(‘All projects: ‘, data.map(el => el.name).split(", "))
BaaS tools also provide a nice, friendly visual interface to interact with your database, whereas if you worked with Express, Django, or any other backend framework you would need to do schema migrations and other stuff you don’t even want to know the purpose of.
Why I moved away from Supabase
At first, I advocated for Supabase over Firebase because it was open-source, it looked fresher and more lightweight. In my experience, Google’s frameworks often feel very disconnected from everything else out there. Take the complexity of Angular versus the immediacy of React, or Flutter, which even has its own programming language Dart, versus React Native. While other frameworks try to expand on concepts that are familiar to web developers, it looks like Google it’s always doing its own thing.
My most recent project was a little SaaS product to create and review flashcards, which I was developing based on my own needs while learning Spanish. Development was going fast and smooth, until one day, without anything having changed, I started getting an apparently random “Internal Server Error” upon signing in. A quick search redirected to an issue on Github and revealed that I was not the only one experiencing this, however, the developers themselves were clueless about what was causing the problem. This was annoying not only because it disrupted my development, but it also kept me from using the product, which I was actually using to learn.
This was just an episode of a series of outages that Supabase suffered in the past months. I concluded that if I could not trust it for the personal use of my own product locally, then definitely I couldn’t trust it for production. I was also feeling the need for a bigger community and documentation. I then made the commitment to switch to Firebase.
My refactoring experience
Refactoring (including learning how Firebase works), took about two weeks of working in my spare time outside my full-time job. The good thing is the documentation and the community around it are super extensive. The hardest part was definitely getting rid of unused imports related to Supabase without breaking anything. Replacing the API calls was also pretty tedious and the time it will take depends on how many you have.
One thing to note is that while Supabase comes with a Postgres database — which is relational — Firestore comes with a NoSQL database, so you might have to rethink a bit the way you store data.
I would actually love to see Supabase succeeding. I would much rather take the sides of an open-source product with a fresh vibe than those of Google.
Supabase might not be yet a viable option for production, but its future is looking bright since it recently announced a Series B investment of $80M, which more than triples the company’s total funding to date. That means that although I experienced problems, if you’re starting out with personal side projects it might be still worth going with Supabase. By the time you will be familiar with it and ready to deploy bigger projects hopefully it will be way more stable.
