Alternative à Databricks : où partir et comment migrer sans tout réécrire

Pourquoi partir sur Snowflake. C'est l'entrepôt SQL géré le plus proche de ce que fait Databricks SQL, sans cluster ni machine à gérer. Tu crées un entrepôt virtuel, tu le dimensionnes, il s'arrête tout seul quand personne ne s'en sert. Snowflake documente même la migration depuis Databricks.

Pour qui. Les équipes data de PME et d'ETI dont le travail quotidien est du SQL, des modèles dbt et des tableaux de bord, avec quelques scripts Python.

Pour qui ce n'est pas fait. Une équipe qui entraîne des modèles lourds sur GPU chaque nuit, ou qui écrit surtout du Scala : elle perdra plus qu'elle ne gagnera.

Sa limite. Le crédit est cher en Europe : 2,60 $ en Standard, 3,90 $ en Enterprise et 5,20 $ en Business Critical à Paris, Francfort ou Dublin, contre 2,00 $, 3,00 $ et 4,00 $ en AWS US East. Un entrepôt X-Small consomme 1 crédit par heure. Le stockage coûte 24 $ par To et par mois à Paris. Un entrepôt mal réglé, qui ne se met jamais en pause, coûte autant qu'un cluster Databricks oublié.

Comment migrer. Pour le code SQL, SnowConvert AI convertit le code SQL de tes tables et de tes vues écrit en Spark SQL ou en Databricks SQL. Pour le PySpark, Snowpark Connect fait tourner ton code Spark sur le moteur de Snowflake sans cluster Spark, ce qui évite de tout réécrire d'un coup. Pour les données, Snowflake sait créer une table Iceberg à partir de fichiers Delta en stockage objet : tu peux lire tes tables en place pendant la transition, puis les copier en tables natives. Attention aux différences de dialecte : Netlify a dû remplacer if() par iff() et collect_list() par array_agg(), et la division par zéro renvoie une erreur chez Snowflake là où Databricks renvoie NULL.

Pourquoi partir sur BigQuery. Il n'y a rien à allumer ni à éteindre. Tu écris une requête, Google la fait tourner, tu paies les octets lus. Pour une équipe fatiguée de régler la taille des clusters et les délais d'arrêt automatique, c'est le changement le plus net.

Pour qui. Les entreprises déjà sur Google Cloud, celles qui reçoivent leurs données Google Analytics 4 ou Google Ads, et les équipes qui interrogent leurs données par à-coups plutôt qu'en continu.

Pour qui ce n'est pas fait. Une équipe dont toutes les données vivent sur AWS ou Azure : sortir des téraoctets d'un autre cloud coûte cher, et tu ajoutes un fournisseur.

Sa limite. En mode à la demande, chaque requête coûte 6,25 $ par Tio lu, après 1 Tio gratuit par mois. Un SELECT * sur une grosse table non partitionnée se paie cash. Au-delà d'un certain volume, il faut passer à la capacité réservée (0,06 $ le slot-heure en Enterprise aux États-Unis) et apprendre à la dimensionner. Le stockage actif coûte environ 0,023 $ par Gio et par mois, avec 10 Gio gratuits.

Comment migrer. Si tes tables Delta sont sur Google Cloud Storage, BigQuery les lit directement en tables externes BigLake (CREATE EXTERNAL TABLE), y compris avec les deletion vectors, et suit seul les changements de schéma. Tu peux donc brancher tes tableaux de bord sur BigQuery avant d'avoir déplacé un seul fichier, puis convertir les tables les plus lues en tables natives.

Pourquoi partir sur Fabric. Fabric réunit sous une seule capacité le lakehouse, l'entrepôt, Spark, les pipelines et Power BI. Les tables sont au format Delta dans OneLake, le même format que Databricks : tes fichiers changent d'adresse, pas de nature. Pour une entreprise standardisée sur Microsoft, c'est un seul contrat et une seule console.

Pour qui. Les directions financières et les équipes BI qui utilisent déjà Power BI et Azure, et qui veulent rapprocher la donnée des rapports. Si c'est Power BI lui-même qui te pèse, lis plutôt notre guide pour quitter Power BI.

Pour qui ce n'est pas fait. Une équipe qui a des pics de calcul imprévisibles et ne peut pas attendre : Fabric répond à la surcharge en ralentissant, pas en facturant plus.

