Skip to main content
Asset lineage answers “what feeds this model?”. Column-level lineage answers the sharper question: where does this one value come from, and what happens to it along the way? Use it before you change a column, when you are chasing a number that looks wrong, or when you need to know which downstream fields a rename would break.

Open it

Open any dbt™ model, source, seed, or snapshot in the catalog, go to the Columns tab, and click a column. A drawer opens from the bottom of the screen with the lineage graph for that column.
Column-level lineage is built for dbt™ assets from your compiled SQL. It appears once a dbt docs generate has run for the model, the same production run that populates the rest of the catalog. Assets from BI and ingestion tools connect at the table level, in the graph view.

Read the graph

The graph flows left to right: upstream sources on the left, downstream consumers on the right.
  • Each card is a model or source, titled with its name and package, and the columns involved in this lineage are listed as rows inside it.
  • The column you opened is highlighted, and every card on its value path stays bright. Cards that are only in the graph for context are dimmed.
  • Edges join column to column across cards. An edge that lands on a card’s header rather than on a row means the column affects that whole dataset rather than one of its columns.

What the edges mean

The legend in the corner of the canvas names the three kinds of edge. Hover any edge to see its exact label.

Parse status

Each card carries the parse status of its model, because column lineage is only as good as the SQL Paradime could read:
  • Parsed: the model’s compiled SQL resolved completely.
  • Partial: some columns could not be resolved, typically a SELECT * with no column schema available. The edges that did resolve are still shown.
  • Failed: the model could not be parsed. It stays in the graph with table-level edges instead of disappearing.
Compiled SQL is parsed with your warehouse’s own dialect, so BigQuery, Snowflake, and Databricks syntax (backtick identifiers, EXCEPT, STRUCT, UNNEST, and so on) resolves correctly. Results are cached per model, so a rebuild only re-parses what changed.

Control what’s shown

Depth

Two fields in the toolbar set how far the graph reaches upstream (←) and downstream (→), independently. Enter a number of hops, or + for everything, then press Enter or click the apply button. Both directions apply together, and nothing refetches until you apply, so a half-typed number never redraws the graph. Tracing a reporting column back to its sources wants deep upstream; assessing the blast radius of a change wants deep downstream.
When the graph hits your depth limit, the header shows Truncated, increase depth to see more, and a + button appears just outside the cards at the edge of the graph. Click it to pull in one more level in that direction without retyping the depth.

Lenses

The Lenses menu filters the graph on what each edge actually is. Toggle several at once:
  • Hide indirect edges: strip the graph down to pure value flow, dropping joins, filters, and grouping.
  • Masked columns only: keep only edges where the value passes through a masking transformation, for tracing sensitive fields.
  • Hide low-confidence edges: drop the edges Paradime was least sure about, which mostly come from partially parsed models.

Canvas

Zoom in and out, or fit view to bring the whole graph back into frame. The drawer opens at a comfortable height and can be expanded to nearly full screen for a deep graph.

Move around

  • Click any column on any card to refocus the graph on that column, in place, without leaving the drawer.
  • Click a card’s model name to open that model’s catalog page.

When the graph is empty

A column with no lineage shows No column lineage available. The usual reasons are that the model has not been through a dbt docs generate yet, or that its SQL could not be parsed, in which case the message names what got in the way.
DinoAI can trace the same lineage in chat and over MCP, which is useful for impact analysis across many columns at once. See the Column Level Lineage tool. To see column impact on every pull request instead, set up lineage diff.