Quick answer:
Data lineage is the traced path of your data: which sources feed which tables, which tables feed which models, and which models feed which dashboards. It’s the family tree of every number in the company, and the difference between “this figure looks wrong, give me 2 days” and “this figure looks wrong, the break is in the payments sync, here’s the exact join”.
What is data lineage?
Every dashboard number is the tip of a long chain: a production database, a sync into the warehouse, 4 layers of dbt models, a BI query, a chart. Lineage is that chain, made explicit and browsable as a graph.
It comes in 2 resolutions. Table-level lineage says “table A feeds model B”. Column-level lineage says “the revenue_usd column in the board dashboard comes from amount in the Stripe sync, times the FX rate from this table, minus refunds joined from that one”. Table-level is easy to produce and good for orientation; column-level is the one that answers real incident questions, and it’s much harder to compute because someone has to parse every piece of SQL in the estate.
That parsing is how modern lineage works, by the way. Nobody draws these graphs by hand anymore: tools read your dbt manifests, warehouse query logs, and BI metadata, and reconstruct the graph automatically.
What do teams use it for?
- Root cause, downstream to upstream. The dashboard broke; walk left until you find the failed sync or the schema change. This is the daily-driver use.
- Impact analysis, upstream to downstream. “If I rename this column, what breaks?” Walk right and get the list of every affected model, dashboard, and reverse ETL sync before you ship, instead of after the sales team notices.
- Compliance. Regulators and privacy laws ask where personal data flows. Lineage is the only honest answer that isn’t archaeology.
- Cleanup. The graph exposes dead ends: tables that feed nothing, expensive models with no consumers. Deleting with confidence needs lineage.
Where does lineage live in the stack?
Everywhere, which is its own problem. dbt generates lineage for the transform layer for free (its DAG docs are many teams’ first taste). Catalogs like Atlan and DataHub build cross-tool graphs. Observability platforms like Monte Carlo compute lineage so alerts can say what’s affected. Warehouses expose their own from query history.
The gaps are at the edges. Lineage inside the warehouse is a solved problem; lineage across boundaries (through a Python job, a spreadsheet export, an API call into a SaaS tool) still leaks. OpenLineage, an open standard for emitting lineage events from any tool, is the ongoing attempt to stitch those edges together, and support has been spreading through orchestrators and platforms for years.
What’s the catch?
Automated lineage is only as complete as the SQL it can see and parse. Query a table from a notebook, copy data with a shell script, or paste numbers into a deck, and the graph doesn’t know. There’s a decent rule hiding in that: the more of your platform runs through parseable, declared tools, the better your lineage, which is one more quiet argument for boring SQL over clever scripts.
The other catch is that lineage describes structure, and structure isn’t correctness. The graph shows the revenue chart is fed by the payments model; it can’t tell you the join in that model double-counts refunds. Lineage tells you where to look. You still have to look.
What are the benefits and drawbacks of lineage tooling?
Benefits of data lineage
Root cause in minutes, not days
Walking the graph upstream from a broken dashboard beats interviewing 3 teams about what changed. Incident time collapses to the walk’s length.
Changes ship with a blast-radius report
“What breaks if I rename this column?” gets an exact list before deploy. Refactoring a warehouse without lineage is demolition without blueprints.
Dead weight becomes visible
Tables feeding nothing, models nobody queries, pipelines running for ghosts: the graph exposes them, and deleting with confidence saves real compute money.
Audits stop being archaeology
Where personal data flows, which sources feed the regulatory report: answered from the graph, with screenshots, instead of from a week of interviews.
Drawbacks of data lineage
The graph only sees what it can parse
Notebooks, shell scripts, spreadsheet exports, and API calls punch holes in coverage. The map is honest about the roads and silent about the footpaths.
Structure isn’t correctness
Lineage shows which model feeds the chart, and says nothing about the double-counted refunds inside it. It narrows the search; it doesn’t do the finding.
Cross-tool graphs take integration work
dbt gives its layer free, but stitching warehouse, BI, and ingestion into one graph means connectors, permissions, and upkeep. The full picture is a project, and standalone lineage rarely justifies one.
Big graphs need curation to stay usable
A 10,000-node hairball answers nothing. Good tools filter to the relevant neighborhood; without that, lineage becomes a screenshot for slide decks.
Do you need dedicated tooling for it?
Start with what you already have: dbt docs give you the transform-layer graph, and your BI tool knows which dashboards read which tables. That combination covers most “what breaks if I change this?” questions at small scale.
Cross-tool, column-level lineage becomes worth paying for when incidents regularly cross boundaries and the estate is too big to hold in one head. In practice it usually arrives bundled inside a catalog or observability purchase rather than as its own line item, and that’s the right way to buy it.