It’s no news that Google has a thing for duplicating their products maybe for safety purposes as it looks more like a way of backing up their products just the same way people back up their data.

Examples in that regard would be the fact that they still actively maintain two operating systems ChromeOS and Android, two programming languages; Go and Dart, two chat applications- Allo and Hangouts amongst many others.

So when they announced the release of a new database that does the same almost exact thing as the Firebase Realtime Database in the early days of October 2017, they were not met with so much surprise as much as plenty “it’s about time”. This could be directly linked to the fact that there were already numerous outcries from developers who expected to see more improvements than firebase was willing to give, and rather than develop a new version of Realtime DataBase, they decided to redesign and build from scratch a totally new product.

Cloud Firestore was borne out of Google listening to what people had said about the Realtime database.

There’s a popular story of Firebase Realtime Database querying: If you’ve used Firebase before, you already know how that your Realtime Database is one large JSON data tree, and that there is no way to declare relationships like one-to-many or many-to-one.

Dealing with relations with NoSQL is hard, dealing with relations with Firebase is pain in the ass.

Firestore is the Google new database. A NoSQL ‘document’ database for Mobile and Web development.

Out of the many complaints about firebase, the one that seemed to stick out was the query problem. Since the Firebase Realtime Database is primarily a huge JSON tree where anything and everything goes, it therefore lacked structure. Even though since it is merely a database (technically a data store) querying should not really be a feature. But hey! The people want what they want.

Another problem that’s more of paranoia than probability (that’s if you do not take to consideration what happened with Facebook’s parse) is that firebase has only one server in the entire world at California. So, if the server is down, your beloved app is also down.

You would also think that Firebase being real time, which happens to be one of the major selling points, is all that great until you try to interact with it when you are not so interested in getting real time updates.

Also, although the Realtime Database does scale to meet the needs of most apps, it could start to get pretty difficult if your application becomes quite a demand or your dataset becomes really massive. So it seemed that firebase was laden with many cons than it had pros and Google took a step forward into addressing the issue by creating the newer Cloud Firestore. But what exactly is the difference? And how exactly does this work? And maybe when exactly do you need to use it for your app development? Let’s start with…

What Exactly Is the Difference? Some of the more important negative aspects of the older Firebase have been mentioned in the previous paragraphs but I would be doing a more detailed comparison of the two databases below.

To start with, since querying has been said to be a pain in the backside with firebase, let’s take a look at how Firestore makes the difference. Cloud Firestore supports a much more easy one-time fetch query in comparison to firebase. This is because as explained by Todd Kerpelman Google developer advocate in one of his blog posts, “queries are shallow” that is in firestore of course.

To explain it better, it is good to visualize a tree with branches that bears fruits that have seeds. This is because Cloud Firestore is a document –model database and this simply means that all of your data is stored in objects called documents that consist of key-value pairs. These values can contain any number of things like strings, floats, binary data and objects that look like JSON that are basically referred to as maps. These documents are also grouped into collections.

A model Cloud Firestore database will probably consist of a few collections that contain documents that point to sub collections. These sub collections will have documents that points to other sub collections and so on. Errm… okay, so how does this help with querying?

Well, the new structure provides you with lots of advantages when it comes to your ability to query your data. Since as mentioned above, all queries are shallow, you can just fetch a document without having to call for all of the data contained in any of the linked sub collections. This means you can store your data in a pyramid in a manner that makes sense logically without being bothered about downloading loads of unneeded data.

Also, Cloud Firestore has a much more powerful querying capability. In the Realtime Firebase trying to create a query across multiple fields was a whole lot of work and it sometimes involved denormalizing your data. This is no longer the case when it comes to Cloud Firestore, since in some cases, Firestore can automatically search across multiple fields. In other cases, Firestore will guide you towards automatically building an index required to make the query possible.

Remember the only one server situation I referenced above with Firebase? Well, Cloud Firestore is a multi-region synchronously replicated database. This means that immediately Google tells you your write is committed, if a terrorist act were to take out an entire region in our world, your data would be unaffected. Safe, sound and ready to be queried! This is possible because your data is automatically copied to multiple geographically separate regions all at once.

Also, Cloud Firestore is designed to scale. Even though the Realtime Database does scale, as mentioned above, it starts to experience difficulties when too much demand is placed on it for instance if the app becomes widely known. But its newer counterpart is built on top of the same Google Cloud infrastructure that powers some really popular apps. It has the ability to scale much more easily and it does this to a greater capacity in comparison to the Realtime Database.

This new structure enables all Firestore queries scale to the size of your result as opposed to the size of your data.

If you were ever wondering how the new pricing works with the new database, it’s a little different in comparison. For the Realtime Database, cost is determined based on the amount of data that is downloaded and the amount of data stored on the database. For the newer database however, while it still charges for the aforementioned, the pricing is quite lower and its pricing is driven by the number of reads or writes that is performed. This however determines when you decide to make use of Firestore. Since the pricing model is more favourable if the app in question is more traditional in its design like a news app where clients would occasionally request large chunks of data from the database.

However, if the app you have in mind will make use of very large numbers of reads and writes per second, per client, you are highly advice to stick to Firebase and the good news is you can use both databases simultaneously!

In another positive light, while the Realtime Firebase supports only Java, JavaScript and Objecctive-C, while the new data silo supports Go, Java, JavaScript, JavaScript (Node.js), Objective-C and Python.