Le bon modèle de tarification BigQuery repose sur une distinction fondamentale : On-Demand facture les données scannées, tandis qu’Editions facture le temps de calcul. Cela détermine si vous optimisez l’efficacité I/O ou l’efficacité CPU, et se tromper peut signifier payer 2 à 3 fois plus que nécessaire.

Google a déprécié la tarification flat-rate en juillet 2023, introduisant trois niveaux Editions avec autoscaling basé sur les slots. Simultanément, le prix on-demand a augmenté de 25% pour atteindre 6,25 $ par TiB. Comprendre ces modèles (et savoir quand passer de l’un à l’autre) est devenu une connaissance essentielle pour quiconque gère les coûts BigQuery à grande échelle.

Ce guide fournit les chiffres concrets, les requêtes SQL et le framework de décision dont vous avez besoin pour évaluer votre propre situation. Que vous scanniez 5 TiB mensuellement pour de l’analyse ad-hoc ou que vous exécutiez des pipelines ETL de 50 TiB quotidiens, vous repartirez avec une réponse claire pour votre workload.

Comment fonctionne réellement la facturation On-Demand

La tarification On-Demand facture 6,25 $ par TiB de données scannées dans la plupart des régions, avec le premier TiB gratuit mensuellement par compte de facturation. Cela semble simple, mais plusieurs mécanismes impactent significativement vos coûts réels.

BigQuery utilise un stockage en colonnes, ce qui signifie que vous êtes facturé uniquement pour les colonnes référencées dans votre instruction SELECT, pas pour la table entière. Une requête exécutant SELECT user_id, created_at FROM events scanne uniquement ces deux colonnes, même si la table en compte cinquante. Cela fait de l’élagage de colonnes l’une des techniques d’optimisation des coûts les plus efficaces : sélectionner uniquement les colonnes nécessaires peut réduire les coûts de 90 % ou plus sur les tables larges.

Le seuil minimum de facturation est de 10 Mo par table référencée et 10 Mo par requête globalement. Exécuter des milliers de petites requêtes contre de petites tables accumule tout de même des coûts significatifs. Les résultats mis en cache n’entraînent aucun frais, et les requêtes retournant des erreurs ne sont pas facturées.

Le partitionnement et le clustering offrent l’autre levier majeur de coûts. Les requêtes filtrant sur les colonnes de partition ne scannent que les partitions pertinentes. Une requête contre une table partitionnée par date demandant les données d’un seul jour paie pour un jour, pas pour tout l’historique de la table. Le clustering permet l’élagage de blocs au sein des partitions, permettant à BigQuery de sauter les blocs de données non pertinents en fonction des prédicats de filtre.

Un comportement contre-intuitif : les clauses LIMIT ne réduisent pas les coûts sur les tables non clusterisées. Exécuter SELECT * FROM table LIMIT 10 scanne quand même des colonnes entières car BigQuery doit lire toutes les données pour identifier les lignes à retourner.

La tarification régionale reste constante à 6,25 $/TiB aux États-Unis, en Europe et dans la plupart des régions Asie-Pacifique. BigQuery Omni pour interroger AWS S3 ou Azure Blob Storage coûte 9,125 $/TiB (une prime de 46 % pour l’analytics multi-cloud).

Détails du Free Tier

L’allocation gratuite se réinitialise mensuellement par compte de facturation, pas par projet. Vous recevez 1 TiB de requêtes traitées gratuitement mensuellement, 10 GiB de stockage gratuit mensuellement, et 2 TiB d’ingestion via l’API Storage Write gratuits mensuellement. Le chargement batch utilisant le pool de slots partagé est toujours gratuit.

BigQuery Sandbox offre 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 l’expérimentation, Sandbox supprime entièrement la barrière de facturation.

Comprendre les trois niveaux Editions

BigQuery Editions a remplacé la tarification flat-rate par trois niveaux différenciés par fonctionnalités, SLA et options d’engagement. Les trois utilisent une tarification basée sur les slots, où un slot représente un CPU virtuel utilisé pour exécuter des requêtes. Contrairement au modèle par TiB d’On-Demand, vous payez pour la capacité de calcul indépendamment de la quantité de données scannées.

Le modèle basé sur les slots expliqué

Un slot est une unité de capacité de calcul. BigQuery détermine automatiquement combien de slots une requête nécessite en fonction de sa complexité et de sa taille. Les requêtes simples peuvent utiliser 10 slots ; les jointures complexes sur de grandes tables peuvent en consommer des centaines.

