La tarification à la demande facture 6,25 $ par TiB de données scannées, avec le premier TiB gratuit mensuellement par compte de facturation. Plusieurs mécanismes affectent significativement la facture réelle au-delà de ce tarif affiché.
Vous payez pour les colonnes, pas les lignes
BigQuery utilise un stockage en colonnes, donc vous n’êtes facturé que pour les colonnes référencées dans votre instruction SELECT, pas pour toute la table. Une requête exécutant SELECT user_id, created_at FROM events ne scanne que ces deux colonnes, même si la table en a cinquante.
La sélection de colonnes est un levier de coût efficace : sélectionner uniquement les colonnes nécessaires peut réduire les coûts de 90 % ou plus sur des tables larges. SELECT * sur une table de 50 colonnes coûte 50 fois plus que la sélection d’une seule colonne du même type et de la même taille. Le modèle de coût découle directement de l’architecture — le stockage en colonnes signifie une facturation en colonnes.
Toute requête utilisant SELECT * sur des tables d’événements larges est candidate à une réduction des coûts.
La clause LIMIT ne réduit pas les coûts
Exécuter SELECT * FROM events LIMIT 10 scanne quand même toute la table. BigQuery lit toutes les données avant d’identifier les lignes à retourner — la limite s’applique après le scan, pas avant.
Il y a une exception : sur les tables avec clustering, BigQuery peut utiliser l’élagage au niveau des blocs pour sauter des blocs de données non pertinents en se basant sur les prédicats de filtre. Mais sur les tables non clusterisées, LIMIT ne génère aucune économie. Le modèle mental à retenir : vous payez pour ce que BigQuery lit depuis le disque, pas pour ce qu’il vous retourne.
Ajouter LIMIT 1000 à une requête exploratoire ne réduit pas le coût sur des tables non clusterisées.
Le seuil de facturation minimum de 10 Mo
BigQuery a un seuil de facturation minimum de 10 Mo par table référencée et 10 Mo par requête globalement. Exécuter des milliers de petites requêtes sur des petites tables accumule tout de même des coûts significatifs, car chaque requête est facturée comme si elle avait traité au moins 10 Mo.
En pratique, cela est surtout important pour :
- Les requêtes de métadonnées sur de petites tables de dimension
- Les requêtes de validation vérifiant quelques lignes
- Les micro-requêtes pilotées par API qui interrogent BigQuery à haute fréquence
Si vous exécutez des milliers de requêtes courtes quotidiennement sur de petites tables — courant dans les outils BI qui interrogent pour des données fraîches — le minimum de 10 Mo s’accumule rapidement.
Les résultats mis en cache sont gratuits
Les résultats des requêtes sont mis en cache pendant 24 heures lorsque les tables sous-jacentes n’ont pas changé. Les requêtes identiques (même SQL, même état de la table) servies depuis le cache n’entraînent aucun frais. La mise en cache est l’une des rares optimisations BigQuery véritablement gratuites.
Nuances importantes :
- Le cache est par utilisateur et par projet, pas partagé à travers l’organisation
- Les requêtes paramétrées avec des valeurs de variables différentes sont traitées comme des requêtes différentes
- Les requêtes utilisant des fonctions non déterministes comme
CURRENT_TIMESTAMP()ouRAND()contournent le cache - Les résultats mis en cache depuis un projet ne sont pas accessibles depuis un autre
Pour les outils BI exécutant des requêtes de tableau de bord identiques de manière répétée tout au long de la journée, la mise en cache apporte des économies substantielles sans aucune modification de code. Looker Studio, par exemple, utilise agressivement la mise en cache BigQuery pour les actualisations de rapports.
Le niveau gratuit
L’allocation gratuite se réinitialise mensuellement par compte de facturation, pas par projet :
- 1 TiB de requêtes traitées gratuitement par mois
- 10 Go de stockage actif gratuit par mois
- 2 TiB d’ingestion via Storage Write API gratuit par mois
- Le chargement par lots via le pool de slots partagé est toujours gratuit
Par compte de facturation, pas par projet — c’est important. Si vous avez dix projets sous un seul compte de facturation, ils partagent la même allocation de 1 TiB gratuite. Des comptes de facturation séparés obtiennent chacun leur propre allocation.
Le BigQuery Sandbox fournit les mêmes limites sans nécessiter de carte de crédit, bien que les tables expirent après 60 jours et que l’ingestion en streaming soit désactivée. Pour l’apprentissage et les preuves de concept, le Sandbox supprime entièrement la barrière de facturation.
Tarification multi-cloud (BigQuery Omni)
La tarification à la demande standard reste cohérente à 6,25 $/TiB pour les régions US, EU et la plupart des régions Asie-Pacifique. BigQuery Omni — qui interroge des données résidant dans AWS S3 ou Azure Blob Storage — coûte 9,125 $/TiB, une prime de 46 % pour les analytics multi-cloud.
Cette prime existe car BigQuery Omni doit transférer des données entre les frontières cloud et exécuter le compute dans un environnement étranger. Si vous utilisez Omni de manière intensive, cette différence tarifaire devrait influencer vos décisions de résidence des données. Déplacer les données vers le stockage natif BigQuery supprime la prime Omni et peut permettre des économies selon le volume de données et la fréquence des requêtes.
Notez que BigQuery Omni n’est pas disponible en édition Enterprise Plus — si vous avez besoin de requêtes multi-cloud et souhaitez une tarification par slots, Enterprise Edition est votre seule option.
Les erreurs ne vous coûtent rien, les résultats mis en cache non plus
Deux garde-fous à connaître : les requêtes qui retournent des erreurs ne sont pas facturées (BigQuery ne facture pas les travaux échoués), et les résultats de requêtes mis en cache n’entraînent aucun frais. Les deux sont véritablement gratuits dans le sens de la facturation, pas seulement “vous ne payez pas pour les données retournées” — il n’y a absolument aucun frais de compute.
Quand la tarification à la demande surpasse les Editions
La tarification à la demande est économique pour les charges de travail sporadiques, exploratoires et à faible volume. Aucune planification de capacité n’est requise, la facturation est par requête, et le niveau gratuit de 1 TiB en fait le point de départ par défaut pour les nouveaux projets BigQuery.
Le calcul du point d’équilibre donne le croisement quantitatif. Comme guide qualitatif : si les requêtes sont ad hoc, s’exécutent de manière imprévisible, et que le volume mensuel reste sous 10 TiB, la tarification à la demande est probablement moins chère. La fenêtre de facturation minimale de 60 secondes rend les Editions coûteuses pour les patterns sporadiques quel que soit le coût théorique en slot-heures.