Looker Data Lineage, Down to the Warehouse Columns Behind LookML
Looker knows its own LookML graph, and Google Cloud can draw a picture of BigQuery flowing into your Explores. Neither one traces a Looker measure down to the exact warehouse column it derives from. Datatrail reads the warehouse read-only and maps that path at the column level, across any warehouse, not just BigQuery.
Read-only connection. Datatrail never moves or mutates your data.
In short
Looker's built-in data lineage comes in two forms, and both stop short of the warehouse column. Inside the Looker application, the derived-table dependency graph shows how persistent derived tables (PDTs) build on each other, but it does not trace back to source tables or columns. Separately, Looker (Google Cloud core) can publish its LookML objects to Google Cloud's Knowledge Catalog, which renders lineage from BigQuery through views, Explores, and dashboards in the Google Cloud console, but that view is object-level only, in preview, BigQuery-only, and syncs on a 4 to 8 hour delay. Google's own documentation states column-level lineage is not supported for the Looker objects. Datatrail connects to the warehouse read-only, parses query history into column-level lineage, and traces a field from the raw source table through dbt to the table a LookML view reads, so you can see which Look or dashboard breaks before you alter a column.
Why it fits
Looker teams who need column-level lineage into the warehouse tables and dbt models behind their LookML, beyond the object-level, BigQuery-only native view.
LookML graph, not column lineage
Looker's native dependency graph maps how persistent derived tables build on each other, and its Knowledge Catalog integration maps object-to-object flow. Neither resolves a LookML dimension or measure down to the warehouse column that feeds it. Datatrail fills that in from the warehouse side.
Any warehouse, not just BigQuery
The Looker to Knowledge Catalog lineage integration is BigQuery-only and still in preview. Datatrail builds column-level lineage from Snowflake, BigQuery, Redshift, Databricks, or Postgres query history, so a Looker instance on any of them gets the same graph.
Impact before you change a source
Before you rename or drop a column a LookML view reads, Datatrail lists every downstream model and, through your warehouse, the Looker content that depends on it, so a refactor does not silently break an Explore or a scheduled dashboard.
What lineage Looker gives you natively
Looker has two separate lineage features, and it helps to keep them apart because they answer different questions and neither is the column-level view most teams are looking for.
The first lives inside the Looker application: the derived table dependency graph. When you build persistent derived tables (PDTs), Looker has to know the order to rebuild them in, so it tracks how each derived table depends on others. Open a PDT in the admin panel and the "Show Dependency Graph" view draws that chain, color-coded by build status, green for built, yellow for building, red for failed. It is genuinely useful for debugging a slow or broken PDT cascade. What it is not is source lineage: it shows relationships between derived tables, and it does not trace back to the underlying warehouse tables, let alone their columns.
The second is the Knowledge Catalog integration (Knowledge Catalog is the service Google renamed from Dataplex Universal Catalog in 2026). If you run Looker (Google Cloud core), you can publish your 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. It is also, per Google's own docs, provided at the object level only.
Where Looker lineage stops
Three limits matter if you are trying to plan a change safely.
It is object-level, not column-level. Google's documentation is explicit: for the Looker to Knowledge Catalog integration, "lineage is provided at the object level (table, view, Explore, dashboard). 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 explicitly supports only BigQuery data sources, and it is a preview feature subject to change. 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 in the graph. And the 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. The break that reaches a Looker dashboard usually started several hops before Looker ever ran a query.
How Datatrail completes the picture from the warehouse
Datatrail approaches Looker lineage from the warehouse end. Instead of reading Looker's internal metadata, it connects to the warehouse that feeds Looker, Snowflake, BigQuery, Redshift, Databricks, or Postgres, with a read-only role, and parses the query history the warehouse already records into a persistent column-level lineage graph. Because the source is the SQL that actually ran, including the SQL Looker itself generates when it runs an Explore, the graph covers every table and column that produced the data your LookML views read, whether a dbt model built it, an analyst wrote it by hand, or a load job landed it.
That gives you the two things Looker's native lineage cannot. First, resolution: you can trace a LookML measure back through each dbt transformation to the exact raw column it derives from. Second, impact analysis before you ship: before you alter or drop a warehouse column, Datatrail names every downstream model, and through your warehouse the Looker content, that reads it, so you change it deliberately instead of hearing about it from a broken dashboard. Schema change alerts catch the upstream renames and drops that would otherwise arrive in Looker unannounced.
The two views complement each other. Keep Looker's PDT graph for rebuild debugging and the Knowledge Catalog view for the object-level BigQuery picture, and use Datatrail for the column-level path from any warehouse out to the LookML model. If you also run Power BI or Tableau, the same warehouse graph covers Power BI lineage and Tableau lineage in one place, and the wider field is in our comparison of data lineage tools.
Questions people ask
Looker lineage, answered
Does Looker have data lineage?
Yes, in two limited forms. Inside Looker, the derived table dependency graph shows how persistent derived tables build on one another. Separately, Looker (Google Cloud core) can publish its LookML objects to Google Cloud's Knowledge Catalog and render an object-level lineage diagram from BigQuery through Explores to dashboards in the Google Cloud console. Both are useful, but neither traces a LookML field to the warehouse column behind it.
Is Looker lineage column-level?
No. Google's documentation states plainly 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. The in-app derived table graph is coarser still, showing only relationships between derived tables. For column-level lineage behind Looker you need to trace it from the warehouse with a tool that resolves lineage to individual fields.
Does Looker lineage work with Snowflake or Redshift?
Not natively. The Looker to Knowledge Catalog lineage integration supports only BigQuery data sources and is a preview feature. If your Looker instance reads Snowflake, Redshift, Databricks, or Postgres, the native Knowledge Catalog lineage does not cover the warehouse side. A warehouse-native tool like Datatrail builds column-level lineage from any of those warehouses by parsing their query history.
What is a LookML derived table dependency graph?
It is Looker's in-app diagram of how persistent derived tables (PDTs) depend on each other, so Looker knows the order to rebuild them. Nodes are color-coded by build status and the graph shows cascading chains where one derived table is built from another. It is meant for debugging PDT builds, not for source lineage, so it does not trace back to the warehouse tables or columns the derived tables ultimately read from.
How do I get column-level lineage for Looker data?
Trace it from the warehouse rather than from Looker. A warehouse-native tool like Datatrail connects read-only, parses query history, including the SQL Looker generates, into column-level lineage, and follows each column from its raw source table through dbt to the table a LookML view reads. That gives you the field-level path and the before-you-ship impact analysis Looker's object-level lineage cannot, while you keep Looker's native graphs for PDT debugging and the BigQuery object view.
More use cases
Related features
Map your lineage, end to end
Connect your warehouse read-only and see your lineage map in minutes. Datatrail never moves or mutates your data.