dbt Impact Analysis: Catching Downstream Breaks Before You Merge

A dbt model change that looks safe in isolation often is not. Renaming a column, adjusting a join, or editing a test can silently break a dashboard, an exposure, or a downstream model that nobody reviewing the pull request even knew depended on it. dbt's own compiled manifest shows which models inside the project sit downstream of a change. It has no visibility into what happens once a mart leaves dbt's project boundary: a BI tool reading it directly, a reverse ETL sync, or an application built on top of the output. By the time the break surfaces, it is in production, not in the pull request, and the team is tracing a failure backward instead of catching it before it shipped.

Foundational applies source code analysis to trace the full impact of a dbt model change, inside the project and across every system downstream of it, before the change merges. This post covers what dbt's native lineage misses once a model changes, what complete impact analysis has to include to be useful, and how that analysis fits into the pull request workflow engineers already use rather than a separate review step added on top.

Why dbt's Native Lineage Stops at "Could Break"

dbt's manifest and generated DAG are accurate for what they cover: which models inside the project read from a changed model, and the order those models run in. That is enough to tell an engineer what could be affected. It is not enough to tell them what will actually break, because a downstream model's SQL might not reference the column that changed at all, or might reference it in a way that fails loudly, or might reference it in a way that fails silently and returns the wrong number for weeks before anyone notices.

None of this is a gap in dbt itself. A dbt project is designed to document dependencies within its own boundary, not everything that consumes its output once that output leaves the warehouse.

What Complete Impact Analysis Has to Trace Before a Merge

Full impact analysis for a dbt model change needs three things dbt's own DAG cannot provide on its own. First, the compiled SQL and Jinja of every downstream model, parsed directly, to know whether a model actually depends on the specific column or logic that changed, not just that it depends on the table in general. Second, visibility into what reads the mart outside the dbt project: a BI tool's saved definitions, a reverse ETL mapping pushing a field into a CRM, or a service querying the warehouse directly in application code. Third, the tests and exposures attached to the model, so a reviewer can see what monitoring already exists for the thing that is about to change.

Getting this from query logs alone has a ceiling. A query log shows what already ran, which means it can miss a consumer that queries infrequently, a job that runs on a schedule outside the log's window, or logic that lives inside a conditional branch that has not executed yet. Deterministic lineage, lineage derived by parsing the code itself rather than inferring it from runtime samples, does not have that gap. It reflects every dependency exactly as written in the code, including the ones that have not run recently enough to show up in a log.

Impact Analysis, Defined for a dbt Project

Impact analysis is the practice of identifying every downstream consumer, model, dashboard, service, or report, that a proposed code change could affect, before that change is merged or deployed. For a dbt project specifically, impact analysis has to extend past the dbt DAG to include anything built on top of a mart outside dbt's own boundary, since a change that looks safe inside the DAG can still break a consumer dbt was never able to see in the first place.

What Good Looks Like

Foundational analyzes a dbt project's compiled SQL and Jinja alongside the application code, BI definitions, and pipeline jobs that read from the resulting tables, and produces one deterministic lineage graph that spans both layers. When a pull request changes a model, that graph shows every downstream model, exposure, dashboard, and application that actually references the changed logic, not just what sits downstream in the DAG, directly in the pull request, before a reviewer approves it. That is proactive governance embedded in the workflow engineers already use, not a separate audit that runs after the change has already shipped.

The same graph that flags a breaking change in a pull request is also what gives an AI agent working against the warehouse accurate context about what a model actually contains, rather than reasoning from a schema definition that is already out of date. Lightricks saw this directly after adopting code-level impact analysis across its dbt and analytics codebase: roughly 100 issues caught and prevented monthly across more than 150 pull requests, according to Eyal El-Bahar, VP of BI and Analytics.

Foundational's approach to catching breaking changes applies the same source code analysis across any pipeline, not only dbt; see how teams catch data pipeline breaking changes before they ship. For the lineage and deployment side of a dbt project specifically, see how dbt deployment, lineage, and code checks fit together.

Frequently Asked Questions

How is this different from dbt's own lineage graph?

dbt's generated DAG is accurate for dependencies inside the project: which models read from a changed model and the order they run in. It has no visibility into whether a downstream model's logic actually depends on what changed, or into dashboards, reverse ETL syncs, and application code that read the resulting tables from outside the project. Full impact analysis picks up exactly where that boundary stops.

Does this replace our dbt tests or CI checks?

No. dbt tests validate data at specific points after a model runs, and CI checks confirm the project still builds. Impact analysis happens earlier, at the pull request itself, and shows a reviewer what a proposed change will touch before it merges, across dbt models and everything downstream of them. The two are complementary: one tells a reviewer what a change might break before it ships, and the other confirms whether something actually broke once it ran.

What about a dashboard or application that queries the warehouse directly, outside dbt?

Foundational traces any code that touches the data, not only the dbt project itself. A BI tool's saved query, a reverse ETL mapping, or a service reading a mart directly all show up in the same lineage graph as the dbt models they depend on, so impact analysis covers the full consumer base a change could reach, rather than only the part dbt itself manages and documents.

Do we need to restructure our dbt project to get this?

No. Foundational parses the dbt project, its compiled SQL and Jinja, and the surrounding application and pipeline code exactly as they already exist today. There is no requirement to rename models, adopt a new macro convention, split a monolithic project, or change how the project is organized in any way before impact analysis applies to an existing codebase and the pull requests already running through it.

Next Step

If a dbt model change has ever broken something your team only discovered after it shipped, that is the gap complete impact analysis is built to close. Foundational is a data and AI governance platform built on source code analysis, so the graph covers every downstream model, dashboard, and application a change actually touches, not just what sits inside the dbt DAG. Request a demo to see Foundational trace the real impact of a dbt model change across your own stack.