dbt Lineage That Goes Past the dbt Boundary
The dbt DAG stops at your models. The data does not. Datatrail picks up where dbt ends and follows the column into the raw sources and out to the BI dashboard.
Read-only connection. Datatrail never moves or mutates your data.
In short
dbt lineage is the dependency graph dbt builds across your models, but it stops at the edges of your dbt project. Datatrail connects to your warehouse read-only, reads your dbt models and exposures, and joins them to query-log lineage on both ends, so the map runs from the raw landing tables dbt does not model, through your transformations, and out to the BI dashboards and downstream tables dbt cannot see, all at the column level.
Why it fits
dbt users who need lineage beyond the project edges, into raw sources and BI dashboards.
Before and after dbt
Lineage covers the raw sources upstream of your models and the dashboards downstream of your exposures, not just the dbt DAG in between.
Models confirmed by logs
Datatrail reconciles your dbt models against actual query logs, so the lineage reflects what ran, even where ref and source are loose.
Exposures to dashboards
dbt exposures are extended into real BI lineage, so you see which dashboard breaks when a model changes.
What dbt gives you, and exactly where it stops
dbt builds a real dependency graph, and it is one of the best things about the tool. Every ref() and source() call is a declared edge, so dbt docs generate produces a DAG of your models that is accurate, versioned with your code, and free. If your whole world is dbt models, that DAG is genuinely useful and you should use it.
The graph has two hard edges, and incidents tend to live at both of them. The first is upstream: dbt knows a model reads from source('stripe', 'charges'), but it knows nothing about how that raw table got there. The Fivetran or Airbyte sync that lands it, the schema the vendor changed last night, the load job that half-failed, none of that is in the DAG. dbt starts at the source declaration, and most freshness and schema problems start one step before it.
The second edge is downstream: the DAG ends at your models. The Looker explore, the Tableau workbook, and the reverse-ETL sync that pushes a model back into Salesforce are where a broken column is actually noticed, and dbt cannot see any of them unless you hand-maintain an exposures block, which almost nobody keeps current. So the graph is precise in the middle and blind at exactly the two ends where breakage is discovered.
dbt DAG lineage vs column-level lineage
There is a second gap inside the dbt boundary, not just at its edges. The dbt DAG is model-level. It tells you fct_orders depends on stg_stripe_charges, which is a table-to-table edge. It does not tell you that fct_orders.revenue specifically comes from stg_stripe_charges.amount minus stg_refunds.amount.
That distinction is the difference between a graph you look at and a graph you can act on. When you are about to change one column, a model-level DAG flags every downstream model that references the table, so a one-field change looks like it touches dozens of models. Column-level lineage narrows it to the handful of fields that actually read the column. dbt Core does not do column-level lineage at all; it is available in dbt Cloud on paid tiers through dbt Explorer, and still only within the dbt project. Datatrail parses the SQL of your models and your warehouse query history into column-level edges across the whole path, dbt and non-dbt alike.
How Datatrail extends the dbt graph both ways
Datatrail does not replace dbt lineage, it completes it. It connects to your warehouse read-only, reads your dbt manifest and exposures, and reconciles them against the query history the warehouse already keeps. That reconciliation matters because ref and source can drift from what actually runs: a model that reads a table directly instead of through ref, or a macro that builds SQL dynamically, is invisible to the DAG but visible in the query log. Joining both gives you lineage that reflects what executed, not only what was declared.
On the ends, Datatrail fills the two gaps. Upstream, it traces the raw landing tables dbt does not model, so a schema change in a Fivetran-synced source surfaces as a schema change alert before it breaks a model. Downstream, it follows exposures into real BI lineage, so impact analysis can tell you which Looker dashboard goes blank when you rename a column. The result is one column-level graph from raw source to dashboard. If you want to see the dependency structure drawn out, the dbt dependency graph guide walks through it, and the wider field is in our comparison of data lineage tools.
Questions people ask
dbt lineage, answered
Does dbt have data lineage?
Yes, at the model level. Every ref and source call in your dbt project declares a dependency, and dbt docs generate assembles those into a browsable DAG of your models and sources that stays in sync with your code. Its limits are scope and resolution: it covers only what is inside your dbt project, it stops at the raw sources upstream and the BI dashboards downstream, and dbt Core resolves to the table, not the column.
Does dbt support column-level lineage?
dbt Core does not. The DAG built from ref and source is table-level. Column-level lineage is available in dbt Cloud on paid tiers through dbt Explorer, and it is scoped to models inside your dbt project. Columns in raw landing tables that were never modeled, or produced by queries running outside dbt, fall outside it. Datatrail parses SQL from the dbt manifest and the warehouse query log together, so column lineage covers both.
How do I see lineage beyond my dbt models?
The dbt DAG ends at your project boundary, so raw sources upstream and dashboards downstream are not in it. To see the full path you join the dbt graph to warehouse query history, which captures the load jobs feeding your sources, and to BI metadata, which captures the dashboards reading your models. Datatrail does this automatically from a read-only connect, extending the column-level graph from raw landing tables out to Looker, Tableau, and reverse-ETL syncs.
What is a dbt exposure and why does it matter for lineage?
A dbt exposure is a manually declared entry that tells dbt a downstream asset, like a dashboard or an ML model, depends on specific dbt models. It is how you make the BI layer show up in the DAG. The catch is that exposures are hand-maintained, so they are only as complete as your team keeps them, and most teams do not keep them current. Datatrail derives the downstream lineage from BI metadata directly, so it does not depend on exposures being up to date.
Can I use dbt lineage for impact analysis before a change?
Partly. The dbt DAG lets you see which models depend on a model, so you can gauge model-level impact within the project. What it misses is column-level precision, the raw sources upstream, and the dashboards downstream, which is usually where a change actually breaks something. Datatrail runs impact analysis on the full column-level graph, naming every dependent model, exposure, and dashboard, including the ones outside your dbt project, before you merge.
More use cases
Related features
Map your lineage, end to end
Connect your warehouse read-only and see your lineage map in minutes. Datatrail never moves or mutates your data.