Les 5 erreurs Snowflake qui coûtent le plus cher

Après avoir analysé de nombreux environnements Snowflake, je retrouve systématiquement les mêmes erreurs. Chacune peut représenter 10-30% de la facture mensuelle.

Dans 90% des environnements que j'audite, au moins 3 de ces 5 erreurs sont présentes. Ce n'est pas une question de compétence des équipes — c'est juste que Snowflake est configuré par défaut pour la performance, pas pour les coûts.

Voici les 5 patterns de gaspillage les plus fréquents — et comment les corriger.

Erreur #1 : Auto-suspend désactivé ou trop long

Le problème

Par défaut, Snowflake crée les warehouses avec un auto-suspend de 5 minutes. Beaucoup d'admins le désactivent "pour éviter les temps de démarrage" ou le montent à 10-15 minutes.

Résultat : Le warehouse tourne à vide pendant des heures.

J'ai vu chez un client un warehouse XLARGE avec auto-suspend désactivé "parce que les utilisateurs se plaignaient des 2 secondes de cold start". Coût de cette décision : 18 000€/mois de gaspillage pur. Pour éviter 2 secondes d'attente.

Le calcul

Un warehouse MEDIUM (4 crédits/heure) avec auto-suspend désactivé :

Utilisation réelle : 2h/jour de requêtes
Temps facturé : 24h/jour (jamais suspendu)
Gaspillage : 22h × 4 crédits × $3 = $264/jour = $7,920/mois

La solution

-- Vérifier tous les warehouses
SELECT
  warehouse_name,
  warehouse_size,
  auto_suspend,
  CASE
    WHEN auto_suspend IS NULL THEN 'JAMAIS'
    WHEN auto_suspend > 300 THEN 'TROP LONG'
    ELSE 'OK'
  END as status
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSES
WHERE deleted IS NULL;

-- Corriger
ALTER WAREHOUSE my_warehouse SET AUTO_SUSPEND = 60;

Règle : 60 secondes pour les workloads interactifs, 120 secondes maximum pour le batch.

Mon avis tranché : Je ne recommande JAMAIS de désactiver l'auto-suspend, même sur les warehouses "critiques". Le cold start de Snowflake est de 1-3 secondes. Si vos utilisateurs ne peuvent pas attendre 2 secondes, le problème n'est pas technique — c'est un problème de communication.

Économie typique : 20-40% des coûts compute

Erreur #2 : Warehouses surdimensionnés

Le problème

"On a pris un LARGE pour être sûrs d'avoir assez de puissance."

Sauf que la plupart des requêtes n'ont pas besoin d'un LARGE. Un X-SMALL ou SMALL suffit pour 80% des cas d'usage.

La pire situation que j'ai vue : une équipe BI avec 15 analystes, chacun avec son propre warehouse MEDIUM dédié. Utilisation moyenne : 45 minutes par jour. Coût mensuel : 12 000€. Après consolidation sur un seul warehouse SMALL avec auto-scaling : 800€/mois. Même performance perçue par les utilisateurs.

Comment le détecter

-- Analyser la charge réelle par warehouse
SELECT
  warehouse_name,
  warehouse_size,
  AVG(avg_running) as avg_concurrent_queries,
  AVG(avg_queued_load) as avg_queue,
  MAX(avg_queued_load) as max_queue
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_LOAD_HISTORY
WHERE start_time > DATEADD(day, -30, CURRENT_TIMESTAMP())
GROUP BY 1, 2
ORDER BY avg_concurrent_queries DESC;

Signaux de surdimensionnement :

• avg_concurrent_queries < 1 → Le warehouse est souvent idle
• avg_queue = 0 → Pas de contention, pas besoin de plus de puissance
• Requêtes simples (< 10 sec) sur warehouse LARGE

La solution

-- Réduire la taille
ALTER WAREHOUSE analytics_wh SET WAREHOUSE_SIZE = 'SMALL';

