Snowflake Data Lineage, Column-Level and Automatic
Snowflake already records who queried what in ACCESS_HISTORY and QUERY_HISTORY. Datatrail reads those logs read-only and turns them into column-level lineage you never had to draw.
Read-only connection. Datatrail never moves or mutates your data.
In short
Snowflake data lineage maps how data moves between Snowflake tables and columns, from raw landing tables through every transformation to the views that feed reporting. Datatrail connects to Snowflake read-only and parses ACCESS_HISTORY and QUERY_HISTORY to build column-level lineage automatically, so you can trace any column to its source, see what reads it, and scope the downstream impact of a change without writing or maintaining a single mapping by hand.
Why it fits
Snowflake teams who want automatic column-level lineage without maintaining it by hand.
From your query history
Datatrail builds lineage from Snowflake ACCESS_HISTORY and QUERY_HISTORY, so it reflects the queries that actually ran, not a stale diagram.
Column-level, not just table
Trace an individual column from its source through each CTAS and view to the dashboard field it lands in.
Read-only by design
The connection is a read-only role against your metadata and logs. Datatrail never writes to or moves your Snowflake data.
What Snowflake gives you natively
Snowflake has the best native lineage foundation of any warehouse, and it is worth understanding before you buy anything. SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY records the objects and, importantly, the columns each query read and wrote, with base objects already resolved for you. QUERY_HISTORY carries the full SQL text alongside it. Between the two, the raw material for a real column-level lineage graph is sitting in your account right now.
What Snowflake does not give you is the graph. You get an event log, not a map. Turning one into the other is the work, and it is more work than it looks.
Why hand-rolling it gets expensive
Teams that try this usually get a table-level graph working in a sprint and then stall. The parts that stall them:
- The SQL parser. To resolve columns rather than tables you have to parse the SQL, which means understanding CTEs, aliases, window functions, CASE expressions, and expanding
SELECT *against the schema as it was when the query ran. This is a genuinely hard piece of software and nobody on your team was hired to write it. - Transitive impact. One hop is easy. Walking the chain to the fifth-order dependent, deduplicating across thousands of near-identical queries, and keeping it fast is not.
- Retention and drift. ACCOUNT_USAGE views have a retention window, and a table that rebuilds quarterly can fall out of it. Your graph decays silently.
- The BI boundary. Snowflake knows nothing about the Looker dashboard that reads the view, and the dashboard is where impact actually lands.
What Datatrail does with it
Datatrail connects with a read-only role, reads ACCESS_HISTORY and QUERY_HISTORY, parses the SQL into column-level lineage, and keeps its own persistent graph so nothing ages out from under you. It reconciles the result against your dbt models and exposures, then extends the chain into the BI layer.
From there, impact analysis gives you the blast radius of a change before you merge it, and schema change alerts catch the upstream changes that land on you unannounced. Nothing is ever written back to Snowflake. For the full walkthrough of the native tables, read the Snowflake data lineage guide, or compare the field in our guide to data lineage tools.
Questions people ask
Snowflake lineage, answered
Does Snowflake have built-in data lineage?
Snowflake gives you the raw material rather than a finished lineage graph. ACCESS_HISTORY records the objects and columns each query read and wrote, and QUERY_HISTORY carries the SQL text. That is enough to reconstruct column-level lineage, but Snowflake does not assemble it into a browsable map, follow it transitively, or extend it to the dashboards downstream. You either build that layer or buy it.
How do I trace a column back to its source in Snowflake?
Query ACCESS_HISTORY for the queries that wrote to your target table, pull their SQL from QUERY_HISTORY, and read the derivation. For one column that works. It stops scaling the moment the derivation is several hops deep, involves CTEs or SELECT *, or the query that built the table has aged out of the retention window. Automated column-level lineage exists to make that a one-click answer instead of an afternoon.
What is ACCESS_HISTORY used for?
ACCESS_HISTORY is the Snowflake ACCOUNT_USAGE view that records which objects and columns every query read and wrote, with base objects resolved through views. It is the single most useful table in Snowflake for lineage, auditing, and access governance, because unlike a manually maintained diagram it reflects what actually ran against your data.
Does connecting a lineage tool to Snowflake cost credits?
Reading ACCOUNT_USAGE views consumes some warehouse compute, so there is a small credit cost to any lineage tool that polls them, including one you build yourself. It is typically minor relative to your transformation workload. Datatrail connects with a read-only role, reads metadata and query history only, and never moves, copies, or mutates data.
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.