Sa limite. Tu paies une capacité allumée, pas une requête. Une F2 en France Centre coûte environ 0,20 $ par CU-heure, soit environ 292 $ par mois si elle tourne 730 heures (notre calcul) ; la réservation sur 1 ou 3 ans fait économiser environ 41 %. Quand la capacité est saturée, Microsoft applique un étranglement par paliers : au-delà de 10 minutes de capacité future consommée, 20 secondes de délai sur les requêtes interactives ; au-delà d'une heure, elles sont refusées ; au-delà de 24 heures, tout est refusé. Le dépassement payant existe, mais coûte trois fois le tarif normal. Et sous la F64, chaque personne qui publie ou lit un rapport a besoin d'une licence Power BI Pro.

Comment migrer. Si tu es sur Azure Databricks, Fabric sait refléter ton catalogue Unity Catalog : seule la structure est copiée, les données restent lues par des raccourcis. Les tables, vues matérialisées et streaming tables sont reflétées ; les vues et les metric views, elles, n'apparaissent pas, pas plus que les tables externes hors format Delta. Pour le reste, crée des raccourcis OneLake vers ton ADLS Gen2 ou ton S3 : un dossier Delta posé dans Tables est reconnu comme une table. Les noms de table avec des espaces ne passent pas.

Pourquoi partir sur EMR. Ton code PySpark tourne tel quel, ou presque, puisque EMR exécute Apache Spark. Tu supprimes la couche DBU : avec EMR Serverless, tu paies le vCPU et la mémoire consommés, à la seconde, avec une minute minimum. Avec EMR sur EC2, tu paies le supplément EMR plus la machine, et les instances Spot peuvent faire économiser jusqu'à 90 % par rapport au prix à la demande.

Pour qui. Les équipes data engineering sur AWS dont les pipelines Spark sont lourds et réguliers, et qui ont quelqu'un pour gérer l'orchestration (Airflow, Step Functions).

Pour qui ce n'est pas fait. Une équipe d'analystes qui veut une interface de notebooks, un catalogue et des tableaux de bord prêts à l'emploi : EMR est un moteur, pas une plateforme.

Sa limite. Tout ce que Databricks fournissait autour de Spark est à recomposer : catalogue (Glue), droits (Lake Formation), notebooks, alertes, déploiement. Sur Reddit, un ingénieur qui prévoyait ce montage se voit rappeler la complexité des droits Lake Formation et le travail d'orchestration qui retombe sur l'équipe. Les fonctions propres à Databricks (dbutils, Delta Live Tables) n'existent pas.

Comment migrer. Liste tes jobs, puis remplace dans chaque notebook les appels dbutils.fs par des appels S3 et dbutils.secrets par AWS Secrets Manager. Convertis les notebooks en scripts Python versionnés. Lance chaque job sur EMR Serverless en parallèle de Databricks et compare les sorties avant de couper. En Europe (Paris), le vCPU-heure coûte 0,06318 $ et le Go-heure de mémoire 0,00689 $.

Pourquoi partir sur Starburst. Starburst Galaxy est un service géré autour de Trino, un moteur SQL qui interroge les fichiers là où ils sont. Tes tables Delta restent dans ton S3 ou ton ADLS, et tu changes seulement ce qui calcule. C'est le départ le moins risqué pour les données.

Pour qui. Les équipes qui ont des données dans plusieurs sources (lac de données, bases, autres entrepôts) et veulent les interroger en SQL sans tout recopier.

Pour qui ce n'est pas fait. Une équipe qui fait surtout du machine learning et des notebooks Python : Starburst est un moteur SQL.

Sa limite. Le prix se lit en crédits : Pro dès 0,50 $ le crédit, Enterprise dès 0,75 $, et un cluster à 2 workers consomme 12 crédits par heure, soit 6 $ de l'heure en Pro. La consommation de crédits est la même sur tous les paliers, seul le prix du crédit change. Le connecteur Delta Lake ne lit pas les vues Databricks, mais il sait lire les tables gérées et externes via le metastore Unity.

Comment migrer. Branche le connecteur Delta Lake sur ton stockage, recrée tes vues en SQL Trino (elles ne viennent pas toutes seules), puis repointe tes tableaux de bord. L'essai de 30 jours donne 500 $ de calcul et les fonctions Enterprise ; ensuite, le compte passe au palier gratuit, avec jusqu'à 3 clusters.

