Is Your dbt Bill Growing in Seats, or in Engineers?

dbt, now one company with Fivetran, gave SQL the things software engineering had for years: version control, tests, modularity. That is why teams adopt it. The cost conversation arrives later, and it arrives on both of the paths dbt offers.

Why the layer costs more than the license

• dbt Core is free to download, not free to run. Somebody sets up the orchestrator, the CI pipeline, the artifact storage and the state deferral, then keeps them running. That somebody is an engineer who was hired to model data.
• dbt Cloud is priced per developer plus usage. Seats scale with the team, and usage metering means the bill moves with how often models are built. Predictable on a quiet month, less so on a busy one.
• Both paths pay warehouse compute on top. Every run executes in Snowflake, BigQuery or Databricks, and that bill is separate from either the seats or the salaries.
• Both paths own the support. dbt Core is community supported; dbt Cloud adds vendor support for the platform, not for the patterns in your project.
• Both paths own the patterns. When the database ships a new feature, somebody updates the macros, tests them, writes migration scripts for every existing structure and tests those too. That work has no line on either invoice, and over the life of a warehouse it is the largest maintenance cost of the layer.
• Openness is the advantage, and the cost. Every pattern and convention is yours to choose, which is the appeal, and yours to build, test and keep current, which is the bill.
• The choice is framed as one or the other. Either subscriptions or platform engineering. The option nobody presents is a transformation layer that needs less hand-written code in the first place.

Where the cost actually sits

• Most of a dbt project is the same pattern repeated. Staging models, key handling, deduplication and history logic are written per source and re-run per schedule.
• Repeated patterns are what generators are for. A model-driven platform derives that code from the model, so it is neither written nor maintained by hand.
• Custom logic is the small part. Business rules and metrics that genuinely need bespoke SQL are a fraction of the code base, and they are the part dbt is best at.

What changes with Datavault Builder

Datavault Builder generates the staging, raw vault and business vault layers from a visual model, with orchestration, deployment, documentation and lineage in the same platform.

• The generated part leaves the code base. No staging models to write, no incremental macros to maintain, no historization logic to test again for each source.
• Orchestration and CI come with it. Git and Gitflow support, deployment and rollback scripts, and lineage are part of the platform, not a second stack to run.
• So do pattern updates, database updates and support. New database features arrive as updated load patterns with the migration scripts for existing structures included, and support is part of the license rather than a forum.
• The delivery layer is model-driven too. Marts and data products are assembled by drag and drop on the semantic layer, with business rules managed and versioned in the platform, so business oriented people decide which data they need without a dbt developer in the loop.
• dbt is optional, not removed. Teams that want to keep operations in dbt get the dbt models generated from the same model. The process stays model-driven, and a change is a model update and a regeneration, not a hand edit.
• The cost is predictable. A server license in one of three sizes plus the number of developers, and nothing metered per run or per load. No orchestration cluster to operate, and no invoice line that moves with how often the models were built.

What to decide

Audit the project and count the models that exist only to stage, dedupe, key or historize a source. That share of the project is what you are paying for twice, once to write and once to run. It is the part a generator should own.