Data lineage is the map of how each field moves from where it was captured, through every transformation, to the dashboards, models, and exports that consume it. This page goes deep on lineage as its own discipline. The data governance pillar only summarizes it in a section. The short version: table-level lineage tells you which tables connect, column-level lineage tells you what actually breaks when you change something and where a person's data ended up.
Lineage is a directed graph. The nodes are your data objects, tables, views, columns, dashboards, model features, exported files. The edges are the transformations that carry data from one to the next: a join, a dbt model, an ETL step, a CASE expression, a BI calculated field. Follow the edges downstream and you see everywhere a value travels. Follow them upstream and you see where a number came from.
That map is the difference between changing a pipeline with confidence and changing it by prayer. Without lineage, every schema change and every audit request turns into archaeology: opening query after query to reconstruct a path that the system already knows but never wrote down. Lineage writes it down, and keeps it honest, by reading the code that moves your data rather than a diagram someone drew once.
Table-level lineage tells you orders feeds daily_revenue feeds the Finance
dashboard. That is useful for a first orientation and almost useless for a real decision, because a table has
dozens of columns and a change to one of them should not implicate all of them.
Column-level lineage tells you that orders.amount_cents, divided by 100 in a specific model,
becomes daily_revenue.revenue_usd, which feeds the Net Revenue tile. Now the blast
radius is exact. When you touch one column you see the handful of downstream fields that depend on it, not the
whole table it happens to live in. This precision is the entire reason lineage earns its keep. It is what makes
impact analysis trustworthy and what makes a privacy answer defensible instead of approximate.
Impact analysis is lineage read in the downstream direction. Before you rename a column, change a type, drop a field, or quietly change a definition from gross to net, you ask the graph: what depends on this. The answer is the list of models, dashboards, and exports that will move or break. Read the graph upstream instead and you answer the other half of the question, where did this number come from, which is what you need when a figure looks wrong and you have to trace it back to source.
The leverage is running impact analysis on the pull request, while the change is still cheap to adjust, so the owners of the fields at risk are looped in before anything breaks.
When a person exercises a right over their data, you have to know every place that data went, not just where it was first stored. Under GDPR Article 15 (right of access) you must be able to say what you hold and where. Under Article 17 (right to erasure) you have to delete it everywhere it propagated, including derived tables, aggregates, and exports that copied it downstream. Article 30 (records of processing activities) expects a truthful account of your data flows, and lineage is direct evidence for that account. CCPA access and deletion rights create the same practical need for US-facing data.
Column-level lineage is what turns a complete deletion into a provable one. If an email address was copied from a signup table into a marketing export and a model feature, lineage shows all three, so the deletion is complete and you can produce the map that proves it. This is a readiness and evidence posture, not a certification. Lineage gives you the artifact a reviewer or a regulator can actually inspect.
Redact PII across the fields lineage tracesHand-drawn lineage diagrams rot the moment a query changes, because nothing keeps the picture tied to the code. Real lineage is parsed from the artifacts that already move your data: SQL query logs, dbt manifests, orchestration and ETL definitions, and BI tool metadata. You parse the SQL into its syntax tree, resolve each column reference through joins, CTEs, and subqueries back to its sources, and assemble the graph automatically.
Because it is generated from the real code, it stays current when you regenerate it on every deploy or rebuild it
from recent query history. The hard parts are worth naming honestly: SELECT * hides which columns
actually flow, dynamic SQL and stored procedures resist static parsing, and cross-system hops (warehouse to
reverse-ETL to a SaaS tool) break the chain unless each hop is captured. A capture approach that ignores these
silently reports less blast radius than really exists, which is worse than reporting none.
Share of columns and tables with captured lineage, not just the flagship models.
How current the graph is against the latest deploy. Stale lineage is confidently wrong lineage.
How fast you can answer "what breaks" for a proposed change.
Share of access and deletion requests you can resolve from lineage instead of manual hunting. Also watch orphaned and unresolved columns.
| Dimension | Table-level lineage | Column-level lineage |
|---|---|---|
| Granularity | Which tables feed which tables and reports | Which specific column feeds which downstream column, through which expression |
| Answers "what breaks" | Roughly. Flags the whole table as affected, including columns that are not | Precisely. Names the exact downstream fields that depend on the one you are changing |
| Privacy request use | Points to tables that might hold a person's data. Still needs manual confirmation per field | Traces a specific field to every downstream copy, so access and deletion can be proven |
| Effort to maintain | Lower. Fewer edges to parse and keep current | Higher to build, but automated by parsing SQL rather than drawn by hand |
| Failure mode | Over-broad blast radius. Teams learn to ignore it because it cries wolf | Under-reported flow if SELECT *, dynamic SQL, or cross-system hops are not captured |
revenue
column from gross to net inside one warehouse model. Table-level lineage says the finance table is involved and
stops there. Column-level lineage shows that this exact column feeds a board-level "Net Revenue" tile and two
forecasting features, so the change is reviewed with those owners before it ships instead of surfacing as a number
that silently shifted.Once lineage finds the copies, redact the personal data in them.
Try the redaction gateway