Avec Editions, vous configurez deux paramètres : un baseline (minimum garanti de slots, toujours facturé qu’il soit utilisé ou non) et un maximum (limite supérieure incluant la capacité d’autoscaling). L’autoscaler ajuste dynamiquement entre ces valeurs en fonction de la demande du workload.

L’autoscaling opère par incréments de 50 slots avec une fenêtre de facturation minimum de 60 secondes avant de réduire. Si votre workload a besoin de 101 slots, vous êtes facturé pour 150. Si une requête utilise 200 slots pendant 5 secondes, vous êtes facturé pour 200 slots × 60 secondes minimum. Ce comportement rend l’autoscaling plus rentable pour les workloads soutenus que pour les requêtes sporadiques.

Standard Edition : 0,04 $/slot-heure

Standard Edition cible les workloads de développement et l’analyse ad-hoc. À 0,04 $ par slot-heure, c’est le niveau Editions le moins cher mais il comporte des limitations significatives.

Le plafond strict est de 1 600 slots maximum par réservation. Vous ne pouvez pas acheter plus de capacité même si vous en avez besoin. Aucune remise d’engagement n’est disponible ; vous payez le tarif plein quelle que soit la durée d’utilisation. Le SLA est de 99,9 % de disponibilité mensuelle, inférieur aux autres niveaux.

Plus critique encore, Standard Edition manque de fonctionnalités que de nombreux analytics engineers considèrent essentielles. BigQuery ML n’est pas disponible (pas d’instructions CREATE MODEL pour entraîner des modèles de régression, clustering ou forecasting). L’accélération BI Engine est désactivée. Vous pouvez interroger les vues matérialisées existantes mais ne pouvez pas en créer de nouvelles ni bénéficier des optimisations de smart tuning. Les fonctionnalités de sécurité incluant les clés de chiffrement gérées par le client (CMEK), VPC Service Controls, le contrôle d’accès au niveau des colonnes et la sécurité au niveau des lignes nécessitent tous des niveaux supérieurs.

Standard Edition fonctionne bien pour les environnements de développement où vous avez besoin de coûts prévisibles et ne nécessitez pas de fonctionnalités avancées. Il n’est pas adapté aux workloads de production avec des exigences de sécurité ou des cas d’usage ML.

Enterprise Edition : 0,06 $/slot-heure

Enterprise Edition fournit des capacités production-ready à 0,06 $ par slot-heure en pay-as-you-go, avec des remises substantielles sur engagement : 0,048 $ pour les engagements d’un an (20 % d’économie) et 0,036 $ pour les engagements de trois ans (40 % d’économie).

L’ensemble de fonctionnalités est complet. BigQuery ML permet le machine learning in-database avec régression linéaire, régression logistique, k-means clustering, time series forecasting, matrix factorization et imports de modèles TensorFlow. BI Engine accélère les requêtes de tableaux de bord en mettant en cache les données en mémoire pour des temps de réponse inférieurs à la seconde. Les requêtes continues permettent le traitement d’événements en temps réel avec export vers Pub/Sub ou Bigtable.

Les fonctionnalités de sécurité incluent CMEK pour le chiffrement géré par le client, VPC Service Controls pour l’isolation réseau, la sécurité au niveau des colonnes et des lignes, et le masquage dynamique des données. Enterprise prend également en charge BigQuery Omni pour l’analytics multi-cloud contre AWS S3 et Azure Blob Storage.

Le SLA passe à 99,99 % de disponibilité mensuelle. Pour les workloads de production nécessitant fiabilité, sécurité ou capacités d’analytics avancées, Enterprise Edition est généralement le bon choix.

Enterprise Plus : 0,10 $/slot-heure

Enterprise Plus ajoute des capacités pour les industries réglementées et les exigences de disaster recovery à 0,10 $ par slot-heure, avec des remises d’engagement à 0,08 $ (un an) et 0,06 $ (trois ans).

Les fonctionnalités uniques sont le disaster recovery géré avec réplication inter-régions et les certifications de conformité Assured Workloads incluant FedRAMP, CJIS, IL4 et ITAR. Si vous opérez dans le gouvernement, la santé ou les services financiers avec des exigences de conformité strictes, Enterprise Plus peut être obligatoire.

Une exception notable : Enterprise Plus ne prend pas en charge BigQuery Omni. Si vous avez besoin d’analytics multi-cloud, Enterprise Edition est votre seule option Editions.

La taxe de l’autoscaling

Les coûts théoriques en slot-heures correspondent rarement aux factures réelles en raison du comportement de l’autoscaling. Les incréments de 50 slots et la fenêtre de facturation minimum de 60 secondes créent un overhead qui se compose sur de nombreuses requêtes.

