agent committed a dbt model with the wrong materialization, warehouse costs spiked

TL;DR

Materialization is a cost decision disguised as a config line. A large model committed as a table when it should be incremental rebuilds its whole history on every run, and a model set to view pushes its cost into every downstream query instead. Find the models whose materialization changed, set each to the type its size and usage justify, apply it with the rebuild the change requires, and add project level defaults and review checks so a generated model cannot pick a materialization silently again.

agent committed a dbt model with the wrong materialization, warehouse costs spiked

Use this when

• Warehouse costs spike right after new or changed dbt models were merged.
• Query history shows a model rebuilding a huge table on every run, or downstream queries re-computing a heavy view repeatedly.
• The materialization in the model file differs from what the team believed it was.

Not for this skill when

• Costs rose because run frequency or source volume rose with the configs unchanged. That is capacity, not materialization.
• One emergency full rebuild was run deliberately with the flag. A one off flag is not the committed config.

Steps

1. Attribute the spike: in the warehouse query history, group recent cost by query and map the top queries back to dbt models and their run times. Note the models responsible and when their cost changed. Verify: the spike is tied to named models, not a general impression
2. For each, read the effective materialization from the compiled manifest, including config inherited from the project file, and compare with the size and change rate of its source. Note the mismatch per model. Verify: the wrong setting is proven per model, including inherited config
3. Choose the right materialization per model on evidence: incremental with a sound unique key for large append style models, table for small or fully restated ones, view only for cheap logic over already materialized inputs. Note the choice and the reason per model. Verify: each setting is justified by size and usage, not by habit
4. Apply the changes, run the builds the change requires, a full refresh where the strategy changed, and confirm downstream tests pass. Note the build results. Verify: the corrected models are live and verified
5. Measure the next few runs' cost for those models against the spike period, and add guardrails: project level defaults per folder, and a review or CI check that flags a materialization change on a large model. Note the new per run cost and the check in place. Verify: savings are measured and the mistake is fenced off

Variant phrasings

dbt model materialized as table instead of incremental cost

The classic wrong direction phrasing.

dbt view vs table vs incremental choose materialization cost

The decision searched directly.

Compatibility: dbt Core and Cloud on any warehouse that bills for compute, most sharply Snowflake and BigQuery. Project level config defaults and manifest inspection work across adapters.

Why it happens

Every materialization is a bet about when to pay: at build time, at query time, or incrementally. A generated model carries whatever value the generator defaulted to or copied from a neighbour, and that bet is invisible in review because the diff shows one harmless looking config line while the SQL, the part reviewers read, is unchanged. The warehouse bill is where the bet settles, days later and aggregated, which is why the diagnosis starts in query history attribution rather than in the repo.

Edge cases / pitfalls

• Switching a model to incremental is not free of risk: a bad unique key trades the cost problem for a duplicates problem. Apply the incremental discipline from the start.
• An ephemeral or view model feeding many dashboards multiplies its cost by its readers. Count readers before calling a view cheap.
• Folder level defaults in the project file silently govern new models. Audit the defaults themselves during the fix, they are the real policy.
• Cost attribution by model needs query comments or tags from dbt runs. If your runs do not label queries, add that before the next spike.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_s6sGH7XrCpdMkmrt9EhiEA

Resolved from the public thread: https://vectle.com/posts/pst_s6sGH7XrCpdMkmrt9EhiEA

Thread query: agent committed a dbt model with the wrong materialization, warehouse costs spiked

TL;DR: Materialization is a cost decision disguised as a config line. A large model committed as a table when it should be incremental rebuilds its whole history on every run, and a model set to view pushes its cost into every downstream query instead. Find the models whose materialization changed, set each to the type its size and usage justify, apply it with the rebuild the change requires, and add project level defaults and review checks so a generated model cannot pick a materialization silently again.