Snowflake vs Databricks : le duel

Les données

Notre benchmark s'appuie sur le TCP-H Scale Factor 1000. Ce jeu de données compte environ 6 milliards de lignes sur la plus grande table. Snowflake et Databricks proposent tous deux des données TPC-H, mais sans tailles communes ni jeux de données strictement identiques. Pour une comparaison rigoureuse, il faut donc transférer en ETL les données de Snowflake vers Databricks. Le plus simple est d'utiliser un outil dédié comme Estuary, sinon vous pouvez le faire vous-même.

Databricks fournit :

• tpcds_sf1 et sf1000
• tpch avec 30 millions de lignes. Soit environ la moitié du scale factor 10 de Snowflake, qui compte 60 millions de lignes.

Snowflake fournit :

• tpcds_sf10 et 100
• tpch aux scale factors 1, 10, 100 et 1000

Sans surprise, les plateformes n'ont pas facilité la comparaison des performances en ne proposant pas de données d'exemple alignées. 🤨

Scénarios

Nous avons utilisé ces requêtes standard existantes selon 3 scénarios :

• Exécution séquentielle des 22 requêtes. Dans ce scénario, seule la requête 1 est un cold start ; chaque requête suivante peut profiter du cache du warehouse alimenté par les précédentes.
• Exécution simultanée des 22 requêtes. Ce scénario teste la capacité de la plateforme à exécuter plusieurs requêtes en parallèle et permet d'observer un éventuel scaling horizontal.
• 5 requêtes en cold start. Nous avons exécuté une petite sélection de requêtes, de complexité et de style variés, pour comparer les plateformes sur un warehouse à froid.

Workloads CTAS : les requêtes standard du benchmark produisent des résultats plutôt restreints et fortement agrégés, ce qui ne reflète pas un véritable workload CTAS — le volume écrit est trop faible pour solliciter le débit en écriture. Pour tester les opérations à forte intensité d'écriture, nous avons créé 5 variantes qui matérialisent de gros résultats avec des formes de données différentes, allant de tables étroites de plusieurs milliards de lignes à des tables très larges et dénormalisées, afin de comparer les performances d'écriture selon la forme des tables et la complexité des requêtes.

Workloads DML : ici, nous supprimons 1 mois de données de la table avant de le réinsérer. Un mois représente environ 1 % des données, soit 6 M de lignes. Ce test évalue à la fois l'efficacité du query pruning (cibler le mois en question) et celle des opérations DML.

Warehouses

Pour chaque run et chaque scénario, un nouveau warehouse est généré automatiquement au démarrage, puis détruit dès la fin du travail. Cela permet d'isoler le coût total d'un warehouse et d'éliminer le temps d'inactivité de l'équation.

Un Databricks Serverless SQL Warehouse correspond grosso modo à un Snowflake Warehouse de taille supérieure. Par exemple, un Small Databricks équivaut à peu près à un Medium Snowflake. Nous avons exécuté les 4 scénarios ci-dessus sur les combinaisons de warehouses suivantes :

• Snowflake Medium vs Databricks Small
• Snowflake Large vs Databricks Medium
• Snowflake XL vs Databricks Large

Cette équivalence de tailles est confirmée par la documentation Snowflake et Databricks, où le Worker Count Databricks est considéré comme équivalent aux Snowflake Credits.

Attribution des coûts

Nous voulions une attribution des coûts la plus précise possible. Pour cela, des warehouses isolés sont utilisés comme décrit plus haut. Nous nous appuyons sur les données de facturation réelles (en credits ou DBUs) pendant toute la durée de vie du warehouse. Au final, un calculateur de coûts flexible applique différents tarifs par credit ou par DBU aux résultats pour simuler les différents tiers des plateformes. Cette approche élimine toute la complexité liée à l'attribution des coûts pour des requêtes concurrentes ou aux incréments minimaux de facturation. Nous regardons simplement le coût total du scénario.

Lorsque nous présentons le coût de requêtes individuelles plutôt que de runs complets, le coût est attribué à chaque requête au prorata de son temps d'exécution. Concrètement, le coût total du run (ou de la durée de vie du warehouse) est réparti entre les requêtes, de sorte que les chiffres s'additionnent correctement.

Comparaison des coûts