Une règle empirique pratique : appliquez un multiplicateur de 1,5× aux coûts théoriques en slot-heures lors de l’estimation des dépenses réelles d’autoscaling. Les requêtes courtes et les patterns de burst engendrent un overhead significatif dû à la fenêtre de facturation minimum. Un workload nécessitant théoriquement 1 000 $/mois en slot-heures coûte souvent 1 400-1 600 $ en pratique.

Ce multiplicateur diminue pour les workloads soutenus fonctionnant en continu et augmente pour les patterns sporadiques avec de nombreuses requêtes courtes. Si votre workload consiste en des milliers de requêtes de 5 secondes, le multiplicateur pourrait être de 2× ou plus. Si vous exécutez des jobs ETL de 4 heures, il pourrait être plus proche de 1,2×.

Comparaison des fonctionnalités : ce que vous obtenez réellement

L’écart de fonctionnalités entre les modèles de tarification est plus important que la tarification ne le suggère. Cette matrice résume ce qui est disponible à chaque niveau :

On-Demand maintient la parité fonctionnelle avec Enterprise Plus pour la plupart des capacités sauf les requêtes continues et le disaster recovery géré. Les organisations utilisant On-Demand peuvent accéder à BQML, BI Engine, aux fonctionnalités de sécurité et aux vues matérialisées sans passer à Editions.

Cela signifie que le choix entre On-Demand et Editions porte principalement sur l’optimisation des coûts, pas sur l’accès aux fonctionnalités. Standard Edition, à l’inverse, échange des fonctionnalités contre un prix par slot-heure inférieur, un compromis qui n’a de sens que pour des cas d’usage spécifiques.

Le framework du point d’équilibre

La question fondamentale (On-Demand versus Editions) se réduit à comparer les coûts I/O aux coûts CPU pour vos workloads spécifiques. Un scan de données important avec des agrégations simples favorise On-Demand ; des transformations complexes sur des datasets plus petits favorisent Editions.

Calculer votre point d’équilibre

Exécutez cette requête contre vos propres données INFORMATION_SCHEMA pour comparer directement les coûts :

WITH cost_analysis AS (
  SELECT
    DATE_TRUNC(creation_time, MONTH) AS month,
    SUM(total_bytes_billed) / POW(1024, 4) * 6.25 AS on_demand_cost,
    SUM(total_slot_ms) / 1000 / 3600 * 0.04 * 1.5 AS standard_edition_cost,
    SUM(total_slot_ms) / 1000 / 3600 * 0.06 * 1.5 AS enterprise_edition_cost
  FROM `region-us`.INFORMATION_SCHEMA.JOBS
  WHERE
    creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 90 DAY)
    AND job_type = 'QUERY'
    AND statement_type != 'SCRIPT'
  GROUP BY month
)
SELECT
  month,
  ROUND(on_demand_cost, 2) AS on_demand_usd,
  ROUND(standard_edition_cost, 2) AS standard_usd,
  ROUND(enterprise_edition_cost, 2) AS enterprise_usd,
  ROUND(enterprise_edition_cost / NULLIF(on_demand_cost, 0) * 100, 1) AS editions_pct_of_ondemand
FROM cost_analysis
ORDER BY month DESC;

Le multiplicateur 1,5× tient compte de l’overhead d’autoscaling. Interprétez la colonne editions_pct_of_ondemand comme suit : si elle dépasse 75 %, On-Demand reste plus rentable (les économies du changement ne justifient pas le sacrifice de flexibilité). En dessous de 50 %, Editions offre probablement des économies significatives. Entre 50 et 75 % est une zone grise où d’autres facteurs (concurrence, prévisibilité, fonctionnalités) doivent guider la décision.

Scénarios concrets avec de vrais chiffres

Scénario A : ETL quotidien traitant 50 TiB

Considérons une équipe data exécutant des jobs ETL nocturnes qui traitent 50 TiB de données brutes en tables prêtes pour l’analytics. Les jobs s’exécutent pendant environ 4 heures avec un calcul soutenu.

Coût On-Demand : 50 TiB × 6,25 $ × 30 jours = 9 375 $/mois

Enterprise Edition avec 500 slots baseline fonctionnant 4 heures par nuit : 500 slots × 4 heures × 30 jours × 0,06 $ = 3 600 $/mois

Économies avec Editions : 62 %

Cela représente le sweet spot d’Editions : des workloads soutenus et compute-intensive fonctionnant sur des horaires prévisibles. Les jobs ETL utilisent les slots en continu pendant leur fenêtre d’exécution, minimisant l’overhead d’autoscaling.

