MongoDB vs Google Firebase: Which NoSQL Database Did We Choose?

Not-so-fun story: We built and launched CoursePilot (an anonymous coding bootcamp review platform) with Firebase Database and then, two weeks later, spent two days converting Google Firebase into MongoDB Database.

Why did we start with Firebase?

We started with Firebase because there were so many voices telling us that a small-scale website or application should start off with Firebase. Reason being that it’s an all-in-one solution and very quick to get going and build a prototype.

We listened and we regretted.

What we found was:

1. Yes, it's not too difficult to set up. But in terms of signing up and connecting to Firebase, there was nothing about it that was different to most modern NoSQL databases these days. Maybe it's marginally easier and quicker than MongoDB but, in our opinion, the initial 30 minutes or so saved is not worth the subsequent 2 days of conversion and migration.
2. The “all-in-one” solution is not strictly speaking an all-in-one, out-of-the-box solution. For example, if you wanted to store user information after using Google Authentication, for example, you’ll have to sign up to Google Cloud Functions, which is separate to Google Authentication and is an addition to Firebase Database. Moreover, it has a different pricing plan. The pricing plan within a pricing plan had our alarm bells ringing so we opted to not store user data and, thereby, not subscribing to Google Cloud Functions.
3. If you don’t use Google Authentication (in case you're wondering, we use NextAuth) and don’t sign up to Google Cloud Functions, it becomes quite difficult to write security rules for the database once you switch from test mode to production mode. And if you don’t have good security rules for your database, (i) it’s not great in terms of looking after your user’s data; and (ii) Google will stop users from being able to write to your database. Not ideal by any means or standard.
4. Visually, it’s not very easy to see the Firebase Database data. If you don’t have a custom ID for a document you’re adding to the database, you are invited to use the add() method, which assigns an auto-generated ID for you. Sounds good so far? Until you get to the database and see that each document is listed by the ID, and only when you click on the ID, you see relevant fields. This makes it very annoying if you wanted to quickly double-check something or to quickly fix a typo directly in the database.
5. If you then want to import or export data, you have to upgrade your plan and start paying.

Our Conclusion

Firebase does have a lot of advantages and for the two weeks that we had it up and running, it worked absolutely fine but, in our case, it wasn’t the right fit for us. It just felt like we were at risk of snowballing into more and more Google products, layered with paywalls.

So one rainy Monday in March, we began the journey of switching to MongoDB.

After switching to MongoDB, all of our headaches went away. For some reason, likely to be purely psychological, MongoDB felt more robust for us.

Of course, every application is different and what didn't work for us doesn't mean it won't work for you but we hope that this at least provides additional information before you make the ever-so-important decision of whether to start with Firebase or MongoDB when you're looking to integrate a NoSQL database.

And since at CoursePilot, we're all about honest reviews. Here's our one last, candid comment:

If you’re a startup or new business debating on whether to start with Firebase or MongoDB as your NoSQL database, we would personally recommend ignoring people’s advice of starting with Firebase at a minimum.

Some people even recommend starting with Firebase and migrating to MongoDB once you’re of a certain size. No, just jump in with MongoDB.

The hassle of switching databases is NOT WORTH IT. All that time you waste could be better spent elsewhere

We'd love to hear your thoughts on the MongoDB vs Firebase discussion. Which do you prefer?