Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Firebase facture les données que vous stockez dans votre base de données et tout le trafic réseau sortant au niveau de la session (couche 5) du modèle OSI. Le stockage est facturé 5 $ par Go et par mois, et évalué quotidiennement. La facturation n'est pas affectée par l'emplacement de votre base de données. Le trafic sortant inclut la surcharge de connexion et de chiffrement de toutes les opérations de base de données et des données téléchargées lors des lectures de base de données. Les lectures et les écritures de base de données peuvent entraîner des frais de connexion sur votre facture. Tout le trafic vers et depuis votre base de données, y compris les opérations refusées par les règles de sécurité, entraîne des coûts facturables.
Voici quelques exemples courants de trafic facturé :
Données téléchargées : lorsque les clients obtiennent des données de votre base de données, Firebase facture les données téléchargées. En général, cela représente la majeure partie de vos coûts de bande passante, mais ce n'est pas le seul facteur de votre facture.
Surcharge du protocole : un trafic supplémentaire entre le serveur et les clients est nécessaire pour établir et maintenir une session. En fonction du protocole sous-jacent, ce trafic peut inclure la surcharge du protocole en temps réel de Firebase Realtime Database, la surcharge WebSocket et la surcharge des en-têtes HTTP. Chaque fois qu'une connexion est établie, ce coût indirect, combiné à tout coût indirect de chiffrement SSL, contribue aux coûts de connexion. Bien que cela ne représente pas beaucoup de bande passante pour une seule requête, cela peut représenter une part importante de votre facture si vos charges utiles sont minuscules ou si vous établissez des connexions courtes et fréquentes.
Surcharge du chiffrement SSL : le chiffrement SSL nécessaire pour les connexions sécurisées entraîne un coût. En moyenne, ce coût est d'environ 3, 5 Ko pour la première prise de contact et d'environ quelques dizaines d'octets pour les en-têtes d'enregistrement TLS sur chaque message sortant. Pour la plupart des applications, cela représente un faible pourcentage de votre facture. Toutefois, cela peut représenter un pourcentage important si votre cas spécifique nécessite de nombreuses négociations SSL. Par exemple, les appareils qui ne sont pas compatibles avec les tickets de session TLS peuvent nécessiter un grand nombre de négociations de connexion SSL.
Données de la console Firebase : bien que cela ne représente généralement pas une part importante des coûts Realtime Database, Firebase facture les données que vous lisez et écrivez à partir de la console Firebase.
Estimer votre utilisation facturée
Pour consulter vos connexions Realtime Database actuelles et votre utilisation des données, accédez à l'onglet Utilisation de la console Firebase. Vous pouvez vérifier l'utilisation au cours de la période de facturation actuelle, des 30 derniers jours ou des dernières 24 heures.
Firebase affiche des statistiques d'utilisation pour les métriques suivantes :
Connexions : nombre de connexions simultanées en temps réel actuellement ouvertes à votre base de données. Cela inclut les connexions en temps réel suivantes : WebSocket, long polling et événements envoyés par le serveur HTML. Elle n'inclut pas les requêtes RESTful.
Stockage : quantité de données stockées dans votre base de données. Cette valeur n'inclut pas les données Firebase Hosting, ni celles stockées via d'autres produits Firebase.
Téléchargements : tous les octets téléchargés à partir de votre base de données, y compris les dépassements associés au protocole et au chiffrement.
Charge : ce graphique indique la part de votre base de données utilisée pour traiter les requêtes sur un intervalle d'une minute donné. Vous pouvez constater des problèmes de performances lorsque votre base de données approche les 100 %.
Optimiser l'utilisation
Vous pouvez appliquer quelques bonnes pratiques pour optimiser l'utilisation de votre base de données et les coûts de bande passante.
Utilisez les SDK natifs : dans la mesure du possible, utilisez les SDK qui correspondent à la plate-forme de votre application, plutôt que l'API REST. Les SDK maintiennent des connexions ouvertes, ce qui réduit les coûts de chiffrement SSL qui s'accumulent généralement avec l'API REST.
Recherchez les bugs : si vos coûts de bande passante sont anormalement élevés, vérifiez que votre application ne synchronise pas plus de données ou plus souvent que prévu. Pour identifier les problèmes, utilisez l'outil de profilage afin de mesurer vos opérations de lecture et d'activer la journalisation du débogage dans les SDK Android, Objective-C et Web. Vérifiez les processus d'arrière-plan et de synchronisation dans votre application pour vous assurer que tout fonctionne comme prévu.
Réduisez le nombre de connexions : si possible, essayez d'optimiser la bande passante de votre connexion. Les petites requêtes REST fréquentes peuvent être plus coûteuses qu'une connexion unique et continue à l'aide du SDK natif. Si vous utilisez l'API REST, envisagez d'utiliser un HTTP keep-alive ou des événements envoyés par le serveur, qui peuvent réduire les coûts liés aux négociations SSL.
Utiliser des tickets de session TLS : réduisez les coûts généraux de chiffrement SSL sur les connexions reprises en émettant des tickets de session TLS.
Cela s'avère particulièrement utile si vous avez besoin de connexions fréquentes et sécurisées à la base de données.
Requêtes d'index : l'indexation de vos données réduit la bande passante totale que vous utilisez pour les requêtes. Cela présente un double avantage : réduire vos coûts et améliorer les performances de votre base de données. Utilisez l'outil de profilage pour trouver les requêtes non indexées dans votre base de données.
Optimisez vos écouteurs : ajoutez des requêtes pour limiter les données renvoyées par vos opérations d'écoute et utilisez des écouteurs qui ne téléchargent que les mises à jour des données (par exemple, on() au lieu de once()). De plus, placez vos écouteurs le plus loin possible sur le chemin pour limiter la quantité de données qu'ils synchronisent.
Réduisez les coûts de stockage : exécutez des jobs de nettoyage périodiques et réduisez les données en double dans votre base de données.
Utilisez des règles : évitez toute opération non autorisée et potentiellement coûteuse sur votre base de données. Par exemple, l'utilisation de Firebase Realtime Database Security Rules peut éviter un scénario dans lequel un utilisateur malveillant télécharge à plusieurs reprises l'intégralité de votre base de données.
En savoir plus sur l'utilisation des règles Firebase Realtime Database
Le plan d'optimisation le plus adapté à votre application dépend de votre cas d'utilisation spécifique.
Cette liste de bonnes pratiques n'est pas exhaustive. Vous trouverez d'autres conseils et astuces auprès des experts Firebase sur notre chaîne Slack ou sur Stack Overflow.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/08/29 (UTC).
[null,null,["Dernière mise à jour le 2025/08/29 (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)."]]
