I had the opportunity to chat with Liau Jian Jie, CTO & co-founder of Mobbin and talk about their migration from Firebase to SQL on Supabase earlier this year. Mobbin is a tool for designers to see and track UI flows from mobile applications to help with real-world inspiration for their own design work. I used it personally back when I was working on a location based mobile app at Asurion, and it was unbelievably helpful for pattern discovery.
I reached out to Liau after seeing this tweet from their Twitter account:
Not many companies have made this switch, and at Basedash we've been hearing a lot of requests to support Firebase in the future. We already support Supabase as well as any other Postgres databases, and even use it for all of our mock databases.
This post is not an endorsement of one database over the other, but as Supabase is the new kid on the block, and has a very active community, we thought it would be worthwhile to share the perspective of one team that's decided it was right for them.
Thanks again to Liau for taking the time to talk through his process and hope it's helpful to others debating the switch themselves.
Audio and transcript:
I work on Mobbin, where I pretty much lead all technical and engineering decisions over here. We're really small team actually, and we're based out of Singapore. So yeah, in the past, something more relevant to what you guys are doing is that we actually moved from Firebase.
At the same time, we relaunched the Mobbin.design product at the time. And the reason for that migration was because we hit some limitations on Firebase really while building that new iteration of Mobbin.design and we made the painful decision to drop whatever we were doing and start migrating over to Supabase.
It was really indexing, right? We have a very read-heavy kind of application, and so indexing is really important. The thing about Firebase is that if you want to do queries with relationships, you have to do a lot of round trips or you got to try to work around the limitations on the indexing, which is actually really limited and there are some hard limitations on indexing.
For example, there's a [fixed maximum number](https://firebase.google.com/docs/firestore/query-data/index-overview#indexing_limits) of composite indexes on Firebase. Whereas for Postgres, you can have as many indexes as you like, as long as you can just scale the underlying storage space of your database.
We hit a hard constraint that we couldn't work around on Firebase, while we were trying to build a better search experience. If you look at the new Mobbin, you can have very complex compound queries. You can look for screens that have buttons, sliders, and are also part of a sign-up flow or part of our settings flow. You can do all sorts of crazy complex operations, which, as a designer, is what you want to do.
You want to filter by category? What are all the finance apps doing for the login flow when they have a certain element on the screen? But with Firebase, we couldn't do that.
Pretty quick, actually.
I made the decision overnight because I couldn't really sleep. When we hit the hard constraint, well, it was basically a moment of chaos for us because we basically couldn't continue building the product. Like, if we can't build out the search experience to our specifications on Firebase, then we can't do anything.
Before that, I had already played with Supabase in my own free time. And within that same night, I pretty much figured it out how we could get the whole migration going.
It was a huge risk for sure. It's going to take up quite a bit of time, but we managed to put it on a timeline that could work within our launch period. And actually the upside was that with Supabase it was so much easier to work with.
There's nothing proprietary, it's just SQL. So if you're familiar with SQL, then it's going to be a breeze, even when it comes to, let's say access control. With Firebase they have this access control tab inside of Firestore and you have to learn that proprietary syntax to encode rules, like who can view what data.
But Supabase is just SQL. They're using this feature called role-level security to omit or include what information the end user can see, and this is just all SQL— so it's one language and it works for pretty much everything.
Maybe four to six weeks. Yeah, because we were building our features concurrently. So we were trying to balance shipping and also doing the migration.
I'd say the biggest challenge when migrating was actually validating the data before we could insert it into Supabase, because Firestore is NoSQL, and the adherence to the schema is not guaranteed by the database.
Usually you have this validation logic, but let's say if you're doing a migration, then you don't get that database provider relation on the database as well. You have to write up additional logic to perform the migration.
Mobbin has been around for two years, so our data is pretty dirty. We had to insert additional metadata here and there, and our migration script was pretty huge because we had to validate that data and make sure that we could fit them into a schema.
First off we had to understand how Supabase works. The good news is that is that it's completely open source.
You can just poke around into the database. If you're looking into the auth schema, you can see the entire table. It took a little bit to figure out how I can turn Firebase auth users into Supabase auth users, but that was pretty easy actually. The difficulty was things that are related to our application data.
We use this feature on Firebase—Firestore collections—and we had sub collections. Now the tricky part about Firestore collections is that if you do not have your preexisting schema in Firestore in a way that lets you conveniently perform compound queries that traverses the subcollections. It gets really difficult to actually pull out the data and associate it to the user and make it into Postgres rows. That was really a huge challenge. We had to do many round trips.
For example, when we were trying to migrate our "libraries" from the old Mobbin to this new Mobbin "collection" we had to first pull our user data and pull all the Firebase collections, then the users' subcollection, which is like an O(n*m) operation, so to pull that amount of data for 200,000 users took us like four hours—if we had one mistake in the migration, we have to redo it all over again.
That was a very painful process.
There are users who tried to migrate, but the difficult bits were really unique to our own scenario. So far the part where we migrated all of the user data, we actually open sourced that migration script, if you want to export your Firebase auth users, it's pretty simple. You can just download my migration script. The caveat is that though at Mobbin, we were lucky to not support password or phone sign ins, so we never had to migrate that.
ℹ️ You can access the migration script here: https://github.com/liaujianjie/firebase-to-supabase-auth-migrator
But if you have to migrate that it's a little bit trickier. If you're already migrating your users over from Firebase to Supabase and you're using password sign-in, you have to force your users to reset their passwords.
First of all the developer experience is just so much better. Way better.
And the fact that it is open source really makes it so much easier. I can poke into the codebase and see how everything works. And Supabase is built on top of Postgres, right? Which is really great. It is a great piece of software. You can do pretty much, most things that you ever need to without having to step into writing SQL views.
The next would be definitely performance. So if you remember using the old Mobbin, it would take five seconds for the page to load. Right now, it's almost instant, the whole page loads in less than a second.
Purely because it's SQL. Which is that whole decade of engineering expertise going to shaping Postgres to what it is today.
I think the confidence of scalability, that's the next one I would say is the biggest upside, which is now that we are on Postgres and on Supabase, we feel really confident to do much more complex operations and provide more value for our customers.
Oh, for sure. From NoSQL to SQL, it's much easier, right? First of all, you can avoid writing hacks or having to compromise. If you started using Firestore collections and you want to do complex queries, you'll find that, very quickly, you'd need to compromise on many things. You can either compromise on speed or you could choose to abuse the Firestore indexes just to get what you want.
Whereas with SQL, it's so much easier. If you're going to do relationships, they are so well-documented, and you get a lot more data types. You can also perform operations that are tailored to those data types. Also, you have access to all the Postgres extensions.
For example: Full-text search. That's something that's been pretty well explored in Postgres and obviously it's near native support, we have TS vectors.
Whereas with Firebase, you can't even do that. You have to use a third-party service, like Elastic Search or Algolia.
Honestly, not really. I don't regret it.
It was a huge sense of relief when we moved. Because it was just basically technical debt at that point in time.
Oh, yeah, for sure. But the thing is that it's hard to calculate it. Firebase also includes Firebase storage, at this point of time I'm not really sure what the pricing of Supabase is. They only charge for traffic and not for object storage.
💡 Followup from Liau: Turns out i was wrong about this one: https://supabase.io/pricing](https://supabase.io/pricing
In terms of the storage there is huge cost savings, and also for hosting the data itself. I would say the cost got reduced to a negligible cost.
I would say with NoSQL we started with Firebase because it was NoSQL and it really helped us launch a product really quickly.
When your product requirements are clear, then [SQL] is definitely the way to go. There's no point trying to maintain the shape of the data in runtime, the database can just do all the heavy lifting for you.
I would go straight to Supabase because the dashboard UI is great. You get the flexibility just with the dashboard. So I would say there's almost no reason with starting a new project on Firebase anymore now that we have Supabase.
I'll say to anyone out there who's trying to build a new product or who is thinking of investing in a database, between Firebase or Supabase, I say, just skip Firebase. Your investment in SQL or Supabase would pay off.
The headache of Firebase is just not worth it.
If your product isn't going to change much, if you don't intend to invest in the foundation layer, that is the database, then I think it's fine. You can just stick with Firebase.
But if you have an intention to scale to do much more complex operations, then definitely consider migrating over to some something that's SQL or Supabase.
And there's a huge community behind it, so you can always leverage on the community experience.
It was really helpful and I appreciate what you're working on and hope you the best. Hopefully we'll talk again soon!
Mobbin - The world's largest mobile app design reference library - https://mobbin.design/
GitHub - liaujianjie/firebase-to-supabase-auth-migrator - https://github.com/liaujianjie/firebase-to-supabase-auth-migrator
The Open Source Firebase Alternative | Supabase - https://supabase.io/
Firebase - https://firebase.google.com/
This video was transcribed and edited with:
Descript | All-in-one audio/video editing, as easy as a doc. - https://www.descript.com/
Technical database knowledge can be a hurdle. Education can go a long way, but the solution primarily lies in creating user-friendly databases.
A no-code SQL GUI is a user interface that allows you to interact with a database without using code—in the case of most relational databases, this would be Structured Query Language (SQL). No code SQL GUIs are an excellent way for both newbies and SQL veterans to speed up and simplify the process of querying data.
We’re no longer in the times when database manipulation, management, and interpretation were only to be done by admins. It's the 21st century, and both technical and non-technical users should be accommodated when planning database design and access.
An index is a data structure you can add to your SQL database that allows for quick retrieval of certain information. For example, if you have a database of names and phone numbers, an index might be created on the name column so that the database could quickly be searched for a particular student's phone number. You can think of this in the same way that a physical phone book works.
If you're working on a startup, chances are you've got a lot of internal tools that you've built or are in the process of building. And if you're like most startups, those tools are probably a hot mess. What tools will startups use in the next few years? We have a prediction on trends, tech, and emerging ideas in the space.
Refactoring our tables to be virutalized was a huge undertaking, with a huge upside. It sped up table performance by 500% and allowed Basedash to load tables that had previously caused the app to crash.
Internal tooling can be a quick solution to satisfy requirements for colleagues that lack the technical knowledge to build their own custom software. Let's look at how we can beyond simply viewing admin panels, audit logs, and simple CRUD operations -- and into the world of building for the end users that work alongside us each day.
There are many different types of internal tools that you can build. You might want to create a reporting tool for your marketing team, or maybe you need a way to quickly get customer data visible for your customer support team. Or, any number of business apps to help your colleagues manipulate data.
Inheritance is a design pattern commonly used in object-oriented programming which allows you to model entities that inherit certain properties or functions from a parent class. This can be incredibly useful for modeling entities which have multiple types, such as different types of activities to show in a feed.
You've built a solid DB, but your colleagues need to edit data without knowing SQL. Here's how to enabler them to make edits:
How we wrote our own utility with Typescript to take the Date primitive and transform it into a string for use inside of Basedash.
In customer support cases, we use Basedash to help get to the bottom of issues. With a bit of browsing, we can pull up Views, find user details, schema, table information, and take a look to see what the issue is.
A breakdown of the process of how the engineers at Basedash added the feature to allow workspaces to restrict signups based off of user email address.
Using our own product to query our databases speeds up our development time and gives us more opportunities to spot new ideas for features and improve our user's experience.
We recently added an easter egg to Basedash which shows ASCII art of our logo in the browser console. Here's how we we able to style our console.log message with CSS.
At Basedash we use Basedash itself for managing, adding, and removing feature flags for our product. These help use beta test new features, catch bugs, and get feedback before shipping new features.
There aren’t many designers out there who would advocate for working with less or no information about the product they’re building. We want to know who is using our product, what their motivations are, what kind of frustrations they might have, what work environment are they in, and what other tools...
Recently, we refactored our codebase at Basedash to fetch our server data with React Query and optimize our REST API calls in the process. The transition to React Query allowed for better code readability and the optimization of our API calls resulted in half the number of data fetching API calls...
Startups can use whatever tools they want to do their job. We're not burdened by legacy contracts, enterprise-wide procurements, existing monolithic workflows, or the burden of training hundreds or thousands of staff for a new tool. We can change workflows on a dime. We can try something new...
See how removing barriers can change the way your team works.
No credit card required