Realtime Database FAQ and troubleshooting

What is a "simultaneous database connection"?

A simultaneous connection is equivalent to one mobile device, browser tab, or server app connected to the database. Firebase imposes hard limits on the number of simultaneous connections to your app's database. These limits are in place to protect both Firebase and our users from abuse.

The Spark pricing plan limit is 100 and cannot be raised. The Blaze pricing plan has a limit of 200,000 simultaneous connections per database.

This limit isn't the same as the total number of users of your app, because your users don't all connect at once. If you need more than 200,000 simultaneous connections, see options in Scale with multiple databases.

What are the scaling limitations of the Realtime Database?

Each Realtime Database instance has limits on the number of write operations per second. For small writes, this limit is approximately 1000 write operations per second. If you're approaching this limit, batching operations using multi-path updates can help you achieve higher throughput.

In addition, each database instance has a cap on the number of simultaneous database connections. Our default limits are large enough for most applications. If you're building an app that requires additional scale, you may need to shard your application across multiple database instances for added scale. You might also consider Cloud Firestore as an alternative database.

What can I do if I'm over my Realtime Database usage limits?

If you've received an email alert or notification in the Firebase console that you've exceeded your Realtime Database usage limits, you can address it based on the usage limit you've exceeded. To see your Realtime Database usage, go to the Realtime Database Usage dashboard in the Firebase console.

If you're over your download limit, you can upgrade your Firebase pricing plan or wait until your download limit resets at the start of your next billing cycle. To decrease your downloads, try the following steps:

• Add queries to limit the data that your listen operations return.
• Check for unindexed queries.
• Use listeners that only download updates to data — for example, on instead of once.
• Use security rules to block unauthorized downloads.

If you're over your storage limit, upgrade your pricing plan to avoid service disruptions. To reduce the amount of data in your database, try the following steps:

• Run periodic cleanup jobs.
• Reduce any duplicate data in your database.

It might take some time to see any data deletions reflected in your storage allotment.

If you're over your simultaneous database connections limit, upgrade your plan to avoid any service disruptions. To manage simultaneous connections to your database, try connecting users using the REST API if they don't require a realtime connection.

What happens if I exceed the Spark pricing plan storage or download limits for Realtime Database?

To provide you with a predictable price, the resources available to you are capped when your project is on the Spark pricing plan. This means that when you exceed any plan limit in any month, your app will be turned off to prevent any further resource usage and additional charges.

What happens if I exceed Spark pricing plan simultaneous connection limits for Realtime Database?

When your app reaches its concurrency limit on the Spark pricing plan, any subsequent connections will be rejected until some of the existing connections are closed. The app will continue to work for users who are connected.

What are automated backups? Do you offer hourly backups for Realtime Database?

Automated backups are an advanced feature for projects that are on the Blaze pricing plan. This feature backs up your Firebase Realtime Database data once a day and uploads it to Google Cloud Storage.

We don't offer hourly backups.

Why was my Realtime Database reported bandwidth lower than average between September 2016 and March 2017?

For bandwidth calculations, we normally include SSL encryption overhead (based on layer 5 of the OSI model). However, in September 2016, we introduced a bug that caused our bandwidth reporting to ignore encryption overhead. This might have resulted in artificially low reported bandwidth and bills on your account for a few months.

We released a fix for the bug in late March 2017, returning bandwidth reporting and billing to their normal levels.