When your project is on theno-cost Spark pricing plan, then you're not billed foryour usage ofRealtime Database. You get no-cost usage that includes1 GB of data storage and 10 GB/month of data downloads.

If you upgrade to thepay-as-you-go Blaze pricing plan, then you maintain the no-costusage (1 GB of data storage and 10 GB/month of data downloads), andyou're now billed for any usage beyond that amount. When your project is on theBlaze pricing plan, we recommend setting upbudget alertsfor your project.

The rest of this page describes billing in more detail.

HowRealtime Database calculates billing

Firebase bills for the data you store in your database and all outbound networktraffic at the session layer (layer 5) of the OSI model. Storage is billed at$5 for each GB/month, evaluated daily. Billing is not affected by the locationof your database. Outbound traffic includes connection and encryption overheadfrom all database operations and data downloaded through database reads. Bothdatabase reads and writes can lead to connection costs on your bill. Alltraffic to and from your database, including operations denied by securityrules, leads to billable costs.

Some common examples of billed traffic include:

• Data downloaded: When clients get data from your database, Firebasecharges for the downloaded data. Typically, this makes up the bulk of yourbandwidth costs, but it isn't the only factor in your bill.
• Protocol overhead: Some additional traffic between the server and clientsis necessary to establish and maintain a session. Depending on the underlyingprotocol, this traffic might include: Firebase Realtime Database's realtimeprotocol overhead, WebSocket overhead, and HTTP header overhead. Each time aconnection is established, this overhead, combined with any SSL encryptionoverhead, contributes to the connection costs. Although this isn't a lot ofbandwidth for a single request, it can be a substantial part of your billif your payloads are tiny or you make frequent, short connections.
• SSL encryption overhead: There is a cost associated with the SSLencryption overhead necessary for secure connections. On average, this costis approximately 3.5KB for the initial handshake, and approximately tens ofbytes for TLS record headers on each outgoing message. For most apps, this isa small percentage of your bill. However, this can become a large percentageif your specific case requires a lot of SSL handshakes. For example, devicesthat don't supportTLS session ticketsmight require large numbers of SSL connection handshakes.
• Firebase console data: Although this isn't usually a significantportion ofRealtime Database costs, Firebase charges for data that you read andwrite from theFirebase console.

When your project is on the Blaze pricing plan,set up budget alerts using the console. You can use theBlaze plan calculator to estimate your monthly costs.

Be aware thatbudget alerts donot cap your usage or charges — they arealerts about your costs so that you can take action, if needed. For example, you might considerusing budget notifications to programmatically disableCloud Billing on a project.

Estimate your billed usage

To see your currentRealtime Database connections and data usage, check theUsagetab in theFirebase console. You can check usage over the current billingperiod, the last 30 days, or the last 24 hours.

Firebase shows usage statistics for the following metrics:

• Connections: The number of simultaneous, currently open, realtimeconnections to your database. This includes the following realtimeconnections: WebSocket, long polling, and HTML server-sent events. It doesnot include RESTful requests.
• Storage: How much data is stored in your database. This doesn't includeFirebase hosting or data stored through other Firebase products.
• Downloads: All bytes downloaded from your database, including protocoland encryption overhead.
• Load: This graph shows how much of your database is in use, processingrequests, over a given 1-minute interval. You might see performance issuesas your database approaches 100%.

Optimize usage

There are a few best practices you can employ to optimize your database usageand bandwidth costs.

• Use the native SDKs: Whenever possible, use the SDKs that correspond toyour app's platform, instead of the REST API. The SDKs maintain openconnections, reducing the SSL encryption costs that typically add up withthe REST API.
• Check for bugs: If your bandwidth costs are unexpectedly high, verifythat your app isn't syncing more data or syncing more often than you originallyintended. To pinpoint issues, use theprofiler tool tomeasure your read operations and turn on debug logging in theAndroid,Objective-C,andWebSDKs. Check background and sync processes in your app to make sureeverything is working as you intended.
• Reduce connections: If possible, try to optimize your connectionbandwidth. Frequent, small REST requests can be more costly than a single,continuous connection using the native SDK. If you do use the REST API,consider using an HTTP keep-alive orserver-sent events,which can reduce costs from SSL handshakes.
• Use TLS session tickets: Reduce SSL encryption overhead costs on resumedconnections by issuingTLS session tickets.This is particularly helpful if you do require frequent, secure connectionsto the database.
• Index queries:Indexing your datareduces the total bandwidth you use for queries, which has the double benefitof lowering your costs and increasing your database's performance. Use theprofiler tool tofind unindexed queries inyour database.
• Optimize your listeners: Add queries to limit the data that your listenoperations return and use listeners that only download updates to data — forexample,on() instead ofonce(). Additionally, place your listeners asfar down the path as you can to limit the amount of data they sync.
• Reduce storage costs: Run periodic cleanup jobs and reduce any duplicatedata in your database.
• Use Rules: Prevent any potentially costly, unauthorized operations onyour database. For example, usingFirebase Realtime Database Security Rules could avoid a scenariowhere a malicious user repeatedly downloads your entire database.Learn more aboutusing Firebase Realtime Database Rules.

Note about the profiler tool: The profiler tool doesn't accountfor network traffic. It only records an estimate of the application data sent inresponses. The profiler tool is intended to give you an overall picture of yourdatabase's performance, to help you monitor operations and troubleshoot issues,not to estimate billing. To learn more, seethe profiler tool documentation.

The best optimization plan for your app depends on your particular use case.While this isn't an exhaustive list of best practices, you can findmore advice and tips from the Firebase experts on ourSlack channelor onStack Overflow.