dbt Column Level Lineage: dbt Cloud, dbt Core v2, Fusion and the Alternatives Compared
dbt does have column-level lineage, but which plan you are on, which build you installed and which flag you compiled with decide whether you can see it. Below is where it is available, what dbt itself documents it cannot trace, what each route costs, and how to get column lineage across the whole warehouse when the dbt graph is only part of it.
Read-only connection. DataTrail never moves or mutates your data.
dbt column-level lineage is available in three places and priced three ways: in dbt Catalog it requires an Enterprise or Enterprise+ plan, which dbt Labs quotes rather than publishes; locally it is free in dbt v2 (the Fusion engine) once you run dbt login and set static_analysis to strict; and it is not in the Apache 2.0 dbt-oss runtime at all. dbt's own documentation says the lineage covers select statements only, ignores joins and filters, cannot parse Python models and stops at the edge of the dbt project. Starter, the only published dbt price at $100 per user per month, does not include it.
dbt column level lineage tools, compared on plan, scope and price
Every route we could verify against a primary source on 22 September 2026. "Scope" is the part most comparisons skip: five of the eight only see dbt models, which is usually not where the column that broke the dashboard came from.
| Option | Where you see it | Scope | Plan and price | Source |
|---|---|---|---|---|
| dbt Catalog (dbt platform) | Hosted, shared UI for the whole team | dbt models, sources, snapshots | Enterprise or Enterprise+ plan, quoted | docs.getdbt.com, pricing page |
| dbt v2 locally (VS Code, Docs v2, CLI) | Your machine, per developer | dbt models, sources, snapshots | Free, needs dbt login and strict static analysis | docs.getdbt.com |
| dbt OSS (pip install dbt-oss, Apache 2.0) | Nowhere, feature is Fusion-only | None | Free | dbt Labs v2 roadmap note |
| Power User for dbt (Altimate) | VS Code panel | dbt models | Extension free, column lineage runs through Altimate's service | docs.myaltimate.com |
| dbt-column-lineage-extractor | JSON files from the CLI | dbt models | Free, beta, last release 28 Mar 2025 | PyPI |
| SQLMesh (dbt project adapter) | SQLMesh UI and CLI | Models SQLMesh can parse | Free, Apache 2.0, 0.236.2 on 8 Sep 2026 | PyPI |
| DataHub Core (dbt source) | DataHub catalog UI | dbt nodes plus the warehouse tables they map to | Free, Apache 2.0, you run Kafka and the indexes | docs.datahub.com |
| DataTrail | Hosted, read-only warehouse connection | dbt graph plus every query in warehouse history, upstream to raw sources and downstream to dashboards | $99 to $799 a month, flat | datatrail.ai/pricing |
dbt Labs' June 2026 v2 roadmap: column-level lineage, SQL comprehension and linting are "available in Fusion only" and unlocked by dbt login. The Apache 2.0 code contains thin clients for them, not the feature.
A developer gets column lineage free in VS Code. The shared, hosted version in dbt Catalog is an Enterprise feature, and the pricing page lists Starter's Catalog access as "Lineage", without the word column.
Every dbt-native route starts at your first source() and ends at your last model. The raw load upstream, the analyst's ad hoc query and the dashboard downstream are outside it. Only the last two rows read the warehouse itself.
What dbt documents its column level lineage cannot trace
These are from the caveats section of dbt's column-level lineage page, last updated 16 September 2026, quoted rather than paraphrased. The third column is what each one means when you use the lineage for impact analysis.
| Limit | dbt's wording | What it means for a change review |
|---|---|---|
| Only select statements | Column-level lineage reflects the lineage from select statements in your models' SQL code. It doesn't reflect other usage like joins and filters. | A column that only drives a join key or a where clause shows no dependency, so impact analysis on it comes back empty. |
| Python models break the chain | Due to the nature of Python models, it's not possible to parse and determine the lineage. | Every column downstream of a Python model loses its upstream trail at that point. |
| Complex SQL fails to parse | Error occurs when the SQL is ambiguous or too complex for parsing. An example of ambiguous parsing scenarios are complex lateral joins. | JSON unpacking, lateral joins and some dialect-specific functions produce a parsing error instead of lineage. |
| Hardcoded names are invisible | An example of this would be if a dbt best practice is not being followed, like using hardcoded table names instead of ref statements. | Any model that reads a table by name rather than through ref() or source() has no lineage into it. |
| Strict mode is a migration | Column-level lineage needs static_analysis: strict, and strict mode means resolving every parse error, unsupported type and unsupported function in the project first. | Projects using STRUCT, ARRAY, GEOGRAPHY or functions dbt v2 does not support yet cannot turn it on until those models are rewritten. |
The joins-and-filters caveat is the one that catches teams. A column such as customer_id is rarely selected into a downstream model unchanged; it is the key that a join runs on. dbt's lineage records the columns a select projects, so a change to the key column's type or semantics shows an empty downstream list, and the review that relied on it passes a change that breaks every join. Warehouse-side lineage built from the queries that actually ran sees the join because it parses the whole statement, not the projection.
The strict-mode requirement is the other one worth reading twice. dbt v2 defaults to static_analysis: baseline, and column-level lineage is a strict-mode feature. Getting to strict means every model parses under dbt v2's SQL comprehension, which its own migration notes say excludes projects using STRUCT, ARRAY or GEOGRAPHY types and functions it has not covered yet. For a mature BigQuery or Snowflake project that is a rewrite before the first lineage graph appears.
dbt Cloud vs dbt Core vs dbt Fusion: which one actually has column level lineage
Since June 2026 the names overlap, so it helps to be exact about which artifact you are running. There are three, and only two compute column lineage.
The hosted product. Column-level lineage is a dbt Catalog feature listed under Enterprise and Enterprise+ on the pricing page. Developer (free, one seat) and Starter ($100 per user per month, five seats) do not get it. Enterprise is billed annually on seats plus successful models built, and quoted.
What pip install dbt gives you now: the Rust engine formerly called Fusion, free to use, with the richer features (column lineage, linting, SQL comprehension) unlocked by dbt login with a free platform account. Column lineage appears in the VS Code extension, dbt Docs v2 and dbt show --info column_lineage.
pip install dbt-oss. dbt Labs describes it as the option "for organizations that require the Apache 2.0 codebase specifically". It runs your project at full parity with v1 but does not compute column-level lineage; the roadmap note is explicit that this is a Fusion-only feature.
This matters for two kinds of teams. A team with a license policy that only allows OSI-approved software cannot use the free column lineage, because it lives in the login-gated distribution, not in the Apache 2.0 one. And a team that wants column lineage shared across everyone, not per laptop, is being pointed at Enterprise, whose price dbt Labs does not publish. The only dbt number on the pricing page is $100 per user per month for Starter, and Starter's Catalog row says "Lineage", not "Column-level lineage".
How to get dbt column level lineage locally, for free
If one developer needs to check a column before a pull request, this is enough and it costs nothing. Install dbt v2 normally, sign in with a free dbt platform account, set strict static analysis, and compile with the information schema switched on:
dbt login dbt compile --generate-info-schema \ --static-analysis strict dbt show --info column_lineage
The lineage is written as Parquet under target/info_schema/ and can be read with pandas or Polars. To see it in the browser, run dbt docs generate --no-compile after the strict compile; dbt notes that docs generate has no static-analysis flag of its own, so the strict compile has to come first or the site ships without column lineage. In the VS Code extension it is a right-click on a model, then dbt: View Lineage, then Show column lineage.
What you get is a per-developer view of the dbt project. What you do not get is a place the analytics lead, the on-call engineer and the BI team all look at, lineage that starts before your first source, or any alerting when a column upstream changes. Those are the reasons teams end up pricing Enterprise, and the reason a warehouse-side tool is the cheaper answer for most of them.
dbt column level lineage cost for a team, at published prices
Only two of the numbers below are published by dbt Labs. Where a price is quoted we say so rather than repeat third-party estimates.
| Team of 10 developers wants | Route | Published cost | Column lineage included |
|---|---|---|---|
| Each person checks their own changes | dbt v2 locally, strict mode | $0 | Yes, per laptop |
| A shared hosted project with model lineage | dbt Starter | $100 per user per month, so $12,000 a year for 10 | No, model-level only |
| A shared hosted project with column lineage | dbt Enterprise | Not published, billed annually on seats and models built | Yes, dbt models only |
| Column lineage across dbt, raw sources, ad hoc SQL and dashboards, with alerts | DataTrail | $99, $299 or $799 a month flat, no seat count | Yes, warehouse-wide |
The pricing page lists Starter at five developer seats and 15,000 successful models built a month. A ten-person team is already past it, which is why "we just want column lineage" turns into an Enterprise conversation.
Enterprise is billed on seats plus successful models built, with 100,000 a month included. A lineage tool that reads the warehouse has no such meter; the price is the same whether you build 500 models a day or 50,000.
Column level lineage past the dbt boundary
Every dbt-native option on this page shares one property: the graph starts at source() and ends at your last model or exposure. That is correct behavior for a transformation tool. It is also why the column that actually broke the dashboard is so often outside the picture. The Fivetran connector that renamed a field lands upstream of your first source. The finance analyst's scheduled query that reads fct_orders straight into a spreadsheet is downstream of your last model and invisible to ref(). The Airflow task that writes a table into the same schema never touches the dbt manifest.
DataTrail builds the graph from the other side. It connects to Snowflake, Databricks, BigQuery, Redshift or Postgres with a read-only role, parses every statement in the warehouse query history alongside your dbt manifest, and produces one column-level lineage graph that covers the raw load, the dbt models, the ad hoc SQL and the BI layer. Joins and filters are parsed because the whole statement is, not just the projection. Python models are not a gap, because the tables they wrote and the queries that read them are in the log regardless of what produced them.
On that graph, impact analysis lists every downstream model, exposure and dashboard before a column change merges, schema change alerts fire when an upstream column is renamed or dropped, and freshness monitoring runs on the same nodes. Plans are $99, $299 or $799 a month on the pricing page, with no seat count and no models-built meter. There is no strict-mode migration: the project keeps running on whatever dbt build you use today.
It is not a replacement for dbt Catalog if what you want is dbt's documentation site with column cards for the whole company; for that, Enterprise is the product. The broader picture of how dbt's graph relates to warehouse lineage is on dbt data lineage past the dbt boundary, and the practical side of drawing it is in how to visualize dbt lineage and the dbt dependency graph.
dbt column level lineage questions teams ask before they pay for it
Does dbt have column level lineage?
Yes, in two places. In the hosted dbt platform, column-level lineage lives in dbt Catalog and requires an Enterprise or Enterprise+ plan. Locally, dbt v2 (the free default install, after dbt login) computes column-level lineage during compile when static_analysis is set to strict, and shows it in the VS Code extension, dbt Docs v2 and the dbt show command. The Apache 2.0 dbt-oss runtime does not include it.
Is dbt column level lineage available on dbt Core?
Not in the open-source runtime. dbt Labs' own v2 roadmap says column-level lineage, SQL comprehension and linting are "available in Fusion only" and unlocked by dbt login. The free dbt v2 distribution you get from a normal install has it locally; the Apache 2.0 dbt-oss package you install with pip install dbt-oss does not. For a self-hosted, license-clean option you need a separate tool such as SQLMesh, DataHub Core or a hosted lineage service.
How do I get column level lineage in dbt Cloud?
Open a model, source or snapshot in dbt Catalog, go to the Columns tab and expand the column card. There is no setup beyond having at least one job in a production or staging environment run dbt docs generate. The catch is the plan: dbt's pricing page lists "Column-level lineage in dbt Catalog" under Enterprise and Enterprise+ only. Starter, at $100 per user per month, gets model-level lineage in Catalog but not column-level.
Does dbt Fusion have column level lineage?
Yes. The Fusion engine, now shipped as dbt v2, does a static analysis pass over every rendered query in the project and derives column-level lineage from it, which the Python-based dbt v1 could never do. It needs static_analysis: strict, so every model has to parse cleanly and use supported types and functions. It is free to use locally after dbt login with a free platform account.
Is there an open source dbt column level lineage tool?
Three that are genuinely open source: SQLMesh (Apache 2.0, 0.236.2 released 8 September 2026) reads dbt projects through its adapter and shows column-level lineage in its own UI; DataHub Core ingests dbt artifacts and parses the compiled SQL for column lineage, on by default via include_column_lineage; and dbt-column-lineage-extractor on PyPI, a Canva project that is still a beta whose last release was 28 March 2025. The dbt-oss runtime itself does not compute column lineage.
How much does dbt column level lineage cost?
Free for one developer on their own laptop through dbt v2 in strict mode. For a team view in dbt Catalog it costs an Enterprise contract, which dbt Labs quotes rather than publishes; the only published dbt price is Starter at $100 per user per month, and Starter does not include column-level lineage. A hosted lineage tool that reads the warehouse instead of the project costs $99 to $799 a month flat on DataTrail, with no per-seat meter.
Can DataHub show column level lineage for dbt?
Yes. DataHub's dbt ingestion source extracts column-level lineage from the dbt node definitions and parsed SQL, enabled by default with the include_column_lineage setting, and links dbt models to the underlying warehouse tables. It is free in DataHub Core under Apache 2.0, and the cost is running DataHub itself: Kafka, a relational database, a search index and a graph index that your team keeps healthy.
Does Dagster show column level lineage for dbt models?
dagster-dbt can emit column schema and column lineage as materialization metadata when you chain fetch_column_metadata() onto the dbt CLI stream, so each asset carries its column-level dependencies. It covers the dbt models Dagster runs, not queries that happen outside the orchestrator, and the lineage lives in Dagster's asset catalog rather than a warehouse-wide graph.
What does dbt column level lineage not cover?
Anything that is not a dbt model. Raw tables loaded by Fivetran or a custom pipeline upstream of your first source, ad hoc SQL that analysts run against the marts, stored procedures, Airflow tasks that write straight to the warehouse and the dashboards that read from your exposures are all outside the graph. dbt also documents that joins and filters are not tracked and Python models cannot be parsed.
What is the best column level lineage tool for a dbt team without Enterprise?
If the need is a developer checking a change before a pull request, dbt v2 in strict mode is free and good. If the need is the whole team seeing where a column goes, including dashboards and non-dbt SQL, a warehouse-side tool fits better: DataTrail reads query history and the dbt manifest from a read-only role and builds one column-level graph across all of it, on a flat plan, with impact analysis, freshness and schema alerts on the same graph.
Where these facts came from
Everything about dbt on this page was read from dbt Labs' own material on 22 September 2026: the column-level lineage page in the dbt docs (last updated 16 September 2026), the pricing page, the install pages for dbt v2 and for the Apache 2.0 dbt-oss runtime, the VS Code extension pages, the static analysis guide, and the June 2026 "announcing v2" roadmap note in the dbt-labs/dbt repository, which is where the "available in Fusion only" wording comes from. Caveats are quoted, not summarized.
The SQLMesh and dbt-column-lineage-extractor versions, licenses and release dates come from the PyPI JSON API. The DataHub and Dagster capabilities come from their dbt integration documentation. Where dbt Labs quotes a price rather than publishing one, we say "quoted" and do not repeat third-party estimates, because none of them cite a source.
What this page does not claim: it does not say how much dbt Enterprise costs, because that figure is not public, and it does not rate the accuracy of any tool's parser, including ours. Every SQL-parsing lineage tool has a list of statements it cannot handle. dbt publishes its list, which is to its credit, and we quoted it.
Related pages
Why the dbt DAG is the middle of the graph, and what sits on either side of it.
How DataTrail parses query history into a column graph, and what it does with joins.
dbt docs, the DAG and the tools that draw it, compared.
The open source catalog that ingests dbt column lineage, and what running it costs.
dbt-native observability, and where it stops at the same boundary.
The whole field compared on lineage depth, deployment and price.
See column level lineage for your whole warehouse, not just the dbt project
Connect with a read-only role and get one column graph across raw sources, dbt models, ad hoc SQL and dashboards, with impact analysis and schema alerts on it. No Enterprise contract, no strict-mode migration, a flat monthly plan.