Jamieson Bates's photo

In dealing with a firebase RTDB issue, where we experience frequent 100% load spikes, we have exhausted all the recommended debugging / resolutions strategies, including utilizing the profiler, Cloud Monitoring, DB sharding, query optimization, etc..

How can we scale firebase RTDB to meet our needs, or is it possible that we should migrate to another service? What are the hard limits on scalability for firebase?

Jamieson Bates's photo

Adding more context, given other replies in this Q&A. We need both ability to update small chunks of data frequently and capacity to handle large sets of small chunks of data.

Frank van Puffelen's photo

Each Realtime Database instance is essentially running as a single-threaded process on our servers. The load that you see in the usage chart is an indication of how busy that thead is. This means that if you hit 100% sustained load, there's not much more you can do than reduce the amount of work you make the database do.

To scale the Realtime Database beyond that, you have to shard your data over multiple instances. This is one of the big differences between Realtime Database and Firestore: the latter handles scalability automatically for you, while with Realtime Database you'll have to think of it more yourself.

Coming up with a sharding strategy is something best done early in your data modeling phase, typically around the same time when you start thinking about how to secure access to the data. If you have a specific use-case and are wondering how to shard it, I'd always recommend posting to our firebase-talk mailing list as our team loves to think along with those.