dbt Cloud dispose d’un planificateur intégré qui gère les cron jobs, les vérifications de fraîcheur des sources et les builds CI sur les PRs. Pour les équipes ne faisant que des transformations SQL sans dépendances cross-système, cela couvre le besoin d’orchestration. L’écart de capacités entre dbt Cloud et l’intégration dagster-dbt détermine si le surcoût de configuration et les connaissances Python supplémentaires sont justifiés.
Ce que dbt Cloud ne peut pas faire
Les limites sont spécifiques et méritent d’être énumérées, car elles définissent la frontière où Dagster commence à apporter de la valeur :
- Orchestrer des tâches non-dbt. Les pipelines d’ingestion (synchronisations Fivetran, pipelines dlt, extracteurs personnalisés), les jobs de traitement Python, les appels API, l’entraînement de modèles ML — rien de tout cela ne peut être géré dans dbt Cloud. La transformation dbt est une étape dans un pipeline plus large, mais dbt Cloud ne peut voir que sa propre étape.
- Gérer les dépendances cross-système. « Exécuter dbt après la fin de cette synchronisation Fivetran » nécessite de la colle externe — un webhook, un alignement cron, ou un orchestrateur séparé. Dagster gère cela nativement via les capteurs et les conditions d’automatisation.
- Exécuter des exécutions partitionnées. Matérialiser des modèles dbt pour une plage de dates ou une région spécifique. Le système de partitions Dagster s’intègre avec les modèles incrémentiels dbt pour permettre des backfills ciblés et une surveillance au niveau des partitions.
- Fournir une lignée unifiée sur toute la stack de données. dbt Cloud montre la lignée dans dbt. Dagster montre la lignée depuis l’ingestion des sources à travers la transformation jusqu’à la consommation en aval. Quand il faut retracer un problème de qualité des données depuis un dashboard à travers dbt jusqu’à la source brute, la lignée cross-système compte.
Ces limitations ne sont pas théoriques pour de nombreuses équipes. Dès qu’il y a une étape de prétraitement Python, un déclencheur piloté par événements, ou un besoin de coordonner dbt avec l’ingestion en amont, dbt Cloud nécessite de toute façon d’y ajouter un orchestrateur externe.
La comparaison des coûts
La mathématique des coûts favorise souvent Dagster, notamment pour les petites équipes.
Un projet dbt de 100 modèles exécuté quotidiennement utilise environ 3 000 crédits par mois. Sur Dagster+ Solo (le niveau d’entrée), ça s’inscrit confortablement à 10 $/mois. dbt Cloud Starter coûte 100 $/utilisateur/mois. Pour une équipe de 3 personnes :
| dbt Cloud Starter | Dagster+ Starter | |
|---|---|---|
| Coût mensuel | 300 $/mois (3 utilisateurs) | 100 $/mois |
| Inclut | Ordonnancement dbt, CI, docs | Orchestration complète, ordonnancement, capteurs, lignée |
| Orchestration cross-système | Non inclus | Inclus |
La comparaison n’est pas parfaitement nette — dbt Cloud inclut l’IDE, l’hébergement de la documentation et l’accès au semantic layer que Dagster ne fournit pas. Mais pour l’orchestration spécifiquement, Dagster offre plus de capacités à moindre coût.
À plus grande échelle, la tarification dbt Cloud Enterprise est négociée, et la tarification Dagster+ évolue avec le calcul. L’avantage de coût se réduit ou s’inverse selon les patterns d’utilisation. Mais pour les équipes dans la fourchette 100-500 $/mois, la différence est significative.
L’argument de l’indépendance vis-à-vis des fournisseurs
La fusion Fivetran-dbt Labs d’octobre 2025 ajoute une dimension stratégique à la décision. Comme dbt Cloud s’intègre dans la plateforme intégrée de Fivetran, les équipes qui veulent l’indépendance vis-à-vis des fournisseurs dans leur couche d’orchestration ont une raison supplémentaire de garder l’orchestration séparée.
La préoccupation n’est pas que dbt Cloud cessera de fonctionner. C’est que la feuille de route produit s’optimisera de plus en plus pour Fivetran comme couche d’ingestion, potentiellement au détriment des équipes utilisant dlt, Airbyte, des extracteurs personnalisés ou d’autres outils d’ingestion. Si la stratégie de pipeline de données inclut une ingestion non-Fivetran, une couche d’orchestration indépendante garantit de pouvoir changer de composants sans réécrire l’orchestration.
C’est le même principe qui s’applique aux décisions construire vs acheter plus largement : découpler l’orchestration de la transformation donne la liberté de changer l’un ou l’autre indépendamment. Dagster ou Airflow comme couche d’orchestration permet de changer les outils d’ingestion, de transformation et de service sans toucher à la logique de coordination.
Quand dbt Cloud est suffisant
dbt Cloud est le bon choix pour les équipes qui répondent à tous ces critères :
- Uniquement des transformations SQL. Pas de traitement Python, pas d’ingestion personnalisée, pas de pipelines ML. Le projet dbt est toute la couche de transformation.
- Pas de coordination cross-système. Les données en amont arrivent selon un calendrier prévisible. Pas besoin de déclencheurs pilotés par événements ou d’exécution conditionnelle.
- Les fonctionnalités de dbt Cloud couvrent les besoins. L’IDE, l’hébergement de la documentation, le semantic layer et les jobs CI sont précieux pour l’équipe. Ce sont de vraies capacités que Dagster ne remplace pas.
- Le budget permet la tarification par utilisateur. Le modèle de coût par utilisateur fonctionne pour la taille de l’équipe. Les petites équipes (1-2 personnes) peuvent trouver le niveau dbt Cloud Developer (100 $/mois) comparable à la tarification Dagster+.
Pour les équipes analytiques qui vivent entièrement dans SQL et ne veulent pas maintenir d’infrastructure Python, dbt Cloud supprime les frais opérationnels que Dagster ajoute. L’IDE seul est une fonctionnalité de productivité significative pour les analytics engineers qui préfèrent ne pas travailler dans un environnement de développement local.
Quand Dagster mérite sa complexité
Dagster ajoute de la complexité : du code Python, un déploiement séparé à gérer, des concepts comme les assets et les capteurs qui nécessitent un apprentissage. Cette complexité est justifiée quand :
- Le pipeline couvre l’extraction, la transformation et la mise à disposition. La vision full-stack — Fivetran ou dlt pour l’ingestion, dbt pour la transformation, Python pour le traitement ML/API, des capteurs pour les déclenchements en aval — est là où le graphe d’assets unifié de Dagster apporte une valeur qu’aucun outil spécialisé ne peut égaler.
- L’orchestration pilotée par événements est nécessaire. « Exécuter dbt quand les données arrivent » plutôt que « exécuter dbt à 6h00 et espérer ». Les capteurs et les politiques de fraîcheur gèrent cela nativement.
- Le coût compte et l’équipe est petite. La différence de prix entre 10-100 $/mois (Dagster+) et 100-300 $/mois (dbt Cloud par utilisateur) est significative pour les consultants solo et les petites équipes.
- L’indépendance vis-à-vis des fournisseurs est souhaitée. Garder l’orchestration séparée de la transformation et de l’ingestion donne la flexibilité de changer n’importe quel composant indépendamment.
Montée en compétence
L’onboarding sur Dagster prend typiquement quelques semaines pour la partie Python et les concepts. L’intégration dagster-dbt réduit la barrière initiale — le projet dbt existant se mappe en assets Dagster avec un code minimal, mais comprendre les capteurs, les ressources, les conditions d’automatisation et le modèle de déploiement prend du temps.
Dagster University fournit un apprentissage structuré. Pour les équipes migrant depuis dbt Cloud, la migration est additive : le projet dbt ne change pas. Dagster l’enveloppe, et les deux peuvent tourner en parallèle pendant la transition. Voir Courbe d’apprentissage Dagster pour les analytics engineers pour les détails sur les points de friction.
Heuristique de décision
Si le pipeline est « cron déclenche dbt, dbt écrit dans le warehouse, l’outil BI lit le warehouse », dbt Cloud ou les Cloud Run Jobs est suffisant. La coordination cross-système — « exécuter dbt après que Fivetran a terminé », « déclencher un rafraîchissement Looker après que les marts sont frais », « exécuter un modèle Python avant la couche dbt » — est là où le modèle conscient des assets de Dagster s’applique.