Should you use Firebase for your next project? It’s a question I’m quite familiar with, and one I hope to answer for others following in my footsteps. For those who are already familiar, go ahead and skip this post. For everyone who is still here, we’ll start with the basics.

What is Firebase?

Firebase is a realtime document store. Let’s think about what that means in comparison to other options, like Postgres and MySQL, both of which are relational database management systems (RDBMS). An RDBMS uses a table-oriented model. The schema of a table is defined by the table name and a fixed number of attributes with fixed data types. Operations are performed via database language commands, with SQL being the standard language. This should all sound pretty familiar to most readers.

Document stores like Firebase differ from RDBMSs in that they are document oriented rather than table oriented. Document stores use a schema-free organization system, meaning records don’t require a uniform structure and can be nested. If that doesn’t mean anything to you, consider a real world analogy:

Let’s say you have to keep track of cars on a dealer lot. The RDBMS model would be like having a spreadsheet, with defined columns for information about each car. You’d have columns for an ID (the primary key), vehicle name, category, model, fuel type, safety rating, and probably many other things. An equivalent document store model would be like having an individual document for each car on the lot, with the same information present on each document.
If you wanted to add new attributes to the table-based RDBMS you’d have to update the schema with new columns and their data types. You’d be making a new spreadsheet. If you wanted to add new information to the document-based model you’d just add a new key-value pair to the document.
The other defining characteristic of the relational (RDBMS) model is data normalization, where data is decomposed into smaller, related tables. Data is shared across multiple tables, resulting in less duplicates in the database, which is generally an advantage. Going back to our car lot analogy, we could separate cars and manufacturers into their own tables, thereby avoiding repeated information about manufacturers for each car produced by that manufacturer. This advantage of relational models is somewhat offset by the disadvantage of having to manage information changes across multiple tables. Spreading data across a rigid structure also makes changes more difficult once in production.
In a document oriented database we could create separate structures for both manufacturers and cars. We could then make a reference to the manufacturer document in the car document, thereby creating a relationship between the objects. The primary advantage of this approach is ease of updating the schema, which requires only updating the documents for a given object and can be done without any system downtime. The other major advantage of document oriented systems is the ease with which information can be spread across multiple servers.

Okay, I know what Firebase (and document stores in general) are. So when should I use it?

The short answer is that Firebase is a good choice for real-time applications, particularly applications that need scalability. Social media apps are a great example where something like Firebase is a good choice. Unfortunately, Firebase is part of Google Cloud. It is not open source, and you will have to pay. It can be a bad deal when you have a low number of users, but is actually a great deal if you have a large number of users, since it largely relieves you of having to hire back end developers to manage your infrastructure. If you anticipate many users, Firebase is a good choice.
RDBMS like Postgres are better suited to transactional, record keeping based applications. If you’re building an app to manage your client interactions, go ahead and use an RDBMS. Postgres, MySQL, and many other options are open source and can be used anywhere for free.
Lastly, if you’re just starting out as a developer, you should probably use an RDBMS and get familiar with how they work. It’s a core skill to have, and just because cloud platforms like Firebase are the future doesn’t mean the fundamentals are less important. If your app won’t see production, Firebase is a waste.