Pourquoi partir sur Dremio. Dremio interroge ton lac de données en SQL et mise sur Apache Iceberg, le format de table ouvert que lisent aussi Snowflake, Starburst ou Spark. Si ta raison de partir est de ne plus dépendre d'un seul éditeur, c'est une bonne porte de sortie.

Pour qui. Les équipes qui veulent un moteur SQL rapide sur leurs fichiers, avec un prix simple à expliquer à la direction.

Pour qui ce n'est pas fait. Une équipe qui veut tout dans un seul outil, pipelines et machine learning compris : Dremio couvre la requête et la couche sémantique, pas l'entraînement de modèles.

Sa limite. Dremio Cloud coûte 0,20 $ par DCU (Dremio Compute Unit), compté selon la taille du moteur et sa durée de fonctionnement : un moteur de 20 DCU allumé 10 heures consomme 200 DCU, soit 40 $. La version Enterprise auto-hébergée est sur devis, et la Community Edition, gratuite, est à faire tourner toi-même.

Comment migrer. Commence par tes tables les plus lues : convertis-les en Iceberg ou expose-les telles quelles, puis repointe un tableau de bord et compare les chiffres. L'essai donne 400 $ de crédits sur 30 jours, sans carte bancaire, de quoi faire un pilote réel.

Pourquoi partir sur ClickHouse. ClickHouse est une base colonnaire conçue pour les agrégations rapides sur de gros volumes d'événements. Pour un tableau de bord affiché à tes clients, ou une analyse de logs, c'est souvent plus rapide et moins cher qu'un SQL warehouse allumé en continu.

Pour qui. Les éditeurs SaaS qui affichent des statistiques à leurs clients, les équipes produit qui analysent des événements, les équipes qui étaient bloquées par le coût des tableaux de bord sur Databricks.

Pour qui ce n'est pas fait. Les traitements lourds avec beaucoup de jointures entre grosses tables, et le machine learning : garde Spark ou un entrepôt pour ça.

Sa limite. ClickHouse demande de penser le modèle de données à l'avance (clé de tri, partitions) ; il pardonne moins qu'un entrepôt généraliste. Le prix se calcule par unité de calcul (8 Gio de RAM et 2 vCPU) et par heure : en Enterprise, de 0,36027 $ (GCP Pays-Bas) à 0,46974 $ (AWS Francfort), plus le stockage de 22 à 26,95 $ par To et par mois. Le palier Basic plafonne à 1 To de stockage.

Comment migrer. Ne migre pas tout : déplace seulement les tables qui servent les tableaux de bord rapides, alimentées depuis ton lac. Exporte l'historique une fois en Parquet depuis ton lac, puis alimente ClickHouse en continu depuis ta chaîne d'ingestion. L'essai donne 300 $ de crédits sur 30 jours.

Pourquoi partir sur MotherDuck. MotherDuck, c'est DuckDB dans le cloud : un moteur SQL très rapide sur un seul nœud, avec du partage et une interface web. Si tes données font quelques centaines de gigaoctets, c'est souvent la façon la plus simple de diviser ta facture.

Pour qui. Les startups et les petites équipes data, celles qui ont 100 à 500 Go de données et des besoins surtout analytiques, et qui aiment tester en local avec DuckDB avant de publier.

Pour qui ce n'est pas fait. Une équipe avec des dizaines de téraoctets et des pipelines Spark complexes, ou une grande entreprise qui a besoin d'une gouvernance fine.

Sa limite. Le plan Lite est gratuit, mais limité à 3 utilisateurs, 10 Go de stockage et 10 heures de calcul par mois. Business coûte 250 $ par mois et par organisation, plus l'usage : 0,60 $ le CU-heure en calcul Pulse et 0,04 $ par Go et par mois de stockage. C'est un outil jeune comparé à Snowflake ou BigQuery.

Comment migrer. DuckDB a une extension delta qui lit tes tables Delta directement depuis S3 avec delta_scan(). Commence par lire tes tables en place, compare tes résultats, puis charge les tables les plus utilisées dans MotherDuck. Business s'essaie 7 jours sans carte.