Is Your dbt Run Quietly Driving Up Warehouse Compute?

dbt, now one company with Fivetran, runs every model in the warehouse. That is the right architecture. It also means that inefficiency has no error state: a model that rebuilds a year of history every night succeeds, and the cost shows up somewhere else.

Why compute creeps

• Full rebuilds are the default. A table materialization drops and recreates on every run. Making it incremental is extra work per model, and that work is easy to postpone.
• Incremental logic is bespoke. Unique keys, lookback windows and merge strategies are decided per model, by whoever wrote it, and across developers they drift.
• The DAG runs wider than the change. One changed input can trigger a run across many downstream models, most of which produce the same output as yesterday.
• Nobody profiles what works. A green run is the finish line. Compute per model is visible in the warehouse console, not in the pipeline.

None of this is a dbt fault. Hand-written transformation logic is as efficient as the person who wrote it had time to make it.

Where efficiency belongs

• Delta loading should be the only kind. If the load pattern is generated, incremental is not a choice a developer makes under deadline. It is how every load is written.
• History should be isolated in one place. Satellites hold change over time, so the mart layer never has to recompute history to answer a question about now.
• Set based SQL for the engine you run. Generated code can be tuned per platform once, rather than per model by whoever wrote it.

What changes with Datavault Builder

Datavault Builder generates set based delta loads for hubs, links and satellites, tuned to the target engine, so the expensive part of the pipeline only ever touches what changed.

• Every load is a delta by construction. New and changed rows are detected against what is already historized. Nothing is dropped and recreated.
• History lives in satellites. As-was questions are answered from stored change, not by rebuilding the past on every run. Bi-temporal loads and point in time tables are patterns the platform offers out of the box, not something to build from macros.
• The run scope follows the model. Dependencies are derived, so a change loads what it touches and nothing beyond it.
• dbt State and Fusion still help if dbt stays. Datavault Builder can generate the dbt models for teams that keep operations there, and those benefit from skipped unchanged models. The generated layers underneath never needed skipping, because they were never doing the full work.
• Compute is predictable. The load cost tracks how much the sources changed, not the total size of the warehouse, and that is a number you can watch.

What to decide

Take the ten most expensive models from the last month of warehouse query history. If most of them are staging or history models rebuilt in full, that is the generated layer waiting to exist.