A man comparing two apples

I made the same functionality with MongoDB Realm, Firebase, AWS Amplify and Supabase – This is what I learned

October 6, 2021

I've written about my quest to replace Firebase in my stack before. That quest led me to try MongoDB Realm about a year ago. I've since built the same functionality with AWS Amplify and Supabase.

Before I get started, let me say that this isn't a post about code because the code differences between them are minor, and by encapsulating external code, you can decrease the effort required to switch between them. So you won't see any snippets here. Instead, this post is about the overall experience in building with these services. Call it a quick review or comparison if you like. Now, read on to see what I learned.

What functionality?

The functionality I built was simple: add basic auth (email+password) to a site, connect the user record with an external customer record (stored in BigCommerce) and save some customer data.

That's it. Simple. Nothing fancy. But there were future considerations to keep in mind. For example, the solution had to scale well and handle potential relations and real-time data. It also had to be possible to integrate with a future native mobile app.

Let's take a closer look at each service I used.


Firebase was the first auth service with a real-time database I used; not only that; it's kind of the original real-time database as a service. I used Firebase early on, before Google acquired them, and believe me, I loved the service.

What's good about it?

The main selling point with Firebase is that it's easy to get started, and that's true. It's effortless to get set up with Firebase. A few lines of code and you have auth, another few and you have a real-time database.

What's bad about it?

But Firebase crumbles at scale. No, not with more users, but with more complex data requirements. A couple of years ago, I noticed this when I built a hobby project for a local sports tournament. Even though there were only four teams in the tournament and each team played each other once, the schema I had set up with references from games to goals and players made the UI very slow. Firebase doesn't resolve references and relations for you, you need to make another HTTP request for those, and if those have references of their own that you want to resolve... well, you can see why that would become slow for a stat heavy app. Not to mention that it will become very expensive at scale.


After that experience, I knew I couldn't rely on Firebase anymore. I couldn't trust a service that I had seen slow down to a near halt under relatively simple conditions. I wouldn't put clients or projects down a path of a potential bottleneck that needs to be fixed at one point or another.

MongoDB Realm

When I heard about MongoDB Realm, I was excited! I wanted to like that service. MongoDB was the first database I "got". You can query the database and resolve references between documents. The aggregate pipeline is quite powerful. But I had too many issues with the service, struggled to find help and found their pricing to be insincere; the pricing page shows a few examples of the cost of Realm but doesn't include the cost of MongoDB Atlas – a service that is required to be able to use MongoDB Realm. Atlas is a lot more expensive than Realm. So, by not including it in the pricing calculation examples they give a false pricing example.

What's good about it?

Realm uses MongoDB and provides a UI for you to define your document schemas. You can also define the schemas in code and deploy them using the Realm CLI. You get a GraphQL API you can use to query and mutate documents.

What's bad about it?

It's not as fast or easy to get started as Firebase. There's a dependency on MongoDB Atlas, and to be honest, I found it kind of clunky to manage the two services at times. However, those are minor problems in comparison to what my biggest issue was: finding help. I often found things that didn't work and lacked documentation. Trying to google the solution was futile. It either pointed to the documentation that I knew didn't have the answer or didn't return anything at all. I posted in the Realm forum, asking for help, but didn't receive a response until months later. By then, it was too late, and I had abandoned Realm.

I haven't seen many updates to the service over the year that I've followed it. The lack of activity makes it feel like it's a fish that's dead in the water. It's still floating around, but it's not going anywhere on its own.


The above may be a bit harsh and unfair. The forum seems to have had some more activity lately, but I feel like it may be too little too late. At least it is for this dev; I've moved on to other services.

AWS Amplify

AWS Amplify is AWS's answer to Firebase (which is owned by Google). This service has seen a lot of improvement over the past year. Although I wasn't even aware of it a year ago, I'd heard of AppSync but not Amplify. Admittedly, I'm not a fan of Amazon, so I don't keep a very close eye on their projects. But I had a client who was already on AWS, so it made sense to try Amplify.

What's good about it?

It's relatively easy to get started. Firebase still has Amplify beat on that, but it's not a big difference. You don't need a database to get started, and you can store some basic additional user data without provisioning a database. That's great for simple user metadata. In my case, I was able to store the BigCommerce customer id/ When you need a database, you can connect it to something like RDS, which gives you a database that can handle requirements at scale.

AWS Amplify is developed and driven forward by some very talented developers over at AWS, and they're great at making content that helps you get started with their features.

What's bad about it?

Aside from the fact that I'm not too fond of Amazon, it also keeps you in the AWS interface, which may be the worst UI of any of the big companies. The documentation is not bad, but it's not great either, aside from the tutorials mentioned above and blog posts.

I noticed that, just like other serverless services, it uses polling to attain that real-time feature. If your app is extremely sensitive to real-time data, it might not be a good solution for you, but for me, it made some functionality unusable. Not because I had some crazy real-time requirements. No, it was simply because each time Amplify polled the server, it would return a user object which, if I set up a listener and used to set the user in a context store in my React app, it would constantly re-render the app, causing side effects. You can get around that with memoization and custom comparisons, but that adds another step beyond "it just works".


Amplify was an excellent fit for my client. However, my feelings towards Amazon as a company prevent me from using it for personal projects and means I will continue to do my best to avoid the service. However, if I put my feelings towards Amazon aside, I can find both good and bad things. So far, out of the services mentioned until this point, it's the best. But that's about to change.


I can't remember how I found out about Supabase, but it might have been on Twitter. Supabase presents itself as The Open Source Firebase Alternative. That line is what made me curious, so I read up on it some more. I was a bit apprehensive at first since it was in beta (and I believe it's still in beta at the time of writing), but I tried it and was blown away.

What's good about it?

Supabase is almost as easy to get started with as Firebase, and when I say almost, I mean it. The thing that makes supabase slightly more complicated is setting up the database for additional user data. But the team has created a few cooking recipes that help you set up rules on your database. You quickly get the hang of it, and with some adjustments, you're off to the races.

What makes Supabase shine, however, is Postgres. A Postgres database backs every Supabase instance. That means two things:

  1. When you need help, there's plenty of information on the internet
  2. It truly scales

The team has put out a lot of updates since I started following them. They're building at a frantic pace.

What's bad about it?

They're still in beta, so some features are missing. Function triggers are probably the biggest ones for me. But there are some limitations during the beta, such as the two project limit and that you can only sign up using Github.


I will use Supabase for all my projects moving forward. It's already in a great state, and with the speed the team ships new features and improvements, it won't be long until they're out of beta and opening up their signup and scrap the project limit.


If you're looking for something as simple as Firebase but more capable, look no further than Supabase. You can even self-host the service anywhere you like, which beats all the other services mentioned in this article.

I prefer hosted services as it allows me to stay small and nimble and take on projects that would have been too big for me to tackle alone otherwise. It saves days of your time and the price you pay is well worth it.