Snowflake exécute avec son moteur propriétaire, Databricks avec Spark et Photon. Ce que la différence change vraiment, et le piège des replis silencieux de Photon.
« Snowflake ou Databricks ? » La question revient dans chaque comité d’architecture, et elle se règle souvent sur un argument de moteur : Databricks vous donne Spark et Photon, donc plus de possibilités. L’argument n’est pas faux. Mais il est incomplet, et pris seul il conduit à des choix qu’on regrette dix-huit mois plus tard.
Voici ce que chaque plateforme exécute réellement, un piège de Photon que personne ne mentionne, et le critère qui décide vraiment — celui qui n’a rien à voir avec le moteur.
Snowflake possède un moteur unique, propriétaire, écrit en C++ avec exécution vectorisée sur des données colonnaires. Vous ne le voyez jamais. Ce que vous manipulez, ce sont des Virtual Warehouses : des grappes de calcul dimensionnées par tailles de t-shirt (XS à 6XL), qu’on démarre, suspend et redimensionne.
Point souvent mal compris : plusieurs warehouses ne sont pas plusieurs moteurs. C’est le même moteur Snowflake, instancié sur plusieurs pools de ressources isolés — ce qui sert à séparer les charges (BI d’un côté, ETL de l’autre) sans qu’elles se concurrencent.
Databricks superpose deux couches d’exécution :
Photon n’est pas une alternative à Spark, c’est un moteur qui s’y substitue silencieusement quand il peut. Votre code df.filter(...).groupBy(...).agg(...) ne change pas ; ce qui l’exécute change.
C’est le point qui manque à presque toutes les comparaisons, et c’est celui qui coûte de l’argent en production. Photon accélère une partie des opérations. Pour tout le reste, il retombe sur Spark JVM — sans erreur, sans avertissement, sans ligne dans les logs.
| Opération | Photon |
|---|---|
SELECT, filter, join, groupBy, agrégations | Accéléré |
| Écritures Delta et Parquet | Accéléré |
Fonctions natives org.apache.spark.sql.functions.* | Accéléré |
| UDF Python ou Scala | Repli sur Spark JVM |
| API RDD | Repli sur Spark JVM |
| Certains types complexes et fonctions rares | Repli sur Spark JVM |
| Structured Streaming (selon les opérateurs) | Partiel |
Conséquence très concrète : vous payez le supplément Photon, vous croyez tourner en C++ vectorisé, et une seule UDF Python au milieu du pipeline renvoie l’étape entière sur la JVM. Le gain annoncé s’évapore sans que rien ne le signale.
C’est exactement le mécanisme décrit dans pourquoi votre UDF est dix fois plus lente, avec un coût supplémentaire : sur Databricks avec Photon, une UDF ne casse pas seulement l’optimisation de Catalyst, elle vous éjecte du moteur rapide.
C’est mesurable, et ça devrait faire partie de toute revue de performance :
df.explain(true)
// Les nœuds préfixés par "Photon" sont exécutés en C++ :
// PhotonResultStage
// PhotonGroupingAgg
// PhotonScan parquet
//
// Un nœud sans préfixe est exécuté par Spark JVM.Dans l’UI, l’onglet Spark UI → SQL / DataFrame annote les étages Photon, et le query profile de Databricks SQL indique explicitement le pourcentage de temps passé en Photon. Un pipeline « Photon » qui affiche 20 % de temps Photon a un problème identifiable — presque toujours une UDF ou un reste d’API RDD.
L’argument « Snowflake c’est du SQL, Databricks c’est du code » était juste en 2021. Il ne l’est plus.
Snowpark offre une API DataFrame en Python, Scala et Java, dont la syntaxe est délibérément proche de celle de Spark :
# Snowpark — ressemble à PySpark, s'exécute dans le moteur Snowflake
from snowflake.snowpark.functions import col, avg
df = session.table("commandes")
resultat = (
df.filter(col("montant") > 100)
.group_by("region")
.agg(avg("montant").alias("panier_moyen"))
)Différence de fond : Snowpark compile ces opérations en SQL Snowflake et les exécute dans le moteur propriétaire. Rien ne sort du moteur — c’est ce qui lui permet d’être rapide, et ce qui le limite quand vous avez besoin de code arbitraire. Pour ce cas, Snowflake propose des UDF Python et des Container Services, avec le même genre de compromis que les UDF Spark.
Autrement dit : les deux plateformes ont convergé. Snowflake a ajouté du code et les formats ouverts (tables Iceberg) ; Databricks a ajouté du SQL serverless et des entrepôts prêts à l’emploi. Le fossé de 2021 s’est largement comblé.
Pas automatiquement, et c’est un point qu’il faut poser honnêtement.
L’opacité de Snowflake est une fonctionnalité pour beaucoup d’équipes : pas de partitions à dimensionner, pas de spark.sql.shuffle.partitions à régler, pas de skew de jointure à diagnostiquer, pas de niveaux de cache à choisir. Le moteur décide. Une équipe de trois analystes livrera plus vite sur Snowflake, précisément parce qu’il y a moins de leviers à mal positionner.
La flexibilité de Databricks est un avantage si vous avez les compétences pour l’exploiter. Les mêmes réglages qui permettent un facteur 10 permettent aussi un facteur 10 dans l’autre sens. Tous les sujets traités dans les partitions et le shuffle ou les stratégies de jointure sont du travail que Snowflake ne vous demande pas.
Le bon critère n’est donc pas « lequel a le plus de moteurs », mais « ai-je des charges qui justifient de piloter le moteur, et l’équipe pour le faire ».
Le moteur est rarement le facteur déterminant. Deux questions le sont bien davantage.
1. Où vos données doivent-elles vivre ? Databricks écrit du Delta et du Parquet sur votre stockage objet : les mêmes fichiers sont lisibles par Spark, Trino, DuckDB, pandas ou Athena. Snowflake stocke historiquement dans un format propriétaire (les tables Iceberg changent la donne, mais le mode par défaut reste le sien). Si la portabilité et le multi-moteur comptent, ce point pèse plus lourd que n’importe quel benchmark. C’est le sujet développé dans écrire proprement en Parquet et Delta Lake.
2. Quelle est la forme de vos charges ?
| Charge dominante | Plateforme plus confortable |
|---|---|
| BI, tableaux de bord, forte concurrence SQL | Snowflake |
| Entrepôt classique, SQL analytique | Snowflake |
| ETL / ELT sur fichiers bruts, semi-structurés | Databricks |
| Streaming | Databricks |
| Machine learning, IA, notebooks | Databricks |
| Code arbitraire, bibliothèques Python | Databricks |
| Partage de données entre organisations | Les deux, approches différentes |
Sur la seule dimension du moteur d’exécution, Databricks offre plus de latitude : Spark pour tout ce qui est arbitraire, Photon pour les charges SQL et DataFrame, un choix explicite selon le besoin. C’est un avantage réel pour du data engineering, du streaming et du ML.
Mais cet avantage a trois conditions, toutes vérifiables avant de décider :
Si les trois sont vraies, Databricks est plus avantageux côté moteur. Si l’une est fausse, Snowflake livrera probablement plus vite et pour moins cher en coût total — licences et temps d’ingénierie.
Snowflake, c’est un moteur propriétaire exposé à travers plusieurs warehouses de calcul isolés. Databricks, c’est Spark plus Photon, avec un basculement automatique vers la JVM dès qu’une opération n’est pas prise en charge — et c’est ce repli silencieux, sur les UDF et l’API RDD, qui fait la différence entre le gain annoncé et le gain réel.
Le débat « quel moteur » est cependant moins décisif qu’il n’y paraît : les deux plateformes ont convergé, Snowpark d’un côté, SQL serverless de l’autre. Ce qui reste vraiment structurant, c’est le format de stockage — ouvert et relisible par d’autres outils, ou propriétaire et optimisé — et la forme de vos charges. Répondez à ces deux questions d’abord ; le moteur suivra.
Développement et déploiement de solutions de données — les premiers modules sont en accès libre.