Building the Same App on Firebase and Supabase
This article may contain affiliate links. Its content is not affected by advertising.
In short
Firebase starts running with no configuration in exchange for little freedom over structure; Supabase gives you SQL-based control in exchange for a longer road to running at all.
v1 was Firebase
The first version was built on Firebase, for the simple reason that it is easy above all.
Both auth and the database run immediately with no difficult configuration. The distance to “get the app into shape and running” is the shortest. For a first step, or for the experience of finishing something that runs, that convenience is strong.
v2 was Supabase
I rebuilt the same app on Supabase, because I wanted to build more freely.
Supabase is SQL-based, and both the data handling and the structure are easier to control yourself. In exchange it is not “it just runs without thinking” the way Firebase is. There is more to decide.
But in the phase of building things out, that freedom becomes welcome.
How they divide
| Firebase | Supabase | |
|---|---|---|
| Speed to launch | fast | takes steps |
| Freedom over structure | none | yes |
| The stage it suits | get it running | build it out |
On ordering
What fitted best having actually done it was not trying to choose the right answer up front.
- v1 = Firebase … launch something running, for the convenience
- v2 = Supabase … requirements grew, so move to what can be built freely
Choose not on “which is better” but on which suits the stage you are at. Holding the premise that you will switch when requirements grow means not spending time on the first choice.
Switching was reimplementation, not migration
One honest note: moving to Supabase became a rebuild, not a port of existing code. The data models are thought about differently, so you redraw the design.
When thinking “I can move it later”, it is fair to hold the premise that the migration cost is a reimplementation cost. Even so, it is faster than stalling while trying to make a perfect first choice — that was the conclusion from doing both.
Frequently asked questions
Q1Should I choose Supabase from the start?
At the stage of wanting to see something running quickly, Firebase is the surer bet. Moving to Supabase at the point where requirements grow and you want to control the structure yourself was the order that fitted best in practice. Not trying to choose the right answer up front moves faster.
Q2How costly is the migration?
It became a rebuild of the same app. The data models are thought about differently, so rather than porting existing code you redraw the design. Closer to reimplementation than migration.
Q3Where does Supabase feel hard?
In not being "it just runs without thinking" the way Firebase is. Being SQL-based and letting you control the structure yourself means more things to decide. That becomes an advantage once you are in the phase of building things out.
What this article is based on
- Markdown file
Every claim in this article comes from the records above. The repositories we operate are private so we cannot link to them, but which file, which lines, and at which commit we read them is recorded for every article. Nothing here is written from guesswork.