Tuesday 3 October 2017

Cloud Firestore for Realtime Database Developers

Todd Kerpleman
Todd Kerpelman
Developer Advocate

Hey, did you hear the big news? We just announced the beta release of Cloud Firestore -- the new database that lets you easily store and sync app data to the cloud, even in realtime!

Now if you're experiencing some deja vu, you're not alone. We realize this sounds awfully similar to another product you might already be using -- the Firebase Realtime Database. So if you're experiencing some deja vu, you're not alone.

So why did we build another database? And when would you choose one over another? Well, let's talk about what's new and different with Cloud Firestore, and why you might want to use it for your next app.

What's different with Cloud Firestore?

While our documentation covers all of the differences between the Realtime Database and Cloud Firestore in much more detail, let's look at the main differences between the two products. And we'll start with...

Better querying and more structured data

While the Firebase Realtime Database is basically a giant JSON tree where anything goes and lawlessness rules the land1, Cloud Firestore is more structured. Cloud Firestore is a document-model database, which means that all of your data is stored in objects called documents that consist of key-value pairs -- and these values can contain any number of things, from strings to floats to binary data to JSON-y looking objects the team likes to call maps. These documents, in turn, are grouped into collections.

Your Cloud Firestore database will probably consist of a few collections that contain documents that point to subcollections. These subcollections will contain documents that point to other subcollections, and so on.

This new structure gives you several important advantages in being able to query your data.

For starters, all queries are shallow, meaning that you can simply fetch a document without having to fetch all of the data contained in any of the linked subcollections. This means you can store your data hierarchically in a way that makes sense logically without worrying about downloading tons of unnecessary data.

In this example, the document at the top can be fetched without grabbing any of the documents in the subcollections below

Second, Cloud Firestore has more powerful querying capabilities than the Realtime Database. In the Realtime Database, trying to create a query across multiple fields was a lot of work and usually involved denormalizing your data.

For example, imagine you had a list of cities, and you wanted to find a list of all cities in California with a population greater than 500k.

Cities, stored in the Realtime Database

In the Realtime Database, you'd need to conduct this search by creating an explicit "states plus population" field and then running a query sorted on that field.

Creating a combined state_and_population field, just for queries

With Cloud Firestore, this work is no longer necessary. In some cases, Cloud Firestore can automatically search across multiple fields. In other cases, like our cities example, Cloud Firestore will guide you towards automatically building an index required to make these kinds of queries possible…

...and then you can simply search across multiple fields.

Cloud Firestore will automatically maintain this index for you throughout the lifetime of your app. No combo fields required!

Designed to Scale

While the Realtime Database does scale to meet the needs of most apps, things can start to get difficult when your app becomes really popular, or your dataset gets truly massive.

Cloud Firestore, on the other hand, is built on top of the same Google Cloud infrastructure that powers some pretty popular apps. So it will be able to scale much more easily and to a much greater capacity than the Realtime Database can.

And with the new querying structure, all Cloud Firestore queries scale to the size of your result set -- not the size of your data. This means that a search for the top 10 restaurants in Chicago for a restaurant review app will take the same amount of time whether your database has 300 restaurants, 300 thousand or 30 million. As one engineer here likes to put it, "It's basically impossible to create a slow query in Cloud Firestore."

At the start of our beta period, Cloud Firestore will already allow scaling to levels somewhat greater than that of the Realtime Database, although we are putting a few restrictions around things as we monitor how the database performs in more real-world situations. But look for Cloud Firestore to be able to expand automatically to ludicrous levels2 as we get out of the beta period and move closer to a general availability release.

Easier manual fetching of data

While some developers appreciated the real-time nature of the Realtime Database for building features like chat or enabling magical collaborative experiences, we found that many of our developers simply wanted to use the Realtime Database as a traditional, "Just fetch data when I ask for it" kind of service.

Although the Realtime Database does support this with .once calls, they can sometimes feel a bit unnatural to use and often play second-fiddle to the streaming methods within the SDKs. With Cloud Firestore, making simple one-time fetch queries is much more natural and is built as a primary use case within the Firestore API.

Of course, you can still add support for listeners, so that your clients have the ability to receive updates whenever you data changes in the database. But now you have the flexibility to retrieve your data however you'd like.

Multi-Region support for better reliability