Scénario B : Requêtes BI ad-hoc totalisant 5 TiB mensuels

Une petite équipe analytics exécute des requêtes exploratoires tout au long de la journée, scannant environ 5 TiB mensuellement sur diverses tables. Les requêtes sont sporadiques, des dizaines de courtes requêtes par jour plutôt qu’un traitement soutenu.

Coût On-Demand : 5 TiB × 6,25 $ = 31,25 $/mois (4 TiB après le free tier)

Standard Edition avec 100 slots maximum, en supposant 8 heures de requêtage actif quotidien : 100 slots × 8 heures × 20 jours × 0,04 $ = 640 $/mois

Vainqueur : On-Demand de 20×

Les workloads sporadiques et orientés exploration favorisent presque toujours la tarification On-Demand. La fenêtre de facturation minimum de 60 secondes rend Editions coûteux pour les workloads avec de nombreuses requêtes courtes.

Scénario C : Workload de production mixte

Une plateforme data mature exécute des modèles dbt planifiés (compute-intensive, timing prévisible), sert des tableaux de bord Looker (haute concurrence, sporadique) et supporte les requêtes ad-hoc des analystes (imprévisibles, exploratoires).

L’approche optimale est hybride : Enterprise Edition pour l’ETL planifié avec des slots engagés pendant la fenêtre de transformation, On-Demand pour les requêtes ad-hoc et les rafraîchissements de tableaux de bord de basse priorité. Assignez différents projets à différents modèles de tarification en fonction des caractéristiques du workload.

Au-delà des calculs de coûts purs

Plusieurs facteurs au-delà des calculs de point d’équilibre influencent la décision :

Les limites de concurrence diffèrent significativement. On-Demand permet environ 100 requêtes concurrentes partageant jusqu’à 2 000 slots du pool partagé. Editions fournit une capacité dédiée sans limites artificielles de concurrence, ce qui est critique pour les organisations exécutant des tableaux de bord servant des centaines d’utilisateurs simultanés. Si vous avez connu une mise en file d’attente des requêtes pendant les heures de pointe, la capacité dédiée d’Editions résout ce problème.

La cohérence des performances des requêtes favorise Editions pour les workloads de production. Les slots On-Demand sont “chauds” et instantanément disponibles mais partagés entre tous les clients Google Cloud. Pendant les périodes de pointe (fin de mois, vacances, événements mondiaux), vous pouvez recevoir moins de slots que prévu. Les réservations Editions garantissent votre capacité baseline configurée indépendamment de ce que font les autres clients.

La prévisibilité des coûts compte pour le budgeting. Les coûts On-Demand fluctuent avec les patterns d’utilisation ; une requête incontrôlée ou un volume de données inattendu peut faire grimper les factures de façon imprévue. Editions fournit des coûts baseline fixes plus des dépenses d’autoscaling bornées. Les équipes finance préfèrent souvent la prévisibilité des engagements basés sur les slots, même si le coût total est légèrement plus élevé.

La latence de l’autoscaler introduit un délai d’environ 10 secondes lors du scaling up depuis zéro ou depuis le baseline vers le maximum. Les requêtes On-Demand démarrent immédiatement avec la capacité disponible. Pour les requêtes ad-hoc sensibles à la latence où les utilisateurs attendent des résultats instantanés, cette différence peut impacter les performances perçues.

Requêtes SQL d’auto-évaluation

Avant de prendre toute décision de tarification, comprenez vos patterns de consommation actuels. Ces requêtes INFORMATION_SCHEMA fournissent les données dont vous avez besoin.

Identifiez vos requêtes les plus coûteuses

SELECT
  user_email,
  job_id,
  SUBSTR(query, 1, 200) AS query_preview,
  ROUND(total_bytes_billed / POW(1024, 4) * 6.25, 2) AS estimated_cost_usd,
  ROUND(total_slot_ms / 1000 / 3600, 3) AS slot_hours,
  TIMESTAMP_DIFF(end_time, start_time, SECOND) AS duration_seconds
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
  creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND job_type = 'QUERY'
  AND state = 'DONE'
ORDER BY total_bytes_billed DESC
LIMIT 25;

Cela révèle des opportunités d’optimisation. Les requêtes coûteuses bénéficient souvent du partitionnement, du clustering ou de la restructuration de requête quel que soit le modèle de tarification que vous choisissez. Corriger les cinq premières requêtes pourrait réduire votre facture de 30 % sans changer de modèle de tarification du tout.

Estimez les besoins en slots à partir de l’historique

