Looker Data Lineage: The LookML Graph, Knowledge Catalog, and Its Limits

Looker has data lineage, but not the column-level kind most teams are looking for. Inside the app, the derived table dependency graph shows how persistent derived tables (PDTs) build on each other, and nothing more. Separately, Looker (Google Cloud core) can publish its LookML objects to Google Cloud's Knowledge Catalog, which draws lineage from BigQuery through views, Explores, and dashboards in the Google Cloud console. Google's own documentation says that view is object-level only: column-level lineage is not supported, it covers BigQuery sources only, it is in preview, and it syncs on a 4 to 8 hour delay. To trace a LookML measure down to the exact warehouse column behind it, across any warehouse, you trace it from the warehouse side.

The two kinds of lineage Looker gives you

People say "Looker lineage" and mean two different features. It helps to separate them, because they answer different questions and neither is the field-level trace you probably want.

The first lives inside Looker: the derived table dependency graph. When you build persistent derived tables, Looker has to know what order to rebuild them in, so it tracks how each derived table depends on the others. Open a PDT in the admin panel and the "Show Dependency Graph" view draws that chain, with nodes color-coded by build status: green for built, yellow for building, red for failed. It is handy for debugging a slow or broken PDT cascade. It is not source lineage. It shows relationships between derived tables and does not reach back to the warehouse tables underneath, let alone their columns.

The second is the Knowledge Catalog integration. Knowledge Catalog is what Google renamed Dataplex Universal Catalog to in 2026. If you run Looker (Google Cloud core), you can publish LookML metadata, projects, models, Explores, views, dashboards, and Looks, into Knowledge Catalog and view a lineage diagram in the Google Cloud console showing BigQuery tables flowing into those Looker objects. That is the closest Looker gets to end-to-end lineage, and it is a real feature.

Why Looker lineage stops short of the column

Three limits matter if you are trying to plan a change without breaking a dashboard.

• It is object-level, not column-level. Google's documentation is explicit that for the Looker to Knowledge Catalog integration, lineage is provided at the object level, table, view, Explore, dashboard, and column-level lineage is not supported. So it can tell you an Explore depends on a BigQuery table, but not that a specific measure is driven by orders.net_revenue, which is the resolution you need before you rename that column.
• It is BigQuery-only and in preview. The integration supports only BigQuery data sources and is a preview feature. If your Looker instance reads Snowflake, Redshift, or Databricks, the native Knowledge Catalog lineage does not cover the warehouse side at all. Sync is not real-time either; the documented delay is roughly 4 to 8 hours.
• Complex SQL and the modeling boundary trip it up. Google notes that LookML defined with complex custom SQL may not be fully parsed, which can leave disconnected nodes. And native lineage does not reach upstream into dbt. It starts from BigQuery tables as Knowledge Catalog sees them, so the dbt models, staging layers, and raw loads that produced those tables sit outside the picture.

What each Looker lineage feature can and cannot answer

How to get column-level lineage behind Looker

The practical answer is to trace lineage from the warehouse rather than from Looker. The data Looker charts was built by SQL that already ran in your warehouse, and the warehouse keeps a record of that SQL in its query history. Parse that history and you can reconstruct column-level lineage for everything that produced the tables your LookML views read, including the SQL Looker itself generates when it runs an Explore.

That is the approach Datatrail takes. It connects to Snowflake, BigQuery, Redshift, Databricks, or Postgres with a read-only role, parses the query logs into a persistent column-level graph, and follows each field from its raw source table through the dbt models that transform it out to the table a LookML view loads. Because the source is the SQL that actually executed, the graph does not care whether a dbt model, an analyst's ad hoc query, or a load job built the table. The warehouse-native Looker lineage use case walks through what that looks like end to end.

Getting clean lineage also depends on getting clean data into the warehouse in the first place. If a chunk of your source data still arrives through hand-maintained scripts, moving those loads onto a managed data integration platform that connects your apps, APIs, and databases gives the lineage graph a stable starting point instead of a black box.

Impact analysis: the part Looker can't do

The reason column-level lineage matters is not documentation for its own sake. It is change safety. Before you rename or drop a warehouse column that a LookML view reads, you want a list of every downstream model and every Look or dashboard that depends on it. Looker's object-level view cannot produce that list at the column level, and its impact analysis is scoped to what it can see inside Looker.

Warehouse-native lineage closes that gap. Datatrail computes downstream impact from the column-level graph, so a refactor names its blast radius before you merge, and schema change alerts catch the upstream renames and drops that would otherwise arrive in Looker unannounced. If you also run Power BI or Tableau, the same graph covers those tools too, and the wider field is in our comparison of data lineage tools.

The short version

Looker's native lineage is genuinely useful within its limits: the PDT dependency graph for rebuild debugging, and the Knowledge Catalog integration for an object-level, BigQuery-only picture of data flowing into your LookML objects. Neither traces a LookML field to the warehouse column behind it. For column-level lineage and before-you-ship impact analysis across any warehouse, trace it from the warehouse with a read-only tool that parses query history, and keep Looker's native graphs for the jobs they do well.