Cloud Firestore is a multi-region database. This means that your data is automatically copied to multiple geographically separate regions at once. So if some unforeseen disaster were to render a data center -- or even an entire region -- offline, you can rest assured that your data is safe.

And for you database aficionados out there, we should point out that our multi-region database offers strong consistency (just like Cloud Spanner!), which means that you get the benefits of multi-region support, while also knowing that you'll be getting the latest version of your data whenever you perform a read.

Different pricing model

The two databases have fairly different pricing models: The Realtime Database primarily determines cost based on the amount of data that's downloaded, as well as the amount of data you have stored on the database.

While Cloud Firestore does charge for these things as well, they are significantly lower than what you would see in the Realtime Database3. Instead, Cloud Firestore's pricing is primarily driven by the number of reads or writes that you perform.

What this means is that if you have a more traditional mobile app where your client is occasionally requesting larger chunks of data from your database -- think something like a news app, a dating app, or a turn-based multiplayer game, for instance -- you will find that Cloud Firestore's pricing model might be more favorable than if you ran the same app on the Realtime Database.

On the other hand, if you have an app that's making very large numbers of reads and writes per second per client (for instance, a group whiteboarding app, where you might be broadcasting everybody's drawing updates to everybody else several times a second), Cloud Firestore will probably be more expensive.4 At least for that portion of your app -- you can always use both databases together, and that's fine, too.

Of course these are just rough guidelines, make sure you check out the Pricing section of our documentation for all the details on Cloud Firestore pricing.

Why you still might want to use the Realtime Database

With this list of changes, you might come away with the impression that Cloud Firestore is simply better than the Realtime Database. And while Cloud Firestore does have a fair number of improvements over the Realtime Database, there are still situations where you might want to consider using the Realtime Database for some of your data. Specifically…

  • The Realtime Database will probably have slightly better latency. Usually not by much -- maybe a couple hundred milliseconds from the database to the client -- but if you're looking for a database with reliably low-latency updates to power an app that feels instant, you might prefer the Realtime Database.
  • The Realtime Database has native support for presence -- that is, being able to tell when a user has come online or gone offline. While we do have a solution for Cloud Firestore, it's not quite as elegant.
  • As we noted above, Cloud Firestore's pricing model means that applications that perform very large numbers of small reads and writes per second per client could be significantly more expensive than a similarly performing app in the Realtime Database.
  • Cloud Firestore is still a beta product. The Realtime Database has been available for four years and has been battle-tested by hundreds of thousands of production-level apps. Cloud Firestore has seen limited production usage over the last few months by several dozen apps. And while some of these apps -- like HomeAwayand Hawkin Dynamics -- are already out in the real world and performing quite nicely, there will likely be issues or edge cases with Cloud Firestore that we simply haven't discovered yet.

The tl;dr: Just tell me what to use!

In general, we recommend that most new applications start with Cloud Firestore, unless you think that your app has unique needs, like those we outlined above, that make it more suitable for the Realtime Database.

On the other hand, if you have an existing database that's already running just fine on the Realtime Database, go ahead and keep it there! If you find you're running up against issues where Cloud Firestore could really help you out, then you could consider switching, or moving part of your data to Cloud Firestore and using both databases together. But don't switch just for the sake of switching.

And if you're looking for a magic, "Please convert my database from the Realtime Database to Cloud Firestore" button, there isn't one5! And, frankly, we don't know if there ever will be. Given how different the database, querying, and pricing structures are between the two, blindly converting a database that's been optimized for the Realtime Database over to Cloud Firestore wouldn't necessarily be a great experience. We want you to be more thoughtful about making this kind of change.

Interested in getting started?

If you're interested in giving Cloud Firestore a try, there's a lot of places for you to get started. You can check out the documentation, play around with our sampleapps, try our interactive code labs, and maybe watch a getting started video or two.

There's a lot we think you'll be able to do with Cloud Firestore and we're excited to see what kinds of apps you're able to build with it. As always, if you have questions, you can hit us up on any of our support channels, or post questions on Stack Overflow with the google-cloud-firestoreand firebase tags. Good luck, and have fun!

Notes


  1. Subject to security rules, of course 

  2. Not an official term for database capacity… yet. 

  3. Something on the order of 27 times cheaper, in the case of data storage 

  4. As an aside, though, I've personally found that the new pricing structure makes it much easier for me to estimate my costs, which is nice. 

  5. Although we do have a very handy Migration Guide

Share:

0 comments:

Post a Comment