WITH hourly_slots AS (
  SELECT
    TIMESTAMP_TRUNC(period_start, HOUR) AS hour,
    SUM(period_slot_ms) / 1000 / 3600 AS slots_consumed
  FROM `region-us`.INFORMATION_SCHEMA.JOBS_TIMELINE
  WHERE
    job_creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
    AND (statement_type != 'SCRIPT' OR statement_type IS NULL)
  GROUP BY hour
)
SELECT
  ROUND(APPROX_QUANTILES(slots_consumed, 100)[OFFSET(50)]) AS p50_slots,
  ROUND(APPROX_QUANTILES(slots_consumed, 100)[OFFSET(75)]) AS p75_slots,
  ROUND(APPROX_QUANTILES(slots_consumed, 100)[OFFSET(90)]) AS p90_slots,
  ROUND(APPROX_QUANTILES(slots_consumed, 100)[OFFSET(99)]) AS p99_slots,
  ROUND(MAX(slots_consumed)) AS max_slots
FROM hourly_slots;

P90 fournit un point de départ raisonnable pour la configuration du maximum de slots. Votre baseline devrait couvrir la charge soutenue, typiquement 60-80 % de P50 si vous voulez minimiser l’overhead d’autoscaling tout en maintenant l’efficacité des coûts.

Attribution des coûts par utilisateur

SELECT
  user_email,
  COUNT(*) AS query_count,
  ROUND(SUM(total_bytes_billed) / POW(1024, 4), 2) AS tib_processed,
  ROUND(SUM(total_bytes_billed) / POW(1024, 4) * 6.25, 2) AS estimated_cost_usd,
  ROUND(SUM(total_slot_ms) / 1000 / 3600, 2) AS total_slot_hours,
  ROUND(AVG(TIMESTAMP_DIFF(end_time, start_time, SECOND)), 1) AS avg_query_duration_sec
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
  creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND job_type = 'QUERY'
  AND state = 'DONE'
GROUP BY user_email
ORDER BY estimated_cost_usd DESC
LIMIT 20;

Cette requête permet le reporting de chargeback et identifie quels utilisateurs ou comptes de service génèrent le plus de coûts. Souvent, un seul job planifié ou quelques power users représentent 80 % des dépenses.

Analysez les patterns de requêtes par heure

SELECT
  EXTRACT(HOUR FROM creation_time) AS hour_of_day,
  COUNT(*) AS query_count,
  ROUND(SUM(total_bytes_billed) / POW(1024, 4), 2) AS tib_processed,
  ROUND(AVG(total_slot_ms) / 1000, 1) AS avg_slot_seconds
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
  creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND job_type = 'QUERY'
  AND state = 'DONE'
GROUP BY hour_of_day
ORDER BY hour_of_day;

Comprendre quand les requêtes s’exécutent aide à dimensionner les réservations Editions. Si 80 % du calcul se produit entre 2h et 6h pendant les fenêtres ETL, vous pourriez utiliser un baseline plus petit avec un autoscaling agressif plutôt que de payer pour une capacité qui reste inactive vingt heures par jour.

Surveillez la contention des slots post-migration

Après être passé à Editions, utilisez cette requête pour identifier les requêtes en attente de capacité :

SELECT
  job_id,
  user_email,
  ROUND(COUNTIF(period_estimated_runnable_units > 0) / COUNT(*) * 100, 1) AS contention_pct,
  MAX(period_estimated_runnable_units) AS max_queued_units,
  ROUND(SUM(period_slot_ms) / 1000 / 3600, 3) AS slot_hours
FROM `region-us`.INFORMATION_SCHEMA.JOBS_TIMELINE
WHERE job_creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
GROUP BY job_id, user_email
HAVING contention_pct > 50
ORDER BY contention_pct DESC
LIMIT 20;

Un contention_pct élevé indique que les requêtes passent un temps significatif à attendre des slots, un signal pour augmenter la capacité baseline ou maximum. Si la contention est constamment au-dessus de 30 %, votre réservation est sous-dimensionnée pour le workload.

Erreurs courantes de migration

Des anti-patterns de migration apparaissent systématiquement dans les expériences des praticiens. Éviter ces erreurs peut économiser des milliers de dollars et une frustration significative.

Sur-provisionnement des slots maximum

L’autoscaler scale agressivement vers le maximum configuré pour prioriser la vitesse des requêtes. Configurer max_slots à 1 600 parce que “les workloads de pointe en ont parfois besoin” résulte souvent en des requêtes routinières consommant bien plus de slots que nécessaire.

