Cadre de décision dbt Core vs Cloud

Choisir entre dbt Core et dbt Cloud n’est pas un test de pureté technique. C’est une décision pratique qui dépend des compétences de votre équipe, du budget, de l’appétit pour l’infrastructure et de la quantité de « tout ce qui entoure dbt » que vous souhaitez gérer vous-même.

Les deux versions utilisent le même SQL, le même Jinja, les mêmes fonctions ref() et source(), le même framework de tests, la même structure de projet. La logique de transformation est identique. Les différences portent sur tout ce qui l’entoure : comment vous développez, déployez, planifiez, collaborez, et ce que vous payez.

La matrice de comparaison

Déploiement : auto-hébergé vs managé

dbt Core s’exécute là où vous le placez. Votre laptop pour le développement. Un Cloud Run Job pour la production. Un conteneur Docker sur Kubernetes. Un worker Airflow. La flexibilité de déploiement est totale, mais la responsabilité l’est aussi.

# Déploiement dbt Core : vous gérez tout
docker build -t my-dbt .
docker push gcr.io/my-project/my-dbt
gcloud run jobs create dbt-daily --image gcr.io/my-project/my-dbt
gcloud scheduler jobs create http dbt-trigger --schedule "0 6 * * *" ...

Déploiement dbt Cloud : créez un projet, connectez votre dépôt Git, configurez un environnement, planifiez un job. Cinq clics et une expression cron. Pas de conteneurs, pas de registres, pas de planificateurs à configurer.

L’écart n’est pas de savoir si les deux approches fonctionnent — elles fonctionnent. L’écart est la surface opérationnelle que vous acceptez. Core auto-hébergé signifie que vous gérez les builds de conteneurs, les mises à niveau de versions, la gestion des identifiants, le monitoring et la réponse aux incidents pour le runtime dbt. dbt Cloud signifie que dbt Labs gère tout cela, et que vous ne gérez que le SQL.

Interface : CLI vs IDE web

Le choix CLI vs IDE corrèle fortement avec la composition de l’équipe.

Les équipes CLI-natives (ingénieurs logiciels, ingénieurs de plateforme, analytics engineers expérimentés) préfèrent l’interface en ligne de commande de dbt Core parce qu’elle s’intègre à leur outillage existant. VS Code avec l’extension dbt Power User, Git en terminal, scripts shell personnalisés pour les opérations courantes. Le CLI est plus rapide pour les utilisateurs avancés qui pensent en termes de dbt run --select tag:finance+ --exclude config.materialized:ephemeral.

Les équipes axées sur SQL (analystes qui migrent vers l’analytics engineering, professionnels de données côté métier) préfèrent l’IDE web de dbt Cloud parce qu’il élimine toutes les barrières entre « je veux écrire du SQL » et « j’écris du SQL ». Pas de Python. Pas de terminal. Pas d’environnements virtuels. Ouvrir le navigateur et commencer.

Aucune préférence n’est incorrecte. La meilleure interface est celle que votre équipe utilise vraiment de manière productive. Une équipe qui peine avec la configuration Python perd des heures sur une infrastructure que dbt Cloud élimine. Une équipe d’ingénieurs qui vivent dans VS Code trouve l’IDE web plus lent et plus contraint que leur configuration existante.

Planification et orchestration

C’est là où la différence pratique est la plus marquée.

dbt Core n’a pas de planificateur. Il s’exécute quand vous l’invoquez. Pour les déploiements en production, vous avez besoin d’un outil externe :

dbt Cloud inclut la planification, les déclencheurs CI et l’invocation via API. Pour les équipes dont les besoins d’orchestration se résument à « exécuter dbt selon un planning et lancer des tests sur les PRs », Cloud élimine le besoin d’évaluer, configurer et maintenir un outil séparé.

La frontière est claire : si vos besoins d’orchestration vont au-delà de dbt (déclencher dbt après une synchronisation d’ingestion, exécuter Python après dbt, coordonner plusieurs pipelines), le planificateur de dbt Cloud est insuffisant quelle que soit la situation. Vous avez besoin d’un orchestrateur. La comparaison avec Dagster et le cadre d’orchestration GCP détaillent cette frontière.

L’équation de tarification

La comparaison des coûts dépend fortement de la taille de l’équipe :

Le coût d’infrastructure pour Core auto-hébergé est quasi fixe quelle que soit la taille de l’équipe. dbt Cloud évolue linéairement par utilisateur. À trois utilisateurs, la différence annuelle est d’environ 3 500 $. À dix utilisateurs, elle est d’environ 12 000 $. À vingt, significativement plus.

Mais le coût d’infrastructure brut n’est pas le coût total de possession. Core auto-hébergé nécessite du temps d’ingénierie pour :

• La configuration initiale : conteneurisation, CI/CD, planification (~1-2 semaines)
• La maintenance continue : mises à niveau de versions, débogage, monitoring (~2-4 heures/mois)
• La réponse aux incidents : quand le planificateur tombe en panne, le conteneur plante ou les identifiants expirent

Si votre équipe dispose d’un ingénieur qui gère cela aisément, le coût total reste faible. Si vous deviez recruter ou externaliser cette compétence, l’avantage de coût se réduit ou disparaît.

L’heuristique de décision

Choisir dbt Core quand :

• Votre équipe inclut au moins un ingénieur à l’aise avec Python, Docker et les outils CLI
• Vous valorisez une flexibilité et un contrôle maximaux sur votre déploiement
• Le coût compte et votre équipe est composée de plus de deux personnes
• Vous disposez déjà d’un orchestrateur (Airflow, Dagster, Prefect) pour les workloads non-dbt
• Vous souhaitez éviter le vendor lock-in, notamment après la fusion Fivetran
• Disposer d’une structure de projet solide dès le début est quelque chose que votre équipe peut établir de manière autonome

Choisir dbt Cloud quand :

• Votre équipe est principalement axée sur SQL avec une expérience limitée en infrastructure
• L’IDE web et les fonctionnalités de collaboration accélèrent le workflow de votre équipe
• Vous avez besoin de CI/CD sur les pull requests sans le construire vous-même
• Vous avez besoin de la couche sémantique, de Mesh ou du moteur Fusion (fonctionnalités Cloud uniquement)
• Le coût par utilisateur est acceptable pour votre taille d’équipe
• Vous souhaitez minimiser le temps consacré à tout ce qui n’est pas du SQL

La voie hybride : Certaines équipes utilisent dbt Cloud pour le développement (IDE, CI) et déploient les runs de production via Core sur leur propre infrastructure. D’autres commencent avec le plan Developer gratuit de Cloud et migrent vers Core auto-hébergé à mesure que l’équipe grandit. Les compétences de modélisation se transfèrent complètement. Vos fichiers .sql, vos tests schema.yml, vos macros — tout fonctionne dans les deux environnements sans modification.

Tendance de divergence des fonctionnalités

L’écart entre Core et Cloud se creuse. Les fonctionnalités exclusives à Cloud (Fusion, couche sémantique, Mesh, CI avancée) s’accumulent à chaque release. Core reste un outil de transformation complet pour la compilation SQL, les tests et la documentation, mais des fonctionnalités comme la couche sémantique, la gouvernance Mesh et le moteur Fusion nécessitent Cloud.

Le calcul build-vs-buy s’applique : la bonne réponse dépend des capacités de l’équipe, des exigences et de la mesure dans laquelle la roadmap du fournisseur s’aligne avec la trajectoire de l’équipe.