Back to top

Lotus Technologies

How To Scale Your Firebase Database

Today’s article may seem a little loaded for those uninitiated to firebase. But I’m going try my best to keep it simple. 

Firebase is one our favorite development tools. You can make really great apps and MVP’s without making a separate backend or REST API. And you can have real-time functionality immediately. (And for those of you that aren’t coders, please know these things take tens to hundreds of hours to develop depending on the application. ). 

But there’s a catch. 

Firebase’s perceived weakness is in it’s ability to scale. Seeing as firebase isn’t a database in the traditional sense, but rather a data store that you pay monthly for, scaling is ….different. 

If your app gets a lot traffic and/or user activity you can end up with a bill that’s bigger than you expected. There’s also genuine caps in how much activity an individual firebase instance can handle (see more on that here: https://firebase.google.com/docs/database/usage/limits). 

In our opinion, the inevitability of cloud space getting cheaper and cheaper will make firebase (and options like it) the winners of backend development. 

But until then, we’ll teach you techniques to scale your firebase application. 

Shard Your Database

Sharding your database sounds like a complicated and large task. But it’s simply a technique in which you host your application’s data across multiple databases.

What does this mean exactly? 

Well instead of making several collections/tables to compartmentalize your data. You compartmentalize your different kinds of data in entire individual databases. (For example, an entire firebase instance just for your user’s posts). 

Doing this brings down the total stress on your individual firebase instances by a lot! 

By keeping the stress contextualized and separate, you bring down large scale problems by a lot. 

Another large benefit is that depending on the current behavior of users, your bill will very likely go down by a good percentage. 

You can even keep your app free for a longer period in the earlier stages of your business with this same infrastructure. 

(It also allows you to better compartmentalize user activity for future analytics. ) 

Firebase has even recently released tools to help with this: https://firebase.google.com/docs/database/usage/sharding

Avoid Using Firebase Alone For Deep Relational Queries

After you’ve dispersed your infrastructure across multiple databases, 

you can start to further refine the load you’re putting on firebase.

What’s next? 

Well we have to get rid of all the excessive /complicated querying in the client if there’s any. 

One common mistake people mistake with firebase is abusing it. Firebase is still subject to the same limitations as the client in many ways. And it’s also a document based data-store, meaning it’s not too good querying “deep” within the data. 

Keep your data and their relations very flat. In the case of complicated functionality (for example: blocks of functionality that do very complex math, payment functionality), consider using a separate cloud backend to handle it if you think it would lag the user flow. 

Think of firebase as the memory of your app. And seek to create ways to do complex relational functionality without leaving it solely to firebase.

Some Additional Resources:

Check out this guide to getting started with firebase: https://firebase.google.com/docs/functions/get-started

Checkout this guide on sharding with firebase (by the firebase team themeselves!): https://firebase.googleblog.com/2017/11/easier-scaling-with-multi-database.html