Analytics Engineering With Lineage Your Whole Team Can Read

Why the dbt DAG is not the whole lineage graph

Every analytics engineer already has a lineage graph, and it is one of the best things about dbt. dbt docs renders the DAG, dbt run -s model+ selects downstream, and within the project the dependency picture is exact because it is derived from ref() rather than guessed.

The limitation is the project boundary, and it cuts at both ends. Upstream, dbt knows a source exists because you declared it in a YAML file, but it knows nothing about how that source got populated, whether an ingestion tool or a stored procedure or somebody's scheduled query wrote it. Downstream, dbt stops at the model. Unless every dashboard is declared as an exposure and kept current by hand, the DAG cannot tell you which report breaks when a model changes.

That is the gap that produces the familiar conversation: a model is refactored, tests pass, dbt is happy, and two days later somebody in finance says a number looks wrong. The graph was right about everything it could see. Column-level detail matters here too, because a model-level DAG says model B depends on model A, while the actual question is usually whether it depends on the specific column you are about to change.

Tracing a number back to its source without reading SQL

The recurring request analytics engineers get is not a bug report. It is "where does this number come from?", asked by somebody who needs an answer before a meeting.

Answered by hand, it means opening the dashboard, finding the query, reading the model, following each ref() back a layer, and repeating until you reach raw. Twenty minutes if the project is clean, an afternoon if there is a view in the warehouse nobody put in dbt. Answered from a lineage graph built out of query history, it is a click, because the path already exists.

The second-order benefit is bigger than the time saved. When stakeholders can follow the path themselves, they stop routing every definitional question through the analytics team, and the conversation moves from "is this number right" to "is this the right definition". That is a much better use of an analytics engineer.

Reviewing a model change with the blast radius attached

The most useful moment for lineage in analytics engineering is the pull request. Renaming a column, changing a join grain, deprecating a staging model: each is safe inside the project and each can break something outside it.

Datatrail reads your dbt models and exposures and confirms them against the queries the warehouse actually ran, then computes downstream impact at column level: every model, exposure and dashboard that reads the field you are changing, by name, before the merge. Ad hoc consumers show up too, which matters because the dashboards that break loudest are usually the ones nobody remembered to declare as exposures.

If you are mapping out how the pieces fit, our guides to visualizing dbt lineage and the dbt dependency graph cover the dbt-native side, and data quality dimensions and metrics covers how to score the models once they are mapped. The same graph is what pages the data engineer who owns the pipeline when a source stops loading.