Firebase Realtime Database vs Firestore: Which is better?

Firebase Realtime Database vs Firestore: Which is better?

They’re both Cloud Databases made by Firebase. They can both work in real-time, both offer offline support, so what’s the difference?

Firestore is nicer to work with because of its various data types. Since it’s built on GCP Cloudstore, it’s HIPPA compliant, unlike Realtime Database. (Thanks anater for this info).

Firestore stores data in documents, organised into collections, which can contain nested data in addition to subcollections. It’s much more scalable than the Realtime Database especially with increasingly complex data, and chaining filters on queries is much easier to perform. With the structure of Firestore, larger datasets can act as a single object in the hierarchy.

With Realtime Database however, each separate int or string (or other data) is another object in the hierarchy of the database. As data gets more complex, your database gets harder to manage. Not to mention, with Realtime, once you hit around 100,000 concurrent connections and 1,000 writes/second in a single database, no matter how expensive your pricing plan is, you’re going to need to shard your data across multiple databases.

So surely, Firestore must be better right? Well… not in all cases.

If you want a comprehensive list of comparisons of all the different features of both databases, the official docs list that better here.

What I’m going to talk about here is the ONLY case you would want to use the Realtime Database over Firestore… well, 3 cases, actually

Maybe it would have been more appropriate to title this “Reasons why you would want to stick to Realtime Database”… but I like this title better.

 

1. Realtime Database has a lower latency

It does, well, by about 500 milliseconds. Both databases read and write data very quickly, but Realtime Database is just that little bit faster. In most cases, Firestore will be well fast enough to suit your needs. Who really cares if you dashboard metrics are behind by 500ms?

But if you have an app where you simultaneously work on or use, say, a digital whiteboard, well then 500ms delay is an eternity. (Thanks pagerussell for this response).

2. Firestore gets more expensive with more read/write operations performed

Firestore may charge less than Realtime Database for bandwidth and storage, but it also charges you for operations performed on your database (read, write, delete, etc.). This could make it extremely expensive for apps like online multiplayer games, instant messengers, etc.

Are you starting to see the pattern yet? Realtime Database is just better for apps that work in Realtime. Who would’ve guessed?

Both databases have Spark (free), Flame, and Blaze plans by the way.

3. Realtime Database is just more reliable… for now at least

Realtime Database has been around for awhile. Thousands of apps continue to use Realtime Database. If you run into problems using Realtime Database, the community also has your back covered with questions already answered on communites such as Stack Overflow.

Firestore, on the other hand, is still a beta baby. It’s new, and you may encounter a few bugs here and there. They don’t occur often, and you may not experience them at all if you use Firestore now. If you need your database to be working reliably at 100% all the time, you may want to hold on until Firestore becomes fully fleshed out.

 

How about using both in one app?

Using both the Realtime Databases and Firestore in one app is actually a valid solution. Both have their clear advantages. While I think Firestore is a better all-around database, Realtime Database has a great specialised use, but hey. That’s just my opinion.

Using both databases won’t be too different from sharding your data across multiple databases but you can get the best of both worlds. Perhaps you can keep your long lists of user data in the neat documents of Firestore and keep only the “Realtime” data in the Realtime Database. It scales better, it’s more manageable, and the pricing can stay at its minimum.

The larger storage costs can be applied to Firestore where it’s cheaper. The majority of operations can then be performed on Realtime Database where there’s no cost for multiple operations.

I’m already using Realtime. Should I switch?

If your app already has Realtime Database implemented, I don’t highly recommend switching to Firestore. First of all, since their fundamentals and frameworks are too different, you’ll have to rebuild your database structure from ground-up.

You may however, see it as an investment if you think you’ll require the better scalability or need to make strong use of the improved querying of Firestore.

However opinionated it may be, this is what I as well as most other developers out there think. If you’re building a new app doesn’t need to make tons of data exchanges during its runtime, Cloud Firestore is definitely the go-to pick. Remember, Firestore is only on the verge of truly emerging out of its shell.

Don’t get confused with “Firebase Database”

I only found out recently that “Firebase Database” refers to the Realtime Database. It’s not a general term for both at the same time. Thanks to Abe Haskins for telling me this! Follow him on Twitter @abeisgreat.