Chapters

Hide chapters

Saving Data on Android

Second Edition · Android 11 · Kotlin 1.5 · Android Studio 4.2

Using Firebase

Section 3: 11 chapters
Show chapters Hide chapters

16. Usage & Performance
Written by Harun Wangereka

In the previous chapters, you learned how to work with the Firebase Realtime Database. Realtime Database is built to handle high-traffic apps. To work effectively with Realtime Database, you have to be aware of its usage and performance limits. This chapter covers just that.

In this chapter, you’ll cover the Realtime Database pricing model, general Realtime Database limits, reading and writing limitations and performance. You’ll learn how to measure and optimize performance and how to profile your database.

Pricing model

Realtime Database is free — but that’s only true up to a certain point. Visit the Firebase pricing page (https://firebase.google.com/pricing), and notice the text - “Start for free, then pay as you go.”. Firebase is designed to work for free for smaller startups or experimental projects, like the one you’ll build in this section. However, Firebase offers additional pricing plans too.

The Spark Plan is free and exists so that everyone can experiment and get their hands on Firebase, integrate it into their apps and see how it performs. The majority of the money that Firebase makes comes from big apps with lots of users. All of the products that Firebase has are included in all the plans that they offer. This means that you can try out any product you want for free.

When it comes to Realtime Database, the metrics that Firebase uses to decide how much to bill you for their services are:

  1. Simultaneous connections: You can have up to 100 simultaneous connections for free. This limit can’t be raised.
  2. Data storage: You can store 1GB of data for free. Data in this context is text data and 1GB of text data is an enormous amount.
  3. Downloaded data: You can download 10GB of data per month for free from Realtime Database.
  4. Databases per project: You’re not allowed to have multiple databases per project for free.

For more information about Firebase billing and how to optimize Realtime Database usage, check out the official Firebase billing guidelines (https://firebase.google.com/docs/database/usage/billing).

Limitations

As mentioned earlier in this chapter, Realtime Database is built to handle high-traffic apps, but it still has some limits. You’ll examine some of those limits next. In general, all of them apply to Realtime Database, not for the free plans alone.

Realtime Database allows you to have 100 simultaneous connections for free, but 100,000 simultaneous connections in a paid plan. This doesn’t mean that your app can’t have 100,000 maximum users because not all of your users are connected at once. Simultaneous connections are devices or other clients currently connected to the database.

A single database can approximately send 100,000 responses per second. Responses are anything that comes from the database, like reading operations, or broadcast.

When writing to Realtime Database, the maximum size of a single write event is 1MB. That write event includes already existing data at the location that you’re writing to plus the new data.

When it comes to the data in Realtime Database, the data is stored as a JSON tree, as you learned previously. The maximum number of child nodes must be less than 32 levels deep, the maximum length of the UTF-8 encoded key is 768 Bytes and the maximum size of the UTF-8 encoded string is 10MB.

Reading and writing operations are also limited. The size of the data stored in the database at a single location should be less than 256MB for a single-read operation. If you want to perform a read operation at a larger location, consider using data pagination with a query, shallow queries or backing up the data. The maximum time to run a single query is 15 minutes. The total number of cumulative nodes in a path that you want to listen to or query needs to be less than 75 million.

Realtime Database can handle 64MB per minute through simultaneous write operations on the database. The maximum size of a single write request is 16MB if you’re writing through the SDK and 256MB if you’re writing from the REST API.

To avoid those limits and scale your Realtime Database data, you can have your data divided across multiple Realtime Database instances. Since the limits mentioned above only apply to a single Realtime Database instance, this is a way to avoid them. Having multiple database instances also allows you to balance server load and improve performance. This concept is known as database sharding.

To learn more about Realtime Database limitations, visit the official Firebase documentation (https://firebase.google.com/docs/database/usage/limits). Learn more about scaling on the sharding page (https://firebase.google.com/docs/database/usage/sharding).

Performance

Monitoring

Realtime Database offers several ways to monitor database performance and find the source of eventual problems in your app. It offers the following tools that provide insight into performance data:

  1. Realtime Database Profiler tool.
  2. Firebase Console.
  3. Cloud Monitoring.

You’ll look into these tools next.

Realtime Database Profiler

One of the tools that Firebase provides is the Realtime Database profiler tool. This tool gives you an overview of reading and writing operations on the database in real-time, which includes information about the speed and operation payload size. The information doesn’t have any historical data, so don’t use it to estimate billing.

Firebase Console

Firebase console can also be a helpful debugging tool. The usage tab in the console gives you data about storage, bandwidth and simultaneous connections.

Console usages section
Console usages section

Cloud Monitoring

Firebase also offers Cloud monitoring. This has a granular approach to performance monitoring. It allows you to use the Metrics Explorer to see the individual performance, create diverse chart dashboards that display several combinations of performance metrics. It gives you ability to monitor your billed usage if you’re on the paid plan, and also contains useful metrics to monitor performance.

With cloud monitoring, you can create alerts when your Database metrics meet a certain threshold. This is very helpful as you’ll receive the alerts on your email as per your metric threshold settings.

To learn more about performance monitoring tools, check out the official page (https://firebase.google.com/docs/database/usage/monitor-performance).

Profiling

Database profiling is critical for finding bottlenecks or other issues that might be degrading the user experience. The Firebase command-line interface offers a variety of tools. One of these, the Database Profiling tool, analyzes the activity in the database over a specific period and generates a detailed report that you can use to troubleshoot the database performance.

The profiling results are split into three main categories: speed, bandwidth and unindexed queries. The speed category contains data about reading, writing and broadcast speed. The bandwidth category profiles database data consumption across incoming and outgoing operations. Finally, the unindexed queries category contains data about unindexed queries since those queries can be expensive.

Optimizing

The best way to optimize performance is to gather all of the data from the tools mentioned above. After you have gathered the data find out about best practices in the area that you want to improve and make changes accordingly.

Other ways of optimizing performance are, already mentioned, sharing data across multiple database instances and the following:

  • Build efficient data structures.
  • Index your queries.
  • Reuse SSL sessions.
  • Prevent unauthorized access.
  • Limit download by use of query-based rules.
  • Optimize connections.
  • Remove unused or duplicate data.
  • Ship scalable and easy to update code.
  • Improve listener efficiency.

The method you choose to optimize performance is entirely dependent on the results you get from the data gathered. With the data, you can check on the best practices for each metric.

To learn more about optimizing database performance, check out the official documentation on optimization (https://firebase.google.com/docs/database/usage/optimize).

Key points

  • Realtime Database is free up to a certain point.
  • Realtime Database is built to handle high-traffic apps but it has some limits.
  • Firebase provides you with tools that allow you to monitor, profile and optimize Realtime Database usage and performance.

Where to go from here?

In this chapter, you covered the usage and performance aspects of Realtime Database, which are critical to know for large-scale apps.

This chapter wraps up the Realtime Database part of this section. This is a good place to pause and revisit what you learned so far. Also, try to play with Realtime Database and check the official documentation to continue learning about what it can offer you as you build your apps.

In the coming chapters, you’ll learn about Cloud Firestore, which is another Firebase product that’s similar to Realtime Database.

Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2026 Kodeco Inc.