It should scale very well with certain kinds of traffic (reads and writes are not on shared objects).

Minimal, or no, knowledge of devops/sysadmin is necessary.

They now have decent tools to migrate your data out of it.

Why Not Firebase

Not a boring established technology.

You only get so many innovation tokens.

Your entire backend is proprietary (BaaS), owned and run by another company. If they shut down Firebase, you have to rewrite everything on their timeline instead of moving it.

This happened with a nearly identical service called Parse.

Parse was purchased by Facebook, then shut down. (Google bought Firebase but seems to be investing in it, and its replacement).

Google shuts things down all the time.

Firebase is somewhat deprecated in favor of Cloud Firestore.

Exceptionally expensive at scale compared to REST.

Not really possible to expose an API spec (swagger) with cloud functions.

Proprietary – complete lock-in:

Migrating off means rewriting all backend tests and much backend code. This is more dangerous than “just” rewriting the code and not the tests, because the tests make sure you didn’t mess something up during the migration.

Firebase is pretty unique in the way you interact with the APIs and realtime components, making a frontend migration a massive ordeal also.

Impossible to develop the app without an internet connection.

Security and data validation setup is tricky, and it cannot be unit tested.

Security and data validations are strings in a JSON file.

Must run security integration tests against a deployed app.

Having your main database public is a highly discouraged practice.

This may not be fully fair, but it is very easy to misconfigure things and expose data that shouldn’t be.

Normally databases are only listen on private interfaces or at least use IP restrictions.

You must duplicate any business logic across all systems that interact with firebase.

Strong anti-pattern for architecture and maintenance

Cloud functions are good for one-off tasks:

good for formatting a PDF invoice and sending it

good for processing a batch job

good for individual tasks delegated by a message bus

bad for a bunch of similar data update routes

bad for structuring and testing a large REST API

Unit testing firebase backend functions is way more complicated than a regular REST API.

Querying and aggregating are limited compared to SQL or popular NoSQL databases like MongoDB.

Transactions have some odd behavior – they might get “rerun” in the case of conflicts.

Database migrations are not supported at all.

red flag – basic service development

few band aid 3rd party open source solutions exist

means hand writing a migration framework that works with unit tests

Firebase recommends duplicating data because JOINs are unsupported.

red flag – architecture

not a problem in other NoSQL databases

this is a core competency of relational databases (SQL)

Integration with outside APIs and maintaining good testing is not simple like a regular server

stripe for example: need to expose backend webhook routes, test them pretty well

You are at the mercy of Firebase’s upgrade cycle.

If they decide to change or break something and force you to upgrade, you do not have a choice on the timeline, if there is one.

Optimized for realtime apps.

Only a downside if you don’t have a realtime app.

Many of the realtime benefits of Firebase can be had with a plethora of popular open source technologies.

Later services you write will likely not be written using firebase.

It reduces the surface area of your tech stack to pick a more boring database technology that will scale a long way and can be used for multiple services.

If you built your tech stack on say, Node.js or Go, each service would have similar paradigms.

With Firebase, now you have all the Firebase paradigms (coding, testing, build and deploying), plus your second service’s paradigms (coding, testing, build and deploying).

All these complaints are probably acceptable when you have a small mobile, a basic website or small ecommerce store, or something that will not grow beyond one server.

Building the core of a SaaS on Firebase, though, is not going to work. There are many blog posts about companies who hit a wall with Firebase, and eventually migrated off it. If you are building a SaaS, the question doesn’t seem to be if you will move off Firebase, but when.