Le tier Databricks Standard est en cours de retrait (et l'a probablement été en octobre 2025). Si l'on compare les prix catalogue les plus bas de chaque plateforme, on oppose donc Snowflake Standard à 2 $/credit à Databricks Enterprise à 0,70 $/DBU. Cette comparaison nous paraît équitable, car le tier Snowflake Standard est une version complète de Snowflake, dont la principale fonctionnalité absente est le time travel. Cela dit, nous savons que de nombreux lecteurs préféreront une comparaison Enterprise vs Enterprise. Nous présenterons donc les deux : Databricks à 0,70 $/DBU vs Snowflake à 2 $/credit, puis à 3 $/credit.

Historique des runs et analyse

Les ID de requête et les statistiques de run sont enregistrés immédiatement dans une instance locale duckdb. Les données sont stockées au grain de l'ID de requête (auquel s'ajoutent le run ID, le warehouse et le scénario). Des vues de reporting agrègent les données pour tirer des conclusions sur l'ensemble des runs.

Requêtes

Les requêtes du benchmark sont disponibles ici. (Bien que le SQL semble codé en dur pour le scale factor 100x, le nom de la table est remplacé dynamiquement à l'exécution par le scale factor défini dans votre fichier de configuration. Tous les tests ont été exécutés sur le scale factor 1000x.) Nous avons organisé les 22 requêtes en catégories selon leur complexité et leur nombre de jointures. Le détail des catégories se trouve ici, mais cette capture d'écran en donne un bref aperçu.

Objectif et setup

Objectif : exécuter les requêtes en séquence reproduit ce que l'on vit à son poste de travail en lançant des requêtes sur ces plateformes. C'est ce que vivent les utilisateurs finaux quand ils lancent une requête select. Cette mesure permet de comparer requête par requête, warehouse par warehouse, à la manière de la plupart des benchmarks TPC-H.

Setup : ultra simple — on exécute les 22 requêtes une par une. Dans tous les scénarios, le warehouse est créé au début du run et détruit immédiatement après la fin de la dernière requête. Les résultats sont enregistrés à la volée dans duckdb.

Dans ce scénario, seule la requête 1 est un véritable cold start ; les requêtes 2 à 22 sont considérées comme warm, puisque le warehouse reste actif pendant tout le run.

Résultats

Snowflake à 2 $/credit vs Databricks à 0,70 $/DBU :

Snowflake à 3 $/credit vs Databricks à 0,70 $/DBU :

À 2 $/credit, Snowflake est 34 % plus rapide et 17 % moins cher. En passant Snowflake à 3 $/credit, Databricks devient 20 % moins cher.

Objectif et setup

Objectif : simuler le chargement d'un dashboard BI ou l'exécution de jobs où des dizaines de requêtes partent en même temps. L'idée est de tester la gestion de la concurrence par chaque plateforme.

Setup : nous avons utilisé Python pour lancer les 22 requêtes simultanément et enregistrer les résultats.

Résultats

Snowflake à 2 $/credit vs Databricks à 0,70 $/DBU :

Snowflake à 3 $/credit vs Databricks à 0,70 $/DBU :

Dans les deux cas, Snowflake s'est révélé plus rapide et moins cher ! Pour les workloads concurrents, Snowflake semble donc l'emporter (dans ce scénario de benchmark).

Voyons maintenant comment chaque plateforme a géré la concurrence. Avec une gestion parfaite (sans file d'attente ni contention sur les ressources), la durée totale du test concurrent devrait être proche de celle de la plus longue requête exécutée seule.

Plateforme	Taille du warehouse	Plus longue requête isolée	Temps total concurrent	Ratio
Databricks	SMALL	134,5 s	369,5 s	2,7x
Databricks	MEDIUM	64,5 s	296,0 s	4,6x
Databricks	LARGE	32,9 s	176,5 s	5,4x
Snowflake	MEDIUM	94,7 s	278,7 s	2,9x
Snowflake	LARGE	45,2 s	142,8 s	3,2x
Snowflake	XLARGE	20,7 s	99,7 s	4,8x

Les données ci-dessus montrent que les deux plateformes subissent une pénalité en exécution concurrente (plusieurs requêtes lancées en parallèle se ralentissent mutuellement, ou bien il y a de la file d'attente), mais Snowflake affiche le meilleur ratio sur cette comparaison.

Avec 22 requêtes concurrentes, on constate que Snowflake a scalé jusqu'à 4 clusters sur les tailles Medium et Large, et n'en a utilisé que 3 sur le XL. D'où le fait que le XL n'a coûté que quelques centimes de plus que le Large.

Malheureusement, ces mêmes données ne sont pas accessibles côté Databricks. Je n'ai pas trouvé le moyen de savoir combien de clusters ont été utilisés.

Objectif et setup

Objectifs : mesurer les durées d'exécution sans cache du warehouse et vérifier si le temps de démarrage du warehouse influe sur les résultats.

Les deux plateformes exploitent un cache du warehouse ou une accélération Photon, c'est-à-dire un cache hébergé sur la VM qui exécute la requête. Quand les requêtes s'enchaînent, la requête 2 peut profiter d'une partie du cache généré par la requête 1, et ainsi de suite.

Setup : pour évaluer les performances en l'absence de cache, nous avons conçu un scénario qui éteint le warehouse entre chaque exécution de requête. Nous avons choisi de ne pas exécuter les 22 requêtes, ce qui aurait engendré un surcoût important.

Le temps de création du warehouse n'est pas comptabilisé dans le temps total, contrairement au temps de démarrage du warehouse, qui l'est.

Les requêtes

Requête	Catégorie	Complexité	Description
Q1	Agrégation et filtrage simples	Faible (warm-up)	Plusieurs agrégations (SUM, AVG, COUNT) avec GROUP BY sur une table de 600 M de lignes
Q3	Jointures basiques (2 à 4 tables)	Moyenne (OLAP standard)	Jointure à 3 voies avec agrégation et filtrage par date
Q5	Jointures complexes (5 tables et plus)	Élevée (stress test)	Jointure à 6 voies avec calcul de revenu et filtrage géographique
Q10	Jointures basiques (2 à 4 tables)	Moyenne (OLAP standard)	Jointure à 4 voies avec filtre sélectif et GROUP BY à forte cardinalité
Q18	Sous-requêtes et semi-jointures	Moyenne (OLAP standard)	Sous-requête IN avec filtre d'agrégation (HAVING)

Requête, Catégorie, Complexité, Description — Q1 Agrégation et filtrage simples Faible (warm-up) Plusieurs agrégations (SUM, AVG, COUNT) avec GROUP BY sur une table de 600 M de lignes ; Q3 Jointures basiques (2 à 4 tables) Moyenne (OLAP standard) Jointure à 3 voies avec agrégation et filtrage par date ; Q5 Jointures complexes (5 tables et plus) Élevée (stress test) Jointure à 6 voies avec calcul de revenu et filtrage géographique ; Q10 Jointures basiques (2 à 4 tables) Moyenne (OLAP standard) Jointure à 4 voies avec filtre sélectif et GROUP BY à forte cardinalité ; Q18 Sous-requêtes et semi-jointures Moyenne (OLAP standard) Sous-requête IN avec filtre d'agrégation (HAVING)

Résultats

On constate ici que Snowflake a été nettement plus rapide et un peu moins cher.

Dans le détail, le temps de démarrage de Databricks tournait autour de 7 secondes par démarrage, contre moins d'une seconde pour Snowflake dans tous les cas.

Objectif et setup

Objectif : mesurer les opérations à forte intensité d'écriture, typiques des tâches de data engineering et des projets dbt. Les requêtes TPC-H standard sont optimisées pour la lecture analytique : elles parcourent de gros jeux de données mais renvoient des résultats agrégés et de petite taille (sommes, moyennes, top-N). Cela permet bien de tester l'exécution et l'optimisation des requêtes, mais pas vraiment la performance en écriture. Nous voulions comprendre comment Snowflake et Databricks se comparent quand il s'agit d'écrire des milliards de lignes avec des formes de données variées.

Setup : nous avons créé 5 variantes de CTAS, chacune conçue pour tester un pattern d'écriture spécifique :

1. Narrow Tall (6 Md de lignes × 4 colonnes) : projection simple de la table LINEITEM avec seulement 4 colonnes clés (l_orderkey, l_partkey, l_quantity, l_extendedprice). On teste ici le débit maximal en lignes avec un surcoût minimal côté colonnes.
2. Standard Tall (6 Md de lignes × 16 colonnes) : copie complète de la table LINEITEM (SELECT * FROM LINEITEM). Cas typique de duplication ou d'archivage de grandes tables de faits. (En pratique, on utiliserait Clone, mais nous ne benchmarkons pas les opérations Clone aujourd'hui.)
3. Medium Wide (1,5 Md de lignes × 30 colonnes) : jointure des tables ORDERS, CUSTOMER, NATION et REGION. On teste ici la combinaison lecture/écriture avec une complexité JOIN modérée et un schéma plus large, typique de la dénormalisation d'un star schema.
4. Very Wide (6 Md de lignes × 59 colonnes) : jointure totalement dénormalisée sur toutes les tables TPC-H (LINEITEM, ORDERS, CUSTOMER, SUPPLIER, PART, PARTSUPP, NATION, REGION). C'est le cas extrême des tables larges pré-jointes que l'on trouve dans les couches analytiques.
5. Filtered (2 Md de lignes × 16 colonnes) : LINEITEM filtrée sur les commandes expédiées après 1995 (WHERE l_shipdate >= '1995-01-01'). On teste ici le débit en écriture pour les copies partielles de tables, pattern courant dans les pipelines de données incrémentaux.

Résultats

Snowflake à 2 $/credit vs Databricks à 0,70 $/DBU :

Snowflake à 3 $/credit vs Databricks à 0,70 $/DBU :

Snowflake à 2 $/credit vs Databricks à 0,70 $/DBU, en excluant la requête Very Wide, qui fait figure de valeur aberrante :

Snowflake à 3 $/credit vs Databricks à 0,70 $/DBU, en excluant la requête Very Wide, qui fait figure de valeur aberrante :

On peut affirmer sans risque que, dans ce scénario de benchmark, Databricks dispose d'un net avantage pour créer de grosses tables via CTAS.

Objectif et setup

Objectif : le pattern Delete + Insert est très utilisé pour mettre à jour les données de manière incrémentale. C'est la façon la plus efficace de transformer des segments ciblés de données sur de grandes tables, et donc un scénario important à tester.

Setup : au début du run, une copie des données source du benchmark est créée. Elle n'est comptée ni dans le temps d'exécution ni dans les métriques de coût. Une fois la copie réalisée, le processus de benchmark démarre. Il supprime 1 mois de données, soit environ 6 M de lignes ou 1 % du total, puis réinsère ce même mois depuis la source. Cela simule un scénario ETL réel où les enregistrements correspondants sont supprimés puis insérés. À noter : nous n'avons pas utilisé merge, car on sait que delete + insert est plus performant que merge.

Résultats

Snowflake à 2 $/credit vs Databricks à 0,70 $/DBU :

Snowflake à 3 $/credit vs Databricks à 0,70 $/DBU :

Les résultats sont vraiment intéressants ici. Si les warehouses Snowflake M, L et XL traitent les données en moins de 20 secondes, c'est grâce à un excellent query pruning. Les 6 milliards de lignes sont élagués pour être traités comme 6 millions de lignes, soit un jeu de données bien plus petit. Le warehouse Snowflake Small met plus de deux fois plus de temps, car il subit du spillage à la fois sur l'étape de suppression et sur celle d'insertion.

Le même phénomène se produit côté Databricks. On observe une concentration entre 35 et 39 secondes pour toutes les tailles de warehouse. Databricks réduit effectivement la taille du jeu de données, et les M, L et XL le gèrent sans problème, mais sans tout à fait égaler la vitesse de Snowflake.

Si vous souhaitez exécuter ces tests vous-même, c'est relativement simple. Comme indiqué plus haut, la première étape est de transférer en ETL le jeu de données 1000x de Snowflake vers Databricks. C'est la partie difficile, et la seule pour laquelle nous ne fournissons pas d'automatisation, car les variables en jeu sont trop nombreuses. Encore une fois, je recommande Estuary pour cela !

Une fois les données disponibles sur votre compte Databricks, suivez le getting started ici. Il vous suffit d'avoir UV et le Snowflake CLI installés, de configurer votre fichier .env en lançant uv run setup_config.py, puis vous pouvez lancer les benchmarks ! Le readme contient de nombreux exemples pour exécuter des scénarios individuels, des tailles de warehouse précises, ou bien l'ensemble d'un seul coup.

Après l'exécution du benchmark, attendez 2 heures que les données de facturation soient consolidées. Lancez ensuite uv run enrich.py pour enrichir les résultats avec les données de facturation. Quand vous êtes prêt à visualiser les résultats, suivez également les étapes du readme.

Les résultats montrent sans ambiguïté que Snowflake Standard Edition est la plateforme la plus rentable dans tous les scénarios, à l'exception du scénario CTAS où Databricks devance Snowflake aussi bien en coût qu'en performance. Passer à Snowflake Enterprise Edition à 3 $/credit rend Databricks moins cher dans certains scénarios. Encore une fois, les benchmarks restent des benchmarks : testez impérativement sur vos propres données !

Jeff est consultant Data et Analytics, fort de plus de 15 ans d'expérience dans l'automatisation des insights et l'exploitation des données pour piloter les processus métier. Côté technique, il est spécialisé sur Snowflake + dbt + Tableau. Côté secteurs, il a travaillé dans les services publics, les essais cliniques, l'édition, les biens de grande consommation et l'industrie. N'hésitez pas à le contacter à tout moment : [email protected].