Une équipe d’ingénierie a rapporté leur expérience : quand ils ont configuré max_slots = 1600, BigQuery scalait fréquemment à 1 600 slots même pour des requêtes qui se seraient terminées raisonnablement avec 400. L’autoscaler optimise pour la vitesse, pas pour le coût. Seul le 99e percentile de leurs requêtes nécessitait réellement autant de capacité.

Commencez conservateur. Configurez le maximum de slots à votre utilisation historique P90, pas P99 ou le pic. L’autoscaler gère les bursts occasionnels de manière acceptable ; vous n’avez pas besoin de marge permanente pour chaque spike possible. Vous pouvez toujours augmenter le maximum plus tard. L’augmentation est instantanée, tandis que les engagements nécessitent une planification soigneuse.

Ignorer la fenêtre de facturation minimum de 60 secondes

Une requête de 100 slots se terminant en 5 secondes est facturée pour 100 slot-minutes, pas 8,3 slot-secondes. Cela rend Editions relativement coûteux pour les workloads consistant en de nombreuses requêtes courtes.

Si votre pattern est des milliers d’opérations sous-minute (outils BI interactifs, exploration de données, micro-requêtes pilotées par API), le minimum de 60 secondes gonfle dramatiquement les coûts comparés aux calculs théoriques. Soit vous batchez les petites requêtes ensemble, soit vous restez sur On-Demand pour ce workload, soit vous acceptez l’overhead comme le coût de la capacité dédiée.

Migrer sans optimiser les requêtes d’abord

Les requêtes inefficaces consommant des slots excessifs ne s’améliorent pas magiquement avec Editions. Elles consomment juste votre capacité réservée plus rapidement. Une requête scannant 10 TiB quand elle pourrait scanner 100 GiB avec un partitionnement approprié gaspille des slots tout comme elle gaspille des bytes.

Implémentez le partitionnement, le clustering et l’élagage de colonnes avant de changer. Réduire les bytes traités réduit aussi les slots requis. Le travail d’optimisation des requêtes paie des dividendes quel que soit le modèle de tarification, mais c’est particulièrement important avec Editions où vous payez pour la capacité de calcul qu’elle soit utilisée efficacement ou non.

Acheter des engagements avant de tester

Les engagements d’un an et trois ans offrent des remises substantielles (20 % et 40 % respectivement), mais ils vous verrouillent dans des configurations qui pourraient ne pas correspondre aux besoins réels. Un engagement acheté sur la base d’estimations s’avère souvent erroné en pratique.

Commencez avec l’autoscaling pay-as-you-go pendant 30+ jours. Surveillez les patterns réels de consommation de slots à travers différents types de workloads et moments. Identifiez votre vrai baseline (minimum soutenu) versus les besoins de burst. C’est seulement alors que vous achetez des engagements basés sur les données observées.

Si votre analyse montre que vous avez besoin de 200 slots baseline avec des bursts à 600, engagez-vous sur 150-200 slots et laissez l’autoscaling gérer le reste. La remise d’engagement sur les slots baseline plus le pay-as-you-go pour les bursts bat souvent l’engagement sur la capacité de pointe que vous utilisez rarement.

Faire passer tous les workloads par une seule réservation

Les jobs ETL, les tableaux de bord BI et l’exploration ad-hoc ont des caractéristiques fondamentalement différentes. L’ETL s’exécute sur des horaires prévisibles avec un calcul soutenu. Les tableaux de bord ont besoin de faible latence mais de capacité sporadique. Les requêtes ad-hoc sont imprévisibles en timing et en besoins de ressources.

Séparez les projets par type de workload pour appliquer les modèles de tarification appropriés. Considérez On-Demand pour les requêtes ad-hoc où les patterns sporadiques favorisent la tarification par TiB, et Enterprise Edition avec des slots engagés pour l’ETL planifié où le calcul soutenu favorise la tarification par slot.

Vous pouvez aussi créer plusieurs réservations au sein d’Editions, assignant différents maximum de slots et priorités à différents types de workloads. Cela empêche un job ETL coûteux d’affamer les requêtes de tableaux de bord interactifs.

Tester Editions sans engagement

Standard Edition fournit un chemin de test sans engagement. Créez une réservation avec 0 baseline et un maximum modeste, assignez un projet de test et exécutez des workloads représentatifs pendant 2 à 4 semaines :

-- Créer une réservation autoscaling-only pour tester
CREATE RESERVATION `my-project.region-us.test-reservation`
OPTIONS (
  edition = 'STANDARD',
  slot_capacity = 0,
  autoscale_max_slots = 200
);

