Solutions
Identify which column changed and which dbt models are affected — automatically.
A schema drift cascade occurs when a column is renamed, dropped, or changed in a source database table, causing multiple downstream dbt models to fail simultaneously with column-not-found errors. Because dbt models often chain together — staging → intermediate → mart — a single source column change can trigger 5, 10, or 20 model failures in a single run.
When 10 models fail at once, the dbt run log shows 10 separate error messages — all pointing to SQL compilation failures. To find the root cause, an engineer must trace which column is missing, find where it's defined in the source, determine when it changed, and map all the downstream models that reference it. Without tooling, this process requires running dbt ls, reading manifest.json, querying the warehouse information schema, and manually checking Git history — a 30–90 minute investigation.
Ordo monitors schema changes in your warehouse from the last 24 hours. When multiple models fail simultaneously with column-not-found errors, Ordo correlates the failed column references against recent schema changes to identify the renamed or dropped column. It then maps the full blast radius — all affected models — and posts the diagnosis to Slack:
Schema drift cascade detected (91% confidence)
Change: column `user_email` renamed to `email` in raw.users
Changed at: 14:22 UTC (detected in warehouse information_schema)
Affected models (3 of 52 failed):
- stg_users (direct source reference)
- dim_users (references stg_users)
- fct_signups (references dim_users)
Fix: Update source ref in stg_users.sql or use column alias in source definition
Ordo uses dbt's manifest.json to understand your project's full dependency graph. When a schema change hits, it traces exactly which models reference the changed column — directly or transitively — giving you the complete blast radius before you start making fixes.