Informazioni sulla fatturazione di Realtime Database
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Firebase fattura i dati che memorizzi nel database e tutto il traffico di rete in uscita
a livello di sessione (livello 5) del modello OSI. L'archiviazione viene fatturata a
$ 5 per ogni GB/mese, valutato giornalmente. La fatturazione non è influenzata dalla posizione
del database. Il traffico in uscita include l'overhead di connessione e crittografia
di tutte le operazioni del database e i dati scaricati tramite le letture del database. Le letture e le scritture del database possono comportare costi di connessione sulla fattura. Tutto
il traffico da e verso il tuo database, incluse le operazioni negate dalle regole di sicurezza, comporta costi fatturabili.
Alcuni esempi comuni di traffico fatturato includono:
Dati scaricati: quando i client ricevono dati dal tuo database, Firebase
addebita i dati scaricati. In genere, questa voce costituisce la maggior parte dei costi
della larghezza di banda, ma non è l'unico fattore della fattura.
Overhead del protocollo:per stabilire e mantenere una sessione è necessario un traffico aggiuntivo tra il server e i client. A seconda del protocollo sottostante, questo traffico potrebbe includere: overhead del protocollo in tempo reale di Firebase Realtime Database, overhead WebSocket e overhead dell'intestazione HTTP. Ogni volta che viene stabilita una connessione, questo overhead, combinato con qualsiasi overhead di crittografia SSL, contribuisce ai costi di connessione. Anche se non si tratta di una grande quantità di
larghezza di banda per una singola richiesta, può rappresentare una parte sostanziale della fattura
se i payload sono piccoli o se effettui connessioni brevi e frequenti.
Overhead della crittografia SSL:esiste un costo associato all'overhead della crittografia SSL necessario per le connessioni sicure. In media, questo costo
è di circa 3, 5 KB per l'handshake iniziale e di circa decine di
byte per le intestazioni dei record TLS su ogni messaggio in uscita. Per la maggior parte delle app, si tratta di
una piccola percentuale della fattura. Tuttavia, questa percentuale può aumentare
se il tuo caso specifico richiede molti handshake SSL. Ad esempio, i dispositivi
che non supportano i ticket di sessione TLS
potrebbero richiedere un numero elevato di handshake di connessione SSL.
Dati della console Firebase: anche se di solito non rappresentano una parte significativa dei costi di Realtime Database, Firebase addebita i dati che leggi e scrivi dalla console Firebase.
Stima dell'utilizzo fatturato
Per visualizzare le connessioni Realtime Database e l'utilizzo dei dati correnti, controlla la scheda
Utilizzo
nella console Firebase. Puoi controllare l'utilizzo nel periodo di fatturazione corrente, negli ultimi 30 giorni o nelle ultime 24 ore.
Firebase mostra le statistiche di utilizzo per le seguenti metriche:
Connessioni:il numero di connessioni in tempo reale simultanee attualmente aperte al database. Sono incluse le seguenti connessioni in tempo reale: WebSocket, long polling ed eventi inviati dal server HTML. Non include
le richieste RESTful.
Archiviazione:la quantità di dati archiviati nel database. Non sono inclusi
Firebase Hosting o i dati archiviati tramite altri prodotti Firebase.
Download:tutti i byte scaricati dal tuo database, inclusi il protocollo e l'overhead di crittografia.
Carico:questo grafico mostra la quantità di database in uso, elaborando
le richieste, in un determinato intervallo di un minuto. Potresti riscontrare problemi di prestazioni
quando il database si avvicina al 100%.
Ottimizzare l'utilizzo
Esistono alcune best practice che puoi utilizzare per ottimizzare l'utilizzo del database
e i costi della larghezza di banda.
Utilizza gli SDK nativi:quando possibile, utilizza gli SDK corrispondenti alla piattaforma della tua app anziché l'API REST. Gli SDK mantengono aperte le
connessioni, riducendo i costi di crittografia SSL che in genere si accumulano con
l'API REST.
Controlla la presenza di bug:se i costi della larghezza di banda sono inaspettatamente elevati, verifica
che la tua app non sincronizzi più dati o non esegua la sincronizzazione più spesso di quanto
previsto in origine. Per individuare i problemi, utilizza lo strumento Profiler per misurare le operazioni di lettura e attivare la registrazione di debug negli SDK Android, Objective-C e Web. Controlla i processi di background e di sincronizzazione nella tua app per assicurarti
che tutto funzioni come previsto.
Riduci le connessioni:se possibile, prova a ottimizzare la larghezza di banda della connessione. Richieste REST frequenti e di piccole dimensioni possono essere più costose di una singola connessione continua che utilizza l'SDK nativo. Se utilizzi l'API REST,
valuta la possibilità di utilizzare un keep-alive HTTP o
eventi inviati dal server,
che possono ridurre i costi degli handshake SSL.
Utilizza i ticket di sessione TLS:riduce i costi generali della crittografia SSL sulle connessioni riprese emettendo ticket di sessione TLS.
Ciò è particolarmente utile se hai bisogno di connessioni frequenti e sicure al database.
Query di indicizzazione:l'indicizzazione dei dati
riduce la larghezza di banda totale utilizzata per le query, il che ha il duplice vantaggio
di ridurre i costi e aumentare le prestazioni del database. Utilizza lo strumento
Profiler per trovare le query non indicizzate nel
tuo database.
Ottimizza i listener:aggiungi query per limitare i dati restituiti dalle operazioni di ascolto e utilizza listener che scaricano solo gli aggiornamenti dei dati, ad esempio on() anziché once(). Inoltre, posiziona i listener il più in basso possibile nel percorso per limitare la quantità di dati sincronizzati.
Riduci i costi di archiviazione: esegui periodicamente operazioni di pulizia e riduci i dati duplicati nel database.
Utilizza le regole:impedisci operazioni non autorizzate e potenzialmente costose sul tuo database. Ad esempio, l'utilizzo di Firebase Realtime Database Security Rules potrebbe evitare uno scenario
in cui un utente malintenzionato scarica ripetutamente l'intero database.
Scopri di più sull'utilizzo delle regole di Firebase Realtime Database.
Il piano di ottimizzazione migliore per la tua app dipende dal tuo caso d'uso specifico.
Anche se questo non è un elenco esaustivo di best practice, puoi trovare
altri consigli e suggerimenti degli esperti di Firebase sul nostro
canale Slack
o su Stack Overflow.
[null,null,["Ultimo aggiornamento 2025-08-23 UTC."],[],[],null,["\u003cbr /\u003e\n\nFirebase bills for the data you store in your database and all outbound network\ntraffic at the session layer (layer 5) of the OSI model. Storage is billed at\n$5 for each GB/month, evaluated daily. Billing is not affected by the location\nof your database. Outbound traffic includes connection and encryption overhead\nfrom all database operations and data downloaded through database reads. Both\ndatabase reads and writes can lead to connection costs on your bill. All\ntraffic to and from your database, including operations denied by security\nrules, leads to billable costs.\n\nSome common examples of billed traffic include:\n\n- **Data downloaded:** When clients get data from your database, Firebase charges for the downloaded data. Typically, this makes up the bulk of your bandwidth costs, but it isn't the only factor in your bill.\n- **Protocol overhead:** Some additional traffic between the server and clients is necessary to establish and maintain a session. Depending on the underlying protocol, this traffic might include: Firebase Realtime Database's realtime protocol overhead, WebSocket overhead, and HTTP header overhead. Each time a connection is established, this overhead, combined with any SSL encryption overhead, contributes to the connection costs. Although this isn't a lot of bandwidth for a single request, it can be a substantial part of your bill if your payloads are tiny or you make frequent, short connections.\n- **SSL encryption overhead:** There is a cost associated with the SSL encryption overhead necessary for secure connections. On average, this cost is approximately 3.5KB for the initial handshake, and approximately tens of bytes for TLS record headers on each outgoing message. For most apps, this is a small percentage of your bill. However, this can become a large percentage if your specific case requires a lot of SSL handshakes. For example, devices that don't support [TLS session tickets](https://tools.ietf.org/html/rfc5077) might require large numbers of SSL connection handshakes.\n- **Firebase console data:** Although this isn't usually a significant portion of Realtime Database costs, Firebase charges for data that you read and write from the Firebase console.\n\n| When your project is on the Blaze pricing plan, [**set up budget alerts**](/docs/projects/billing/avoid-surprise-bills#set-up-budget-alert-emails) using the console. You can use the [Blaze plan calculator](/pricing#blaze-calculator) to estimate your monthly costs.\n|\n| Be aware that **budget alerts do *not* cap your usage or\n| charges** --- they are *alerts* about your costs so that you can\n| take action, if needed. For example, you might consider\n| [using\n| budget notifications to programmatically disable Cloud Billing on a\n| project](https://cloud.google.com/billing/docs/how-to/disable-billing-with-notifications).\n\nEstimate your billed usage\n\nTo see your current Realtime Database connections and data usage, check the\n[Usage](https://console.firebase.google.com/project/_/database/usage/current-billing/)\ntab in the Firebase console. You can check usage over the current billing\nperiod, the last 30 days, or the last 24 hours.\n\nFirebase shows usage statistics for the following metrics:\n\n- **Connections:** The number of simultaneous, currently open, realtime connections to your database. This includes the following realtime connections: WebSocket, long polling, and HTML server-sent events. It does not include RESTful requests.\n- **Storage:** How much data is stored in your database. This doesn't include Firebase hosting or data stored through other Firebase products.\n- **Downloads:** All bytes downloaded from your database, including protocol and encryption overhead.\n- **Load:** This graph shows how much of your database is in use, processing requests, over a given 1-minute interval. You might see performance issues as your database approaches 100%.\n\nOptimize usage\n\nThere are a few best practices you can employ to optimize your database usage\nand bandwidth costs.\n\n- **Use the native SDKs:** Whenever possible, use the SDKs that correspond to your app's platform, instead of the REST API. The SDKs maintain open connections, reducing the SSL encryption costs that typically add up with the REST API.\n- **Check for bugs:** If your bandwidth costs are unexpectedly high, verify that your app isn't syncing more data or syncing more often than you originally intended. To pinpoint issues, use the [profiler tool](/docs/database/usage/profile) to measure your read operations and turn on debug logging in the [Android](https://firebase.google.com/docs/reference/android/com/google/firebase/database/Logger), [Objective-C](https://firebase.google.com/docs/reference/ios/firebasecore/api/reference/Enums/FIRLoggerLevel), and [Web](https://firebase.google.com/docs/reference/js/database#enablelogging) SDKs. Check background and sync processes in your app to make sure everything is working as you intended.\n- **Reduce connections:** If possible, try to optimize your connection bandwidth. 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 or [server-sent events](/docs/reference/rest/database#section-streaming), which can reduce costs from SSL handshakes.\n- **Use TLS session tickets:** Reduce SSL encryption overhead costs on resumed connections by issuing [TLS session tickets](https://tools.ietf.org/html/rfc5077). This is particularly helpful if you do require frequent, secure connections to the database.\n- **Index queries:** [Indexing your data](/docs/database/security/indexing-data) reduces the total bandwidth you use for queries, which has the double benefit of lowering your costs and increasing your database's performance. Use the profiler tool to [find unindexed queries](/docs/database/usage/profile#unindexed_queries) in your database.\n- **Optimize your listeners:** Add queries to limit the data that your listen operations return and use listeners that only download updates to data --- for example, `on()` instead of `once()`. Additionally, place your listeners as far down the path as you can to limit the amount of data they sync.\n- **Reduce storage costs:** Run periodic cleanup jobs and reduce any duplicate data in your database.\n- **Use Rules:** Prevent any potentially costly, unauthorized operations on your database. For example, using Firebase Realtime Database Security Rules could avoid a scenario where a malicious user repeatedly downloads your entire database. Learn more about [using Firebase Realtime Database Rules](/docs/database/security).\n\n| **Note about the profiler tool:** The profiler tool doesn't account for network traffic. It only records an estimate of the application data sent in responses. The profiler tool is intended to give you an overall picture of your database's performance, to help you monitor operations and troubleshoot issues, **not to estimate billing** . To learn more, see [the profiler tool documentation](/docs/database/usage/profile).\n\nThe best optimization plan for your app depends on your particular use case.\nWhile this isn't an exhaustive list of best practices, you can find\nmore advice and tips from the Firebase experts on our\n[Slack channel](https://firebase.community/)\nor on [Stack Overflow](https://stackoverflow.com/questions/tagged/firebase)."]]