-- Créer une assignation liant le projet de test à la réservation
CREATE ASSIGNMENT `my-project.region-us.test-reservation.test-assignment`
OPTIONS (
  assignee = 'projects/my-test-project',
  job_type = 'QUERY'
);

Les assignations prennent environ 5 minutes à s’activer. Les requêtes soumises pendant cette fenêtre peuvent retomber sur la facturation On-Demand, donc attendez la propagation avant d’exécuter les tests.

Surveillez les coûts et les performances pendant la période de test. Comparez la consommation réelle de slots à vos estimations pré-migration. Identifiez les workloads qui performent moins bien avec la tarification basée sur les slots.

Procédure de rollback

Le rollback est simple. Supprimez l’assignation et le projet retourne immédiatement à On-Demand :

DROP ASSIGNMENT `my-project.region-us.test-reservation.test-assignment`;

Le changement prend effet en quelques minutes. Il n’y a pas de pénalité pour supprimer des assignations, rendant le test essentiellement sans risque.

Forcer explicitement On-Demand

Pour les organisations où une organisation parente a des réservations Editions mais où des projets spécifiques ont besoin de la tarification On-Demand (peut-être pour l’allocation des coûts ou l’isolation des workloads), assignez à la réservation spéciale none :

CREATE ASSIGNMENT `my-project.region-us.reservations/none.explicit-ondemand`
OPTIONS (
  assignee = 'projects/exempt-project',
  job_type = 'QUERY'
);

Cela exclut explicitement le projet de toute réservation organisationnelle, assurant la facturation On-Demand indépendamment des configurations parentes.

Utiliser l’estimateur de slots de la Console

La Console BigQuery inclut un outil Slot Estimator (Capacity Management → Slot Estimator) qui modélise comment différentes configurations de slots maximum affecteraient les performances de workloads historiques. Entrez votre maximum de slots désiré et niveau d’engagement ; l’outil montre les coûts estimés et l’impact sur les performances basé sur votre historique réel de requêtes.

Cela fournit des conseils basés sur les données sans nécessiter de tests par essai-erreur. Utilisez-le pour valider vos besoins en slots avant de créer des réservations.

Changements récents affectant votre décision

Plusieurs développements 2024-2025 impactent la stratégie de tarification pour les utilisateurs BigQuery.

Calendrier de dépréciation du flat-rate

La dépréciation du flat-rate s’est terminée au 5 juillet 2023. Plus aucun achat de slots flat-rate, mensuel ou flex n’est possible. Les engagements annuels existants sont convertis en Enterprise Edition au renouvellement avec une capacité de slots équivalente.

Les organisations encore sur flat-rate legacy devraient planifier soigneusement leur transition. L’Enterprise Edition convertie offre des fonctionnalités supplémentaires (BQML, BI Engine, contrôles de sécurité) mais peut avoir des caractéristiques de coût différentes selon vos patterns de workload. Les comptages de slots se transfèrent directement, mais le comportement d’autoscaling diffère du flat-rate legacy.

Quota quotidien de 200 TiB (septembre 2025)

Un quota par défaut de 200 TiB quotidiens pour les projets on-demand prend effet le 1er septembre 2025. Les projets sans quotas personnalisés seront strictement limités à 200 TiB de traitement de requêtes quotidiennement.

Pour la plupart des organisations, cette limite est généreuse (200 TiB quotidiens c’est substantiel). Mais les workloads à haut volume, particulièrement ceux avec des requêtes inefficaces scannant de grandes tables de manière répétée, pourraient atteindre ce plafond. Le changement fournit une motivation supplémentaire pour évaluer Editions pour les patterns d’utilisation intensive où la tarification basée sur les slots supprime entièrement les limites par TiB.

Vous pouvez demander des augmentations de quota via le support Google Cloud, mais le défaut changera. Revoyez vos volumes de requêtes quotidiens pour comprendre si cela affecte vos workloads.

Frais Cloud Storage pour les tables externes (février 2025)

À partir de février 2025, Google a commencé à facturer des frais Cloud Storage précédemment non mesurés lors de l’interrogation de tables externes. Cela inclut les frais de récupération pour les classes de stockage Nearline, Coldline et Archive, plus les frais de transfert réseau inter-régions quand les données et BigQuery sont dans des régions différentes.

Les requêtes de tables externes contre les tiers de stockage froid peuvent devenir significativement plus coûteuses que les patterns historiques ne le suggéraient. Si vous utilisez extensivement les tables externes, particulièrement contre des données archivées, recalculez vos modèles de coûts avec ces nouveaux frais inclus.

Résumé de l’algorithme de décision

