Snowflake a plusieurs caches, et les confondre est une erreur d’entretien classique. Le result cache (cache de résultats) vit dans les services cloud : si la même requête textuelle — ou une requête reconnue équivalente — revient, que les tables sous-jacentes n’ont pas changé, le résultat part sans allumer de warehouse. Le cache du warehouse (parfois local disk cache ou warehouse cache) ce sont des micro-partitions déjà lues, gardées sur les SSD du cluster : la requête s’exécute encore, mais évite de redescendre au stockage objet.
Result cache. Environ 24 heures, partagé entre warehouses et sessions du compte (sous conditions : mêmes droits, données stables). Idéal pour un dashboard qui relance le même SQL toutes les minutes. Invisible si quelqu’un INSERT une ligne : le cache est invalidé. Invisible aussi si vous changez un commentaire… ou pas : Snowflake normalise ; ne pariez pas sur les commentaires pour « forcer » un recalcul — utilisez ALTER SESSION SET USE_CACHED_RESULT = FALSE quand vous mesurez.
Cache warehouse. Vit aussi longtemps que le warehouse reste allumé. Auto-suspend le vide. C’est pourquoi un entrepôt qui s’éteint toutes les 30 secondes « pour économiser » rend la BI froide : chaque clic re-scan S3. Deux warehouses distincts ne partagent pas ce cache. Isoler ETL et BI est juste pour la concurrence ; ce n’est pas gratuit en I/O.
Cache de métadonnées. Les services cloud gardent aussi des infos de pruning. Ça n’explique pas à lui seul un temps de 80 ms, mais ça explique pourquoi le plan est instantané.
Que vous diagnostiquez un temps « trop beau » avant de crier victoire. Une démo où la deuxième exécution passe de 40 s à 200 ms : quel cache ? Si le profil montre QUERY RESULT REUSE (ou un scan à zéro octet), c’est le result cache — vous n’avez rien prouvé sur le clustering. Si le warehouse a scanné depuis le cache local, vous avez prouvé que le working set tient sur le cluster, pas que le SQL est optimal à froid.
La relance : « Comment mesurez-vous une vraie régression ? » Désactiver le result cache, éventuellement reprendre sur un warehouse fraîchement repris, comparer les octets scannés et le spilling, pas seulement le temps mur.
Une équipe peut croire « nos requêtes ne coûtent plus rien » parce que le result cache sert 90 % des clics. Le jour où un modèle dbt écrit la table toutes les cinq minutes, tout le cache résultats tombe, les warehouses se réveillent ensemble, et la facture ressemble au lundi sans le cache. Le cache n’est pas une architecture ; c’est un rabais tant que les données bougent peu.