dbt Cloud coûte 100 $ par utilisateur par mois. Dataform ne coûte rien au-delà des dépenses BigQuery existantes. Pour une équipe de 10 analytics engineers, cela représente 12 000 $ d’économies annuelles de licence — 36 000 $ sur trois ans. Si ces économies se maintiennent dépend des coûts d’ingénierie cachés de l’exploitation de Dataform.
Le calcul de la licence
Le modèle de tarification de Dataform est genuinement zéro — pas de frais de licence, pas de facturation par siège, pas de niveaux d’utilisation. On paie uniquement pour le compute BigQuery que les transformations consomment. Puisque dbt envoie également du SQL à BigQuery pour exécution, les coûts de compute sont identiques entre les deux outils pour la même logique de transformation. La seule variable est la couche de licence au-dessus.
Pour les budgets enterprise, 12 000 $ par an peuvent sembler dérisoires. Mais cela s’accumule au fil de la croissance de l’équipe et du temps. Plus important encore, pour les petites équipes, les startups, ou les organisations sensibles aux coûts, ce poste budgétaire est difficile à justifier quand une alternative gratuite existe et couvre le cas d’usage principal.
La fusion dbt-Fivetran annoncée en octobre 2025 ajoute de l’incertitude. L’entité combinée approchant 600 M$ d’ARR signale une consolidation du secteur. dbt ne va nulle part, mais la tarification et le packaging peuvent évoluer. La position de Dataform en tant qu’alternative gratuite soutenue par Google devient plus stratégiquement précieuse si les coûts de dbt Cloud augmentent.
Les coûts de compute s’annulent
Un malentendu courant est que le choix de l’outil de transformation affecte les coûts de l’entrepôt. Ce n’est pas le cas. Dataform et dbt compilent tous deux en SQL et l’envoient à BigQuery. Les coûts de requêtes dépendent de la qualité d’écriture des transformations — partitionnement, clustering, stratégies incrémentales, élagage des colonnes — pas de l’outil qui les compile.
Un cas d’usage Bilt Rewards a montré 20 000 $ d’économies mensuelles sur BigQuery grâce aux modèles incrémentaux. Ces modèles ont été implémentés dans dbt, mais Dataform supporte les tables incrémentales avec une capacité équivalente. Le potentiel d’optimisation est identique car l’entrepôt ne se soucie pas de l’outil qui a généré le SQL.
Le modèle de coût BigQuery — qu’il soit à la demande sur les octets facturés ou en heures de slots Editions — s’applique identiquement qu’il s’agisse de Dataform ou de dbt qui a soumis la requête.
Les coûts cachés du “gratuit”
Le coût zéro de licence de Dataform masque des coûts d’ingénierie que dbt Cloud absorbe :
Configuration CI/CD. dbt Cloud fournit un Slim CI intégré — construisant automatiquement uniquement les modèles modifiés, créant des schémas spécifiques aux PR, exécutant le linting SQL. Quelques clics et ça fonctionne. Répliquer cela dans Dataform requiert d’appeler l’API REST Dataform depuis des outils CI externes comme GitHub Actions ou Cloud Build. Budgétisez 2 à 4 semaines de temps d’ingénierie pour construire et maintenir une automatisation comparable.
Infrastructure de testing. Les assertions intégrées de Dataform couvrent trois scénarios : unicité, contrôles de nullité, et conditions de ligne. L’écosystème dbt fournit 50+ tests via dbt_expectations, de la détection d’anomalies via Elementary, et des tests unitaires natifs. Construire une couverture équivalente dans Dataform signifie écrire des fichiers d’assertions personnalisées manuellement. C’est du temps d’ingénierie continu, pas un coût ponctuel.
Lacunes d’outillage. L’absence d’IDE local avec des fonctionnalités orientées transformation (visualisation de lignée, auto-complétion des colonnes, estimation de coût) signifie des cycles de développement plus lents. La différence de productivité est difficile à quantifier mais se cumule à travers chaque développeur de l’équipe, chaque jour.
Écosystème de packages. dbt compte plus de 200 packages sur hub.getdbt.com. Quand on a besoin d’une transformation GA4, d’une modélisation d’attribution, ou d’une normalisation CRM, un package dbt permet d’y arriver en quelques heures. Dans Dataform, on construit de zéro.
Le calcul du seuil de rentabilité
La vraie question n’est pas “quel outil coûte le moins” mais “le coût de migration dépasse-t-il les économies de licence ?”.
Pour une équipe actuellement sur dbt, le coût de migration inclut :
- Le temps d’ingénierie pour convertir les modèles (1-2 semaines pour les petits projets, 2-6 mois pour les entreprises)
- La reconstruction de l’automatisation CI/CD
- La réécriture des macros Jinja personnalisées en JavaScript
- L’exécution parallèle et la validation
- La requalification de l’équipe
Si le coût total de migration dépasse deux années d’économies de licence, rester sur dbt a du sens financier indépendamment de la licence continue. L’horizon de deux ans est raisonnable car le paysage des outils de transformation évolue suffisamment fréquemment pour que les projections à plus long terme soient peu fiables.
Pour les projets greenfield — nouvelles équipes démarrant sans investissement dbt existant — le calcul est différent. Il n’y a pas de coût de migration. La question devient : les lacunes écosystémiques coûteront-elles plus en temps d’ingénierie que les économies de licence ? Pour des besoins de transformation simples sur BigQuery, la réponse est souvent non.
Considérations liées au marché des carrières
La transférabilité sur le marché des carrières est un coût qui n’apparaît sur aucune feuille de calcul. 87 % des analytics engineers nord-américains gagnent plus de 100 000 $. La maîtrise de dbt apparaît dans presque toutes les offres d’emploi dans les entreprises orientées données. L’expertise Dataform reste de niche. Investir du temps de développement dans Dataform construit des compétences à transférabilité limitée sur le marché, ce qui affecte le recrutement et la rétention.