HomeChef maîtrise ses coûts Snowflake et installe une véritable culture du coût dans son équipe analytique

SELECT a offert une visibilité immédiate sur les coûts et des recommandations d'optimisation que les outils internes de HomeChef ne fournissaient pas. La mise en place n'a pris que 30 minutes. Grâce à son intégration poussée avec dbt et à une ventilation détaillée des coûts, l'équipe a rapidement identifié les leviers d'optimisation à fort impact sur ses 1 200+ modèles dbt, tout en obtenant la visibilité qu'elle cherchait jusque-là à construire via des dashboards sur mesure.

HomeChef a migré d'EMR vers Snowflake il y a cinq ans, en l'utilisant d'abord pour alimenter des dashboards Looker via des mises à jour batch quotidiennes avec dbt — un setup stable et économique. Tout a basculé lorsque HomeChef s'est mis à faire tourner de plus en plus de workloads opérationnels sur Snowflake. L'équipe est passée de requêtes une fois par jour à des requêtes toutes les 15 minutes. Et quand on enchaîne les upserts sur des tables de churn, la facture Snowflake grimpe très vite. Les coûts ont quasiment été multipliés par dix du jour au lendemain.

Avant SELECT, HomeChef avait construit son suivi des coûts en interne : collecte incrémentale de l'historique des requêtes, séparation des warehouses pour tracer les dépenses par environnement dbt, et dashboards Looker sur mesure. Cette solution maison suffisait pour le monitoring de routine, mais montrait ses limites dès qu'un nouveau problème surgissait. Ajouter une fonctionnalité supposait de pusher de nouvelles dimensions dans les tables et de nouvelles mesures dans les dashboards, et les analyses ad hoc étaient ralenties par la complexité des métadonnées Snowflake. L'inertie et la friction étaient considérables. À mesure que l'éventail de fonctionnalités Snowflake utilisées s'élargissait, c'était à chaque fois un nouveau dataset ésotérique à apprivoiser.

Face à la flambée des coûts, HomeChef avait besoin d'une visibilité immédiate sur ce qui pesait sur la facture. En 30 minutes, l'équipe était opérationnelle avec SELECT. Sa connaissance approfondie de l'écosystème dbt et sa visibilité complète sur les coûts ont rendu la transition fluide, et rendu les solutions maison superflues.

HomeChef a obtenu des réductions de coûts significatives en s'attaquant d'abord aux problèmes de stockage (20 % d'économies), puis en s'appuyant sur SELECT pour identifier des opportunités d'optimisation de performance représentant 40 % supplémentaires. Avec plus de 1 200 modèles dbt, identifier manuellement les cibles d'optimisation aurait été impossible. La ventilation des coûts et les insights de performance de SELECT ont permis à l'équipe de concentrer ses efforts là où l'impact serait maximal. SELECT a joué à la fois le rôle d'outil d'identification des cibles et de tour de contrôle pour le monitoring des optimisations de performance.

SELECT a fait passer HomeChef d'une posture de pompier réactif à un monitoring proactif. Devin commence désormais chaque journée par un coup d'œil rapide à SELECT. Il prend son café, jette un œil aux pipelines, puis ouvre SELECT. Deux à trois minutes lui suffisent pour prendre le pouls de son environnement Snowflake au quotidien. Cette routine permet de détecter en amont les anomalies, les nouveaux workloads et les pics de coûts, avant qu'ils ne deviennent de vrais problèmes. Il peut suivre l'évolution des usages dans le temps et repérer les nouveaux cas d'usage non anticipés, ce qui permet à l'équipe business analytics de travailler directement avec les utilisateurs concernés.

Le changement culturel le plus marquant est sans doute que les analytics engineers se posent désormais la question de l'optimisation dès la phase de développement, et non plus après le déploiement. Grâce à des sessions de pair programming nourries des insights SELECT, toute l'équipe s'est approprié les principes d'optimisation des requêtes. Aujourd'hui, les analytics engineers optimisent les performances en amont, avant même de soumettre leurs pull requests. Les AEs signalent maintenant en amont "celle-ci va coûter cher" et ajoutent "j'ai fait passer le runtime de X à Y avant de pusher la PR parce que je savais que cette window function allait me plomber". Tout aussi important : SELECT aide aussi à savoir quand ne pas optimiser, évitant les efforts inutiles sur des modèles à faible impact.