Comprendre la facturation de Realtime Database

Lorsque votre projet est associé au forfait Spark sans frais, l'utilisation de Realtime Database ne vous est pas facturée. Vous bénéficiez d'une utilisation sans frais qui inclut 1 Go de stockage de données et 10 Go/mois de téléchargements de données.

Si vous passez au forfait Blaze avec paiement à l'usage, vous conservez l'utilisation sans frais (1 Go de stockage de données et 10 Go/mois de téléchargements de données), et vous êtes facturé pour toute utilisation au-delà de ce montant. Lorsque votre projet est associé au forfait Blaze, nous vous recommandons de configurer des alertes de budget pour votre projet.

Le reste de cette page décrit la facturation plus en détail.

Comment Realtime Database calcule la facturation

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/mois, évalué quotidiennement. La facturation n'est pas affectée par l'emplacement de votre base de données. Le trafic sortant inclut les frais généraux de connexion et de chiffrement de toutes les opérations de base de données et des données téléchargées via les lectures de base de données. Les lectures et les écritures de base de données peuvent entraîner des coûts 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 règle générale, cela représente la majeure partie de vos coûts de bande passante, mais ce n'est pas le seul facteur de votre facture.
  • Frais généraux 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 : les frais généraux du protocole en temps réel de Firebase Realtime Database, les frais généraux WebSocket et les frais généraux d'en-tête HTTP. Chaque fois qu'une connexion est établie, ces frais généraux, combinés à tous les frais généraux de chiffrement SSL, contribuent aux coûts de connexion. Bien que cela ne représente pas beaucoup de bande passante pour une seule requête, cela peut constituer une partie importante de votre facture si vos charges utiles sont minuscules ou si vous établissez des connexions courtes et fréquentes.
  • Frais généraux de chiffrement SSL : des frais sont associés aux frais généraux de chiffrement SSL nécessaires pour les connexions sécurisées. En moyenne, ces frais sont d'environ 3, 5 Ko pour le handshake initial 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 petit pourcentage de votre facture. Toutefois, cela peut devenir un pourcentage important si votre cas spécifique nécessite de nombreux handshakes SSL. Par exemple, les appareils qui ne sont pas compatibles avec les tickets de session TLS peuvent nécessiter un grand nombre de handshakes de connexion SSL.
  • Firebase données de la console : 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 afficher vos connexions Realtime Database et votre utilisation des données actuelles, consultez l' onglet "Utilisation" de la console Firebase. Vous pouvez vérifier l'utilisation sur la période de facturation en cours, les 30 derniers jours ou les dernières 24 heures.

Firebase affiche des statistiques d'utilisation pour les métriques suivantes :

  • Connexions : nombre de connexions simultanées, actuellement ouvertes et en temps réel à 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. Les requêtes RESTful ne sont pas incluses.
  • Stockage : volume de données stockées dans votre base de données. Cela n'inclut pas Firebase Hosting ni les données 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 frais généraux de protocole et de chiffrement.
  • Charge : ce graphique indique la quantité de votre base de données utilisée pour traiter les requêtes sur un intervalle donné d'une minute. 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.

  • Utiliser les SDK natifs : dans la mesure du possible, utilisez les SDK correspondant à la plate-forme de votre application, au lieu de l'API REST. Les SDK maintiennent les connexions ouvertes, ce qui réduit les coûts de chiffrement SSL qui s'accumulent généralement avec l'API REST.
  • Rechercher 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 initialement. Pour identifier les problèmes, utilisez l'outil de profilage pour mesurer vos opérations de lecture et activer la journalisation de débogage dans les SDK Android, Objective-C, et Web. Vérifiez les processus d'arrière-plan et de synchronisation de votre application pour vous assurer que tout fonctionne comme prévu.
  • Réduire les connexions : si possible, essayez d'optimiser la bande passante de votre connexion. Les requêtes REST fréquentes et de petite taille peuvent être plus coûteuses qu'une seule connexion continue à l'aide du SDK natif. Si vous utilisez l'API REST, envisagez d'utiliser un événement HTTP "keep-alive" ou envoyé par le serveur, ce qui peut réduire les coûts liés aux handshakes SSL.
  • Utiliser des tickets de session TLS : réduisez les coûts de frais généraux de chiffrement SSL sur les connexions reprises en émettant des tickets de session TLS. Cela est particulièrement utile si vous avez besoin de connexions sécurisées fréquentes à la base de données.
  • Indexer les requêtes : l'indexation de vos données réduit la bande passante totale que vous utilisez pour les requêtes, ce qui présente le double avantage de réduire vos coûts et d'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.
  • Optimiser 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 aussi loin que possible dans le chemin d'accès pour limiter la quantité de données qu'ils synchronisent.
  • Réduire les coûts de stockage : exécutez des tâches de nettoyage périodiques et réduisez les données en double dans votre base de données.
  • Utiliser des règles : empêchez toute opération non autorisée 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 votre base de données entière à plusieurs reprises. En savoir plus sur l'utilisation des règles Firebase Realtime Database.

Le meilleur plan d'optimisation pour votre application dépend de votre cas d'utilisation particulier. Bien qu'il ne s'agisse pas d'une liste exhaustive des bonnes pratiques, vous trouverez d'autres conseils et astuces auprès des experts Firebase sur notre chaîne Slack ou sur Stack Overflow.