-
-
Notifications
You must be signed in to change notification settings - Fork 63
How I migrate from Firebase to Supabase safely
This page reflects my analysis on my current project using Firebase and my strategy to migrate to Supabase safely
Groceries Store app currently uses Firebase to store data and authentication feature. The app uses many SDKs from Firebase to get, sync data. Because data and authentication feature are not related, it is a good practice that we can migrate each part to Supabase separately.
Because app data does not depend on any authentication feature, it is fine to start from this part first to make sure the app still function. Supabase supports each module separately and allows developer to use each part instead of installing lots of unrelated dependencies. I will take advantage of this to migrate the app.
Currently, the app gets data from firebase and cache in the SQLite database. So right after the app has data, I will export data from this database as CSV files then upload to Supabase. By doing this, my data remains unchanged and the step is very simple.
For more details, see: Export and upload data from local SQLite database to Supabase
This comparison is created from my experience working with this project, from the very beginning with Firebase, to the moment I decide to migrate to Supabase When I started with Firebase, I already knew there is also a backend as a service-Supabase with less money for subscription if needed. I chose Firebase because it is stable and backed by Google. Moreover, another point that makes me made the decision of using Firebase is that the platform has a curated document with detailed guidelines, best practices and many active SDKs.
Because I want to use a backend to get information like products, categories and to store data like orders from user, the first and important feature I expect a backend-as-a-service should have is import and export data. These information are not changed frequently, but when I start with Firebase, I have to create lots of data and this limits me of creating more data for my app. The Json data import is a paid feature I know this is a trade off so I create them myself.
Dashboard of Firebase
During the development, I faced some issues regarding wrong data (my bad) that I made when created the data. The collection view on Firebase is aligned in tree type so it's quite hard to have an overview of our data in one collection at a glance. With tree view, one benefit that I observe is that the ability to see set of nested data value. This gives me a very quick information while working with reference type. Options for adding fields are also limited. Firebase only allows us to create one primary key which is the id and we can not create multiple primary key (maybe I'm wrong but its not visible when I started a collection) All types of each field are simplify, which I like it a lot because I only want to care if a field is a string, number or reference, concern about bigInt or other type of data is not really important.
We can not add auto-generated fields like default id
, created_at
or last_updated
as normal database management tools
SDKs
Firebase provides set of SDKs to handle use cases in the app like authentication, data storage and retrieval. Every SDK is shipped with a curated document and very easy to setup. However, when I start, most of them are implemented in chaining method style. This makes the code to be really complex for some basic usages. When add more exception, it might lead to many of nested level of code block
Documentation