-- Ou utiliser l'auto-scaling
ALTER WAREHOUSE analytics_wh SET
  WAREHOUSE_SIZE = 'SMALL'
  MIN_CLUSTER_COUNT = 1
  MAX_CLUSTER_COUNT = 3
  SCALING_POLICY = 'STANDARD';

Règle : Commencer petit, scaler si queue > 0 de manière consistante.

Économie typique : 50-75% sur les warehouses concernés

Erreur #3 : Time Travel excessif

Le problème

Snowflake garde par défaut :

• Standard : 1 jour de Time Travel
• Enterprise : jusqu'à 90 jours de Time Travel

Beaucoup d'entreprises laissent le défaut Enterprise (90 jours) sur TOUTES les tables, y compris :

• Tables de staging temporaires
• Tables de logs
• Tables recréées quotidiennement

Le calcul

Une table de 100 GB modifiée quotidiennement avec 90 jours de Time Travel :

Storage Time Travel : 100 GB × 90 versions = 9 TB
Coût : 9 TB × $23/TB/mois = $207/mois pour UNE table

J'ai vu chez un client e-commerce leur table de tracking des clics avec 90 jours de Time Travel. Cette table était tronquée et rechargée chaque jour. Résultat : 2,3 TB de Time Travel storage pour une table de 25 GB de données actives. Coût annuel de cette erreur de configuration : plus de 600€ — pour une seule table parmi des centaines.

Comment le détecter

-- Tables avec beaucoup de Time Travel storage
SELECT
  table_catalog,
  table_schema,
  table_name,
  ROUND(active_bytes / POW(1024, 3), 2) as active_gb,
  ROUND(time_travel_bytes / POW(1024, 3), 2) as time_travel_gb,
  ROUND(time_travel_bytes / NULLIF(active_bytes, 0), 1) as ratio
FROM SNOWFLAKE.ACCOUNT_USAGE.TABLE_STORAGE_METRICS
WHERE time_travel_bytes > active_bytes
ORDER BY time_travel_bytes DESC
LIMIT 20;

Red flag : ratio > 2 = Time Travel coûte plus que les données actives.

La solution

-- Réduire Time Travel sur tables non critiques
ALTER TABLE staging.temp_data SET DATA_RETENTION_TIME_IN_DAYS = 1;

-- Tables temporaires : 0 jour
ALTER TABLE staging.daily_load SET DATA_RETENTION_TIME_IN_DAYS = 0;

-- Utiliser des tables TRANSIENT pour le staging
CREATE TRANSIENT TABLE staging.temp_data (...);

Économie typique : 15-30% des coûts storage

Erreur #4 : Requêtes sans clustering sur grandes tables

Le problème

Une table de 500 GB sans clustering key. Chaque requête filtrée scanne potentiellement toute la table.

Snowflake ne facture pas au TB scanné comme BigQuery, mais :

• Plus de données scannées = temps d'exécution plus long
• Temps plus long = plus de crédits consommés

Ce que les équipes comprennent systématiquement de travers : elles pensent que le clustering est une optimisation "nice to have". En réalité, sur une table de plus de 50 GB filtrée régulièrement, ne PAS avoir de clustering key est une erreur de design. Point.

Comment le détecter

-- Tables volumineuses sans clustering
SELECT
  table_catalog,
  table_schema,
  table_name,
  ROUND(bytes / POW(1024, 3), 2) as size_gb,
  clustering_key
FROM SNOWFLAKE.ACCOUNT_USAGE.TABLES
WHERE bytes > 10 * POW(1024, 3)  -- > 10 GB
  AND clustering_key IS NULL
  AND deleted IS NULL
ORDER BY bytes DESC;

-- Requêtes longues sur ces tables
SELECT
  query_id,
  query_text,
  total_elapsed_time / 1000 as seconds,
  bytes_scanned / POW(1024, 3) as gb_scanned
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE start_time > DATEADD(day, -7, CURRENT_TIMESTAMP())
  AND total_elapsed_time > 60000  -- > 1 minute
ORDER BY total_elapsed_time DESC
LIMIT 20;

La solution

-- Ajouter un clustering key basé sur les filtres fréquents
ALTER TABLE events CLUSTER BY (event_date, country);

