La tarification Dagster+ fonctionne par crédits. La consommation de crédits est facile à sous-estimer, particulièrement pour les grands projets dbt ou les exécutions à haute fréquence, donc le budget nécessite de comprendre le modèle.
Le modèle de crédits
1 crédit = 1 matérialisation d’asset ou 1 exécution d’op.
Chaque fois que Dagster matérialise un asset — exécute une fonction Python, exécute un modèle dbt, synchronise un connecteur Fivetran — c’est un crédit. Pour les projets dbt, chaque matérialisation de modèle compte comme un crédit séparé car chaque modèle est un asset séparé.
Cela signifie qu’un projet dbt de 100 modèles exécuté quotidiennement utilise approximativement 3 000 crédits par mois (100 modèles x 30 jours). La mathématique est simple mais les implications surprennent : ajouter des modèles, augmenter la fréquence d’exécution, ou lancer des matérialisations ad-hoc consomment tous des crédits.
Niveaux de plans
| Plan | Prix | Crédits/mois | Utilisateurs | Idéal pour |
|---|---|---|---|---|
| Solo | 10 $/mois | 7 500 | 1 | Praticiens solo, petits projets dbt |
| Starter | 100 $/mois | 30 000 | Jusqu’à 3 | Petites équipes, projets dbt modérés |
| Pro | Contacter les ventes | Personnalisé | Personnalisé | Grandes équipes, fonctionnalités enterprise |
Dépassement
Au-delà des crédits inclus dans le plan : 0,03 $/crédit.
Pour référence : un projet dbt de 100 modèles exécuté quotidiennement (3 000 crédits) s’inscrit confortablement dans le plan Solo à 10 $/mois avec 4 500 crédits de marge. Mais un projet de 200 modèles exécuté deux fois par jour (12 000 crédits) dépasse Solo et pousse vers le territoire Starter. Ajoutez des capteurs, des assets Python et des matérialisations ad-hoc, et la consommation de crédits croît plus vite que le nombre de modèles dbt seul ne le suggère.
Calcul Serverless
Si le calcul serverless de Dagster est utilisé (où Dagster exécute le code sur son infrastructure plutôt que la vôtre), il y a un coût supplémentaire : 0,005 $/minute de calcul sur Solo et Starter. Cela s’applique quand Dagster exécute le calcul réel — exécuter dbt, traiter des fonctions Python, etc. Pour les workloads qui orchestrent principalement des services externes (dire à BigQuery d’exécuter une requête, déclencher une synchronisation Fivetran), les minutes de calcul sont minimales. Pour le traitement Python intensif, elles s’accumulent.
Comparaisons de coûts
La tarification prend le plus de sens en comparaison avec les alternatives.
vs dbt Cloud
| dbt Cloud Starter | Dagster+ Solo | Dagster+ Starter | |
|---|---|---|---|
| Coût mensuel | 100 $/utilisateur/mois | 10 $/mois | 100 $/mois |
| Équipe de 3 personnes | 300 $/mois | N/A (1 utilisateur) | 100 $/mois |
| Inclut | Ordonnancement dbt, CI, docs, IDE | Orchestration complète, ordonnancement, capteurs, lignée | Idem + 3 utilisateurs, plus de crédits |
| Orchestration cross-système | Non inclus | Inclus | Inclus |
Pour l’orchestration pure dbt, Dagster+ est moins cher. La comparaison complète couvre ce qu’on perd (IDE dbt Cloud, hébergement de documentation, accès semantic layer) et ce qu’on gagne (orchestration cross-système, ordonnancement piloté par événements, UI unifiée).
vs Cloud Composer
Cloud Composer 3 démarre à environ 300-400 $/mois au repos. Dagster+ Solo à 10 $/mois est 30-40x moins cher pour les petits workloads. Même le tarif engagé 3 ans de Composer (~160-215 $/mois) est plus cher que Dagster+ Starter.
L’écart de coût se réduit à grande échelle. Le coût de Composer est relativement fixe (on paie pour l’environnement), tandis que Dagster+ évolue avec l’utilisation. Une équipe exécutant des milliers de matérialisations d’assets quotidiennement peut trouver les coûts comparables, voire inversés.
vs Dagster open source
La version open source gratuite (licence Apache 2.0) ne coûte rien pour le logiciel lui-même. L’auto-hébergement nécessite de l’infrastructure : une base de données PostgreSQL pour le stockage des exécutions, un serveur web, un processus daemon, et du calcul pour l’exécution. Sur GCP, cela implique un cluster GKE ou une VM, plus Cloud SQL. Le coût d’infrastructure dépend du dimensionnement mais commence typiquement à 50-100 $/mois sur GCP.
Ce qu’on perd avec l’open source :
- Pas de RBAC (contrôle d’accès basé sur les rôles)
- Pas de déploiements de branches
- Pas d’alertes vers des services externes (Slack, PagerDuty)
- Pas de recherche dans le catalogue ni de fonctionnalités Dagster+ Pro
- Pas d’infrastructure gérée ni de support
Pour les praticiens solo et les petites équipes, Dagster+ Solo à 10 $/mois est presque certainement moins cher que l’auto-hébergement quand on tient compte du coût en temps de gestion de l’infrastructure.
Pièges de consommation de crédits
Chaque modèle dbt est un crédit
Un dbt build qui exécute 100 modèles consomme 100 crédits, pas 1. C’est parce que chaque modèle est un Asset Software-Défini séparé. Les équipes migrant depuis dbt Cloud (qui facture par utilisateur, pas par exécution) sous-estiment parfois cela.
Les exécutions d’ops comptent aussi
Les crédits ne sont pas seulement des matérialisations d’assets. Chaque exécution d’op (la primitive Dagster de bas niveau sur laquelle les assets sont construits) compte également. Pour la plupart des workflows d’analytics engineering, ça n’a pas d’importance — on travaille avec des assets, pas des ops bruts. Mais si des pipelines personnalisés sont construits avec le décorateur @op, ces exécutions s’ajoutent à la facture.
Les capteurs et schedules ne consomment pas de crédits
Les tics de capteurs et les évaluations de schedules sont gratuits. Seules les matérialisations réelles consomment des crédits. Un capteur qui vérifie toutes les 5 minutes si Fivetran a terminé ne coûte rien jusqu’à ce qu’il déclenche une matérialisation.
Les matérialisations ad-hoc comptent
Matérialiser manuellement un asset dans l’UI (courant pendant le débogage ou le développement) consomme un crédit. Si on itère sur un modèle en le matérialisant 20 fois dans une journée, c’est 20 crédits. Pour les workflows de développement, envisager d’utiliser dagster dev en local où les matérialisations ne comptent pas dans les crédits Dagster+.
Heuristique de budget
Une estimation budgétaire raisonnable :
- Compter les modèles dbt
- Multiplier par les exécutions quotidiennes (1x pour quotidien, 2x pour deux fois par jour, etc.)
- Multiplier par 30 jours
- Ajouter 20-30% pour les capteurs, les assets Python, les exécutions ad-hoc
Exemple : 150 modèles, exécutions quotidiennes = 150 x 1 x 30 = 4 500 crédits de base + 30% de marge = ~5 850 crédits/mois. S’inscrit dans Solo (7 500 inclus) à 10 $/mois.
Exemple : 300 modèles, deux fois par jour = 300 x 2 x 30 = 18 000 crédits de base + 30% = ~23 400 crédits/mois. S’inscrit dans Starter (30 000 inclus) à 100 $/mois.
Surveiller l’utilisation dès la première semaine. Le dashboard Dagster+ montre les tendances de consommation de crédits.