Before You Rename That dbt Column, Check the Blast Radius
Renaming total_cents to gross_revenue_cents sounded like a one-line change. Blast radius analysis revealed it touched models, metrics, YAML docs, and dashboards.
OVERVIEW
Renaming a column in dbt sounds harmless. One field, one model, done. Until it isn't — and finance is asking why their dashboard broke.
This video shows Altimate Code running a full blast radius analysis before a single character is changed. The rename target: total_cents → gross_revenue_cents in staging_orders. The agent traces the impact through every downstream dbt model, semantic model, metric definition, YAML documentation file, and BI dashboard that references the column.
Once the blast radius is mapped, the rename is applied and every affected reference is updated in one pass. Targeted dbt builds confirm each fix, and a full project build validates the complete change. The lesson: a column rename touches far more than the model you're editing. The right order is always blast radius first, fix everything, then validate.
WHAT YOU'LL LEARN
- →How to run a column-level blast radius analysis before making a dbt change
- →How a single column rename propagates through models, metrics, YAML docs, and dashboards
- →How to apply a rename and update all downstream references in one automated pass
- →How to validate refactoring changes with targeted and full project dbt builds
KEY POINTS
- Traces column impact through dbt models, semantic models, metrics, YAML, and dashboards
- Identifies every reference to total_cents before touching a single file
- Applies the rename and updates all affected downstream references automatically
- Validates with targeted per-model builds before running the full project build
- Avoids the classic mistake: changing production SQL without knowing the downstream blast radius