-- Vérifier l'efficacité
SELECT SYSTEM$CLUSTERING_INFORMATION('events');

Règle : Cluster by les colonnes les plus filtrées, dans l'ordre de sélectivité.

Économie typique : 30-60% du temps d'exécution sur les requêtes concernées

Erreur #5 : Pas de Resource Monitors

Le problème

Sans resource monitors, rien n'empêche :

• Une requête folle de consommer 1000 crédits
• Un warehouse oublié de tourner tout le week-end
• Un utilisateur de lancer des requêtes massives par erreur

J'ai vu des factures doubler en un week-end à cause d'un job mal configuré. Littéralement : 45 000€ partis en fumée entre vendredi soir et lundi matin parce qu'une boucle infinie relançait le même pipeline ETL toutes les 30 secondes.

La solution

-- Monitor au niveau compte (filet de sécurité)
CREATE RESOURCE MONITOR account_safety
  WITH CREDIT_QUOTA = 5000
  FREQUENCY = MONTHLY
  START_TIMESTAMP = IMMEDIATELY
  TRIGGERS
    ON 75 PERCENT DO NOTIFY
    ON 90 PERCENT DO NOTIFY
    ON 100 PERCENT DO SUSPEND;

ALTER ACCOUNT SET RESOURCE_MONITOR = account_safety;

-- Monitor par warehouse critique
CREATE RESOURCE MONITOR prod_etl_monitor
  WITH CREDIT_QUOTA = 500
  FREQUENCY = MONTHLY
  TRIGGERS
    ON 80 PERCENT DO NOTIFY
    ON 100 PERCENT DO SUSPEND;

ALTER WAREHOUSE prod_etl_wh SET RESOURCE_MONITOR = prod_etl_monitor;

Niveaux recommandés

Économie typique : Protection contre les incidents (potentiellement des milliers d'€)

Checklist de diagnostic rapide

-- Script de diagnostic complet
-- À exécuter pour identifier rapidement les problèmes

-- 1. Warehouses mal configurés
SELECT warehouse_name, warehouse_size, auto_suspend,
  CASE WHEN auto_suspend IS NULL OR auto_suspend > 300 THEN 'KO' ELSE 'OK' END as status
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSES WHERE deleted IS NULL;

-- 2. Top consommateurs (7 derniers jours)
SELECT warehouse_name, SUM(credits_used) as credits
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE start_time > DATEADD(day, -7, CURRENT_TIMESTAMP())
GROUP BY 1 ORDER BY 2 DESC LIMIT 10;

-- 3. Time Travel excessif
SELECT table_name,
  ROUND(time_travel_bytes / POW(1024, 3), 1) as tt_gb,
  ROUND(active_bytes / POW(1024, 3), 1) as active_gb
FROM SNOWFLAKE.ACCOUNT_USAGE.TABLE_STORAGE_METRICS
WHERE time_travel_bytes > active_bytes
ORDER BY time_travel_bytes DESC LIMIT 10;

-- 4. Resource monitors existants
SELECT name, credit_quota, frequency, suspend_at, suspend_immediate_at
FROM SNOWFLAKE.ACCOUNT_USAGE.RESOURCE_MONITORS;

Récapitulatif

Total potentiel : 30-60% d'économies sur la facture globale.

Conclusion

Ces 5 erreurs sont présentes dans presque tous les environnements Snowflake que j'audite. La bonne nouvelle : elles sont toutes corrigeables en quelques heures.

L'auto-suspend à 60 secondes et les resource monitors sont les quick wins les plus impactants. Commencez par là — vous aurez des résultats visibles sur votre prochaine facture.

Si ce genre de contenu t'intéresse, je partage régulièrement des tips FinOps et des retours d'expérience sur l'optimisation Snowflake. Tu peux me suivre sur LinkedIn ou t'abonner à ma newsletter pour recevoir les prochains articles directement dans ta boîte mail.

Des questions sur ton environnement Snowflake ? N'hésite pas à me contacter directement — je réponds à tous les messages.