Un crédit Snowflake n’est pas « une requête ». C’est une unité de temps de calcul (et de certains services managés). Un warehouse XS consomme 1 crédit par heure allumé ; un M en consomme 4. La facture réelle additionne plusieurs compteurs que les juniors réduisent à « la taille du warehouse ».
Warehouses. Tant qu’ils sont STARTED, même sans requête. Auto-suspend est donc un levier de coût, pas un confort. Le multi-cluster multiplie : deux clusters M, c’est jusqu’à 8 crédits/heure.
Serverless et services autour. Automatic Clustering, Search Optimization, Snowpipe, tâches serverless, réplication, quelques fonctions de query acceleration. Ils n’apparaissent pas dans le sélecteur de t-shirt, mais ils tournent sans que personne n’ait « lancé un warehouse ».
Cloud services. Parsing, optimisation, gestion des métadonnées. Snowflake en offre l’équivalent d’environ 10 % de vos crédits de calcul. Au-delà — typiquement beaucoup de toutes petites requêtes, de clients qui se reconnectent, de SHOW et de cache de résultats — la ligne cloud services devient visible. C’est souvent le premier « mystère » d’une facture BI.
Ce qui n’est pas un crédit. Le stockage (téraoctets compressés, Time Travel et Fail-safe compris) est une ligne séparée, en monnaie par To/mois. Les transferts inter-régions ou hors cloud aussi. Confondre les trois, c’est mal diagnostiquer un dépassement.
Que vous savez lire Account Usage, pas seulement citer le tarif. WAREHOUSE_METERING_HISTORY, AUTOMATIC_CLUSTERING_HISTORY, QUERY_HISTORY (crédits attribués, octets scannés) : on veut entendre où vous iriez voir, et quelle hypothèse chaque vue infirme.
La relance : « Pourquoi la facture a doublé alors que le volume de données n’a pas bougé ? » Réponses acceptables : un warehouse resté allumé, le clustering automatique sur une table qui s’écrit en continu dans le désordre, une explosion de dashboards (cloud services + files d’attente qu’on « résout » en passant à L), une réplication vers une région DR oubliée.
Le coût d’une requête n’est pas le crédit du warehouse divisé par le nombre de requêtes de l’heure. Un scan de 40 To sur un L pendant trois minutes peut coûter plus qu’une centaine de requêtes de cache. On parle donc octets scannés × temps d’entrepôt allumé, pas « nombre de SQL ». Et on refuse le réflexe « mettre XL, ça ira plus vite donc moins cher » : plus vite, oui, si la requête est parallèle ; moins cher, seulement si le temps baisse plus que la taille n’augmente — ce que le query profile tranche, pas l’intuition.