If you’re considering using Firebase for your project here’s a list of pros and cons to help you make a decision.
For what it’s worth, I’ve been using Firebase for a long time both on personal and client projects and never ran into any limitations that made me regret the choice. But your context might be different.
For proof of concepts / minimum viable projects you’ll probably fit within the free tier. You’ll need to hit some serious usage numbers to even have to pay more than $100 / month.
And after you reach a high usage of your product (read: 10.000+ users) the costs are still reasonable. Unless of course you have some internal issues, like poor architecture choices or bugs in the code.
With Firebase, out of the box, you get: authentication, database, storage, analytics, push notifications, serveless computing (i.e. Firebase Functions) and many more.
To roll out your own solution would take a significant amount of time and specialized human resources. And then you’d have to manage the whole setup. Which leads me to my next point:
With Firebase it’s the engineers at Google that handle system uptime, security and scalability.
✅ geographical redundancy
✅ handle spikes in traffic (i.e. during a successful promotion)
✅ behind the scene updates & security audits to the servers
✅ enable database backups with one click
✅ you don’t have to worry about the backend going down at 4AM
That is an insane value you get compared to having to design and manage your own infrastructure.
note: just because the infrastructure is secure, doesn’t mean you can’t introduce vulnerabilities. You still need to be careful with the settings and your code.
Firebase makes it super easy to start and launch your products. The flip side of that is that your project is now dependent on one supplier: Google.
The major issue with vendor lock-in is that you have little power in the relationship. It’s either they’re way or the highway. If Google decides to kick you out for an arbitrary reason, then there’s little you can do about it.
If you follow good software architecture principles it’s going to be easier to get out of the grip of Firebase when the time comes. But it’s not going to be trivial.
Vendor lock-ins are a part of life unfortunately, and as far as vendors go, Google is quite friendly to it’s customers. So I wouldn’t worry too much about it, but at the end of the day it is a risk.
Not having control over the underlying servers might be an issue in some extremely rare use cases. This, though, only tends to be an issue for large corporations that are not squirmish about a 6 figures budget.
If your business needs are so complex, and you have such a large team of engineers that you can handle your specific use case better than Google Compute Platform, then Firebase is not the right choice for you.
This is probably the largest gripe developers have with Google. There’s even a online cemetery of sorts: https://killedbygoogle.com/.
For my money, Firebase is here to stay. It’s already a mature service and it’s making money for a long time.
Firebase ain’t going away anytime soon.
The only thing you absolutely need to make sure of is to monitor your spend on Firebase.
Under normal operations the price is super decent and comparable to other cloud vendors like AWS (which are not as easy to integrate and use in apps).
However, when there’s a bug, or a just a poor architecture decision, the ‘pay as you go’ pricing model of Firebase can cause immense costs on your business. There are plenty of horror stories on the internet of $10.000+ bills coming in because of a mistake.
The solution to this is either to set up billing alerts, or go the unofficial route and put a hard cap on your Firebase spending.