Votre facture Firebase peut passer de 0 à 2 000 euros en une nuit
Firebase séduit par son plan gratuit et sa promesse de montée en charge sans effort. Mais le modèle du plan Blaze n'a aucun plafond de dépense par défaut : une seule requête mal optimisée et la facture Firestore s'envole. Le mot-clé firebase pricing est recherché plus de 500 fois par mois, souvent par des équipes qui viennent de recevoir une note salée.
Dans cet article, vous allez découvrir :
- •Comment fonctionnent vraiment les plans Spark et Blaze (et où se cache le piège)
- •Pourquoi les lectures Firestore sont le premier poste de coût qui dérape
- •Les 4 pièges de facturation qui transforment un projet gratuit en gouffre
- •Pourquoi Supabase, avec un prix prévisible et Postgres, revient souvent moins cher
Sur Firebase, ce n'est pas le stockage qui coûte cher, ce sont les millions de petites lectures que personne n'avait anticipées.
Firebase Spark et Blaze : les deux plans à connaître
Firebase propose deux formules. Le plan Spark est gratuit, le plan Blaze fonctionne au paiement à l'usage. Comprendre la différence est la première étape pour maîtriser son budget.
Le plan Spark (gratuit)
Le plan Spark offre des quotas fixes et gratuits. Tant que vous restez en dessous, vous ne payez rien. Il inclut notamment :
- •Firestore : 1 Gio de stockage, 50 000 lectures et 20 000 écritures par jour
- •Authentication : gratuit pour la majorité des fournisseurs
- •Hosting : 10 Gio de stockage et une bande passante quotidienne limitée
La limite arrive vite : le plan Spark interdit les appels réseau sortants dans les Cloud Functions et bloque certaines intégrations. Dès que votre application décolle, le passage sur Blaze devient obligatoire.
Le plan Blaze (paiement à l'usage)
Le plan Blaze conserve les mêmes quotas gratuits que Spark, puis facture chaque unité supplémentaire. C'est ici que tout se joue : il n'existe aucun plafond de dépense par défaut. Google vous laisse consommer autant que nécessaire, puis envoie la facture en fin de mois.
Voici les prix indicatifs des principales opérations Firestore sur Blaze (région us-central, hors taxes) :
| Opération Firestore | Prix indicatif |
|---|---|
| Lectures de documents | 0,06 $ / 100 000 |
| Écritures de documents | 0,18 $ / 100 000 |
| Suppressions de documents | 0,02 $ / 100 000 |
| Stockage | 0,18 $ / Gio / mois |
| Bande passante sortante | environ 0,12 $ / Gio |
Firestore : les lectures qui font exploser la facture
Firebase facture à la lecture de document, pas à la requête. Une seule page qui affiche une liste de 50 éléments, rechargée par 1 000 utilisateurs, génère 50 000 lectures. Multipliez par plusieurs écrans et un peu de trafic, et vous atteignez des millions de lectures par jour.
Le vrai danger vient des listeners temps réel. Un composant abonné à une collection relit les documents à chaque changement. Mal configuré, il peut relire l'intégralité d'une collection en boucle. Nous avons déjà audité des projets où 80 % de la facture provenait de lectures redondantes que personne n'avait remarquées.
Autre effet pervers : le modèle NoSQL de Firestore pousse à la dénormalisation. Pour compenser l'absence de jointures, on duplique les données, donc on multiplie les lectures et les écritures. Le coût technique devient un coût financier.
À lire aussi : Firebase ou Supabase : quelle alternative choisir en 2026 - le comparatif complet des deux plateformes, fonctionnalité par fonctionnalité.
Bande passante, Cloud Functions et stockage : les postes oubliés
Les lectures ne sont pas le seul piège. Trois autres postes gonflent la facture sans prévenir.
Cloud Functions
Chaque fonction est facturée sur trois axes : le nombre d'invocations, le temps de calcul (GB-secondes) et le trafic réseau sortant. Une fonction déclenchée à chaque écriture Firestore peut se multiplier de façon exponentielle. Ajoutez les cold starts qui rallongent le temps d'exécution, et le compute grimpe.
Bande passante sortante
Tout ce qui sort de Google Cloud est facturé. Servir des images, des fichiers ou des réponses d'API volumineuses depuis Firebase Storage se paie au Gio. Sur une application média, ce poste dépasse souvent le coût de la base de données elle-même.
Stockage et index
Firestore facture le stockage des documents, mais aussi celui des index. Or Firestore crée des index automatiques sur chaque champ. Sur de grosses collections, la taille des index peut dépasser celle des données.
Les 4 pièges de facturation Firebase
Au-delà des prix unitaires, la structure même de Firebase crée des risques budgétaires.
- 1.Aucun plafond de dépense réel. Les alertes budgétaires de Google Cloud notifient, mais ne coupent rien. Pour vraiment bloquer les coûts, il faut coder une Cloud Function qui désactive la facturation, une bricole que peu d'équipes mettent en place.
- 2.Les lectures en cascade. Listeners temps réel, rechargements automatiques et re-renders React mal maîtrisés multiplient les lectures à votre insu.
- 3.Le coût du multi-région. Passer en configuration multi-région pour la haute disponibilité multiplie certains coûts de stockage et de réplication.
- 4.Le vendor lock-in. Firestore est propriétaire. Migrer ailleurs demande de réécrire la couche de données. Ce coût de sortie est un coût caché que l'on découvre trop tard.
Pourquoi Supabase revient souvent moins cher
Supabase répond directement à ces problèmes avec un modèle différent : une base PostgreSQL classique et une tarification prévisible.
Un prix prévisible
Là où Firebase facture chaque lecture, Supabase propose un plan Pro à tarif fixe qui inclut des quotas généreux de base de données, d'authentification et de stockage. Vous connaissez votre facture à l'avance. Pas de mauvaise surprise en fin de mois.
La puissance de Postgres
Supabase repose sur PostgreSQL, une base relationnelle mature. Les jointures, les vues et les requêtes SQL évitent la dénormalisation forcée de Firestore. Vous lisez ce dont vous avez besoin, en une requête, sans multiplier les opérations facturées.
Pour comprendre en profondeur l'écosystème, la tarification et les cas d'usage, consultez notre guide complet sur Supabase, qui détaille chaque brique de la plateforme.
Chez ONDEV, nous construisons des applications SaaS en production sur cette stack. Wiloq, notre vestiaire numérique pour l'événementiel, tourne sur Next.js et Supabase avec plus de 12 fonctionnalités et trois interfaces. Une architecture Postgres qui reste lisible et dont le coût reste maîtrisé à mesure que le trafic monte.
Nous avons aussi livré des plateformes exigeantes comme Swap&Share (SaaS d'échange de compétences sur React, Node et Stripe) et une application métier pour Dassault Aviation utilisée par plus de 90 collaborateurs. Le fil rouge : choisir une architecture dont le coût reste prévisible dans la durée.
À lire aussi : Supabase : prix et tarifs détaillés en 2026 - tous les plans Supabase comparés, du gratuit à l'entreprise.
Si vous hésitez sur la technologie de votre futur produit, notre agence spécialisée Supabase vous aide à cadrer l'architecture dès le départ, avant que la facture ne devienne un problème.
FAQ : vos questions sur les prix Firebase
Firebase est-il vraiment gratuit ?
Pourquoi ma facture Firestore est-elle si élevée ?
Peut-on plafonner les dépenses sur Firebase ?
Supabase est-il moins cher que Firebase ?
Est-il difficile de migrer de Firebase vers Supabase ?
Firebase n'est pas cher, jusqu'au jour où il l'est
Firebase est excellent pour prototyper vite. Mais son modèle de paiement à l'usage sans plafond transforme le succès en risque financier : plus votre application marche, plus la facture dérape. Les coûts cachés (lectures Firestore, bande passante, Cloud Functions) se révèlent souvent trop tard.
Choisir une base Postgres avec un prix prévisible comme Supabase, c'est s'assurer que la croissance de votre trafic ne se traduise pas par une explosion de vos coûts. Encore faut-il concevoir l'architecture correctement dès le départ.
Vous voulez estimer le coût réel de votre projet et choisir la stack la plus rentable ? Demandez votre devis gratuit : nous auditons votre besoin et vous proposons l'architecture la plus prévisible pour votre budget.