Le choix entre On-Demand et Editions dépend de trois facteurs : le volume du workload, les caractéristiques du workload et les exigences organisationnelles. Voici un arbre de décision :

Étape 1 : Vérifiez votre volume mensuel

Si vous traitez moins de 10 TiB mensuellement, restez sur On-Demand. Le free tier couvre le premier TiB, et les patterns d’utilisation sporadiques favorisent l’économie du pay-per-query. L’overhead d’Editions dû au minimum de 60 secondes le rend non économique à bas volumes.

Étape 2 : Exécutez la requête de comparaison des coûts

Pour les workloads entre 10-50 TiB mensuels, exécutez la requête de point d’équilibre contre vos données INFORMATION_SCHEMA. Si le ratio editions_pct_of_ondemand dépasse 75 %, restez sur On-Demand. S’il est en dessous de 50 %, évaluez Editions plus en détail. Entre 50-75 %, considérez d’autres facteurs comme les besoins de concurrence et la prévisibilité des coûts.

Étape 3 : Évaluez les besoins en fonctionnalités

Si vous avez besoin de BQML, BI Engine ou de fonctionnalités de sécurité (CMEK, VPC-SC, sécurité ligne/colonne), notez qu’On-Demand les fournit mais pas Standard Edition. Vous aurez besoin d’Enterprise Edition ou supérieur pour combiner la tarification basée sur les slots avec les fonctionnalités avancées.

Étape 4 : Évaluez les patterns de workload

Pour les workloads dépassant 50 TiB mensuels avec des patterns prévisibles (ETL planifié, traitement batch régulier), Editions offre probablement des économies significatives, souvent 40-60 % pour les jobs compute-intensive. Les patterns sporadiques avec de nombreuses requêtes courtes favorisent On-Demand quel que soit le volume.

Étape 5 : Considérez les approches hybrides

Les workloads mixtes bénéficient souvent de la combinaison de modèles de tarification. On-Demand pour l’exploration ad-hoc et les projets de développement où l’utilisation est imprévisible ; Editions avec des slots engagés pour les workloads de production ETL et BI où les patterns sont stables et le volume élevé.

Checklist finale avant de changer

Avant de migrer vers Editions, vérifiez ces étapes :

• Exécuté la requête de comparaison des coûts contre 90+ jours d’historique INFORMATION_SCHEMA
• Appliqué le multiplicateur 1,5× pour des estimations réalistes des coûts d’autoscaling
• Identifié les besoins en slots P50/P75/P90 pour la configuration baseline et maximum
• Testé avec Standard Edition pay-as-you-go pendant 30+ jours sur des workloads représentatifs
• Optimisé les requêtes coûteuses (partitionnement, clustering, élagage de colonnes) avant migration
• Validé les besoins en fonctionnalités (BQML, BI Engine, contrôles de sécurité) contre les capacités des Editions
• Confirmé que les patterns de workload favorisent le calcul soutenu plutôt que les requêtes courtes sporadiques
• Établi le monitoring pour la contention des slots et les coûts d’autoscaling post-migration

Référence rapide

Résumé des tarifs (région US)

Vues INFORMATION_SCHEMA clés

Pour l’analyse des jobs et l’attribution des coûts :

• INFORMATION_SCHEMA.JOBS : Historique des jobs du projet courant
• INFORMATION_SCHEMA.JOBS_BY_PROJECT : Scope explicite au projet
• INFORMATION_SCHEMA.JOBS_BY_ORGANIZATION : Vue à l’échelle de l’organisation
• INFORMATION_SCHEMA.JOBS_TIMELINE : Consommation de slots seconde par seconde

Pour la gestion des réservations :

• INFORMATION_SCHEMA.RESERVATIONS : Configurations des réservations
• INFORMATION_SCHEMA.ASSIGNMENTS : Mappings projet-vers-réservation
• INFORMATION_SCHEMA.CAPACITY_COMMITMENTS : Engagements de slots actifs

Règles empiriques pour l’autoscaling

• Facturation minimum : 60 secondes par événement de scaling
• Incréments de scaling : 50 slots
• Latence de scale-up : ~10 secondes
• Multiplicateur de coût pour les estimations : 1,5× les slot-heures théoriques
• Point de départ recommandé pour max_slots : P90 de l’utilisation historique
• Baseline recommandé : 60-80 % de P50 pour les configurations optimisées en coût

Le meilleur modèle de tarification est celui validé par vos patterns d’utilisation réels, pas par les benchmarks de l’industrie ou les calculs théoriques. Exécutez les requêtes, testez avec des workloads réels et laissez les données guider votre décision.