Firebase 102: Breaking Down Firestore Tech

From understanding the emotions that drive consumer behavior to adding AR into the customer journey, our thinkers, makers and doers are constantly seeking new ways to innovate, learn and grow in order to create the best possible experiences for our clients. Want to learn more about your consumers, their habits and the motivations behind their decisions? Let us walk you through a MindSight demo with our Isobar Marketing Intelligence team. Interested in tactical technology implementations? We’ve got you covered with personal, one on one meetings with experts like Chris Steele. Send us a note to set something up. 

In the meantime, take a look at Part 2 of our Firebase series, where technical architect Chris Steele takes a deep dive into the Cloud Firestore database. His in-depth POV covers everything from how to set it up, to the ins and outs of SQL vs NoSQL. Follow along as we uncover everything you need to know… and more! 

Follow along with this series to learn more about:

  • Why Firebase should be considered along with other big names like AWS and Azure
  • What different key features of Firebase can afford your brand 
  • How Isobar can help your business with our own data optimization services and experts


In Part 1, I talked about the features of Firebase as well as how to set up your Firebase instance. In this article I’m going to talk about the first of those features, Cloud Firestore.  

Firestore is one of two NoSQL databases that Firebase offers. The other is the Realtime Database, however this one primarily exists for legacy users and shouldn’t be considered for a new NoSQL database.  

To set up your Firestore database, simply click on “Cloud Firestore” in the “Develop” menu in your Firebase dashboard. Then click the “Create Database” button. You’ll have to click next a couple times (the default options are fine) and then you’ll have a database you can start using. Like most things in Firebase, it really is “just that easy.”

Before we go too far into what we can do with this database, let’s first talk about the difference between a SQL and NoSQL database and why Firebase only offers the NoSQL option.

SQL stands for Structured Query Language, so it stands to reason that NoSQL stands for NO Structured Query Language  – and that’s sort of true. But it doesn’t mean that you can’t query the database, only that the database isn’t necessarily locked into a strict structure. You can think of a SQL database as a bunch of Excel sheets. Let’s call them tables. Each column has a name and stores a specific type of data (text, numbers, images, etc.). When you query this type of database, you can be assured of the structure of these tables and you can use that structure to create complicated queries linked across multiple tables.

In a NoSQL database we don’t have a collection of tables. Instead, it’s easier to think of the data as a collection of Word documents.  Each document can have the same format, but it’s not necessary. We can search for specific data in these documents, but what comes back isn’t going to be a nice table of data. Instead, it will be a list of documents. This gives us “unstructured” freedom where a SQL database does not.

Here is an example of a users collection with one user document.

So why use one over the other? Structure is good, right? Yes it is. And a NoSQL database still tends to be structured as a matter of convention.  All the documents in a specific collection tend to contain the same pieces of data. But storage is only part of the story when it comes to databases. How, and how often, data is written to and retrieved from the database is just as, if not more, important.  

SQL databases are designed to minimize the amount of space used to store the data, but at a cost of speed when retrieving that data.  In a SQL database, writes tend to be fast and reads tend to be slow. In a NoSQL database, the data is stored in a way to make reads fast at the cost of making writes slow, due to needing to validate and potentially repeat data across the different entries. That said, most apps and web pages spend far more time reading data than writing data, so having a database optimized for reads provides much better and more scalable performance.

So, NoSQL is fast for reads, but what about this “realtime” feature? Simply put, Firebase provides an easy way for your app (web or mobile) to listen to certain documents or collections inside of Cloud Firestore. And any time that data changes, your app will get notified and can update anything that depends on that data (the presentation of that data for example). This feature is supported in native iOS and Android, as well as javascript web and node.js.  

The code which gets called anytime the document named chris is changed in the users collection looks like this:

It really is just this simple (after you install/import the firebase SDK).

Accessing, modifying, and adding data to the Cloud Firestore database is easily integrated into all other Firebase features as well as external applications that have been granted access to the database. In the next article I’ll cover web hosting and we’ll look at how to set up a local development environment for easy testing and deployment.