How to Track Data Lineage for Snowflake Tables: 4 Key Methods & Ways to Extend Them in 2026

Snowflake data lineage tracking methods: At a glance

Permalink to “Snowflake data lineage tracking methods: At a glance” #

---

How does data lineage for Snowflake tables work? An overview.

Permalink to “How does data lineage for Snowflake tables work? An overview.” #

Data lineage for your Snowflake ecosystem gets captured automatically via the Horizon Catalog. You can access Snowflake data lineage via various methods, such as SQL queries, the Python SDK, and the External Lineage API. You can also get a visual representation of the lineage graph using the Snowsight UI.

Here is what drives lineage capture in Snowflake:

• Write operation logging: All write operations to tables and columns are recorded automatically in system tables.

• Dependency mapping: The underlying queries for views are parsed to extract and map dependencies between objects.

• Procedure lineage capture: Stored procedure lineage is captured, though with some limitations.

• External lineage ingestion: Lineage from external ingestion, transformation, and orchestration tools also gets captured.

• ML pipeline lineage: A separate lineage workflow for ML pipelines based on Snowpark ML extends the data lineage capability.

One important distinction: lineage capture and lineage access are separate concerns. Snowflake captures lineage continuously in the background. How you access and query that lineage depends on the method you choose, each of which has different latency, depth, and coverage trade-offs covered in the next section.

---

What are the four primary methods of tracking data lineage in Snowflake?

Permalink to “What are the four primary methods of tracking data lineage in Snowflake?” #

Snowflake offers various methods for interacting with lineage metadata. You can use SQL, the Python SDK, and the Snowpark ML library for ML lineage. You can also bring in lineage produced by third-party tools like dbt and Airflow.

Let’s take a closer look at all of these methods.

1. Tracking Snowflake data lineage using the Snowsight UI

Permalink to “1. Tracking Snowflake data lineage using the Snowsight UI” #

The most common method of accessing data lineage is Snowsight. The top-level view of Snowsight is the Catalog, which includes the Database Explorer, which, in turn, lets you select a data object and view its lineage from the Lineage tab.

Using Snowsight UI to visualize Snowflake data lineage. Source: Atlan

From the lineage graph, you can do the following:

• Explore upstream and downstream relationships: Expand object-level relationships one node at a time using the + buttons in the graph.

• Column-level lineage: Track column-level lineage from the same UI, though not expandable in the graph; viewable only in a side panel in tabular format.

• Integrated governance: Apply tags to tables and columns directly from the lineage tab without leaving the view.

Note: While external lineage appears in the lineage graph, it currently doesn’t cover column-level lineage.

2. Tracking Snowflake data lineage using SQL

Permalink to “2. Tracking Snowflake data lineage using SQL” #

Snowflake has a solid foundation for tracking all relevant lineage metadata, which it exposes using a few views in the SNOWFLAKE.ACCOUNT_USAGE schema and one function in the SNOWFLAKE.CORE schema.

Note: The refresh latency of views in this schema can range from 45 minutes to 3 hours, so factor that in when using lineage for time-sensitive workflows.

The four key SQL artifacts for lineage tracking are:

1. OBJECT_DEPENDENCIES: The OBJECT_DEPENDENCIES is a table-level lineage view that maps dependencies captured at object creation time. Mapping can be by object name, object ID, or both. This is used for tracking lineage for views, materialized views, and user-defined functions.

2. ACCESS_HISTORY: For both tables and columns, the most detailed view of lineage is available in ACCESS_HISTORY. It contains the list of DIRECT_OBJECTS_ACCESSED and also the OBJECTS_MODIFIED by a given SQL query. Handles CTAS, INSERT, MERGE, among other DML operations, complementing OBJECT_DEPENDENCIES.

3. QUERY_HISTORY: QUERY_HISTORY records all queries run against Snowflake. Useful for reconstructing lineage from historical queries when no DML operation or view exists to derive lineage. Typically used for lineage enrichment and completeness.

4. GET_LINEAGE: Located in the CORE schema of the SNOWFLAKE catalog, the GET_LINEAGE function gives you an option to get the data or ML lineage for an object directly from the API. Supports both data and ML lineage, with a maximum depth of 5 levels from the referenced object. Doesn’t involve waiting 45 minutes to 3 hours for views to refresh as it uses Snowflake’s internal metadata to provide a near-real-time view of lineage.

3. Tracking data lineage for ML workflows

Permalink to “3. Tracking data lineage for ML workflows” #

While you can fetch the lineage metadata for ML workflows using the GET_LINEAGE function, there are more appropriate methods for ML engineers that align with ML-specific workflows and outputs.

You can access this metadata using two separate APIs:

1. Snowpark Lineage API: The Snowpark Lineage API works for both ML and general data lineage, but it requires you to use the snowflake-snowpark-python library. It’s best to use this API when you’re working with DataFrame-type outputs.

2. ML Lineage API: The ML Lineage API is based on the Snowpark ML library, snowflake-ml-python and works specifically with Snowflake ML objects, like datasets, models, and features.

Two important constraints to be aware of:

• ML lineage requires Enterprise Edition or higher; some non-ML lineage features are available on Standard Edition.
• Column-level lineage support is limited in both ML lineage APIs.

4. Ingesting and tracking external lineage metadata

Permalink to “4. Ingesting and tracking external lineage metadata” #

It’s common for organizations to use a host of services and tools for data storage, processing, transformation, and orchestration, among other things. Because data also flows through these systems, it is important to obtain lineage metadata from them to get the full picture of data lineage and provenance.

Snowflake supports external lineage ingestion via an OpenLineage-based External Lineage API, with two key constraints:

• Table-level only: Lineage events are currently supported at the table level; column-level is not yet available for external lineage
• OpenLineage v1 only: Snowflake currently supports OpenLineage v1, not v2

Snowflake officially supports OpenLineage-based lineage from dbt and Airflow out of the box. For other tools, you can build custom lineage connectors using the same API.

---

What are the biggest challenges with tracking data lineage for Snowflake tables?

Permalink to “What are the biggest challenges with tracking data lineage for Snowflake tables?” #

Snowflake’s lineage works very well for data assets within Snowflake, but for external lineage and lineage that crosses platform boundaries, there are notable limitations. You can work around some of those limitations natively in Snowflake, but others do require alternative solutions.

Here is a list of common challenges with lineage in Snowflake:

• Enterprise Edition requirement: For access to some of the advanced lineage features, like the ACCESS_HISTORY view and the GET_LINEAGE function, you need to use Enterprise Edition or higher.

• No automatic path from lineage to context: While Snowflake Intelligence uses the lineage metadata, there’s no automatic path from lineage to context, especially because lineage is fragmented in systems outside Snowflake, too.

• Column-level lineage gap for external sources: Bringing in lineage is possible, but the External Lineage API does not support column-level lineage. The API is also in preview right now.

• One-year retention limit: There’s a one-year retention for the lineage metadata stored in the ACCOUNT_USAGE schema. You can create an archive of the lineage metadata using regular backups if you want to retain the data longer.

These limitations hinder the integration of lineage metadata across a host of systems which aren’t natively supported by Snowflake, breaking the continuous thread of data that is required to connect and patch context within an organization.

Let’s look at how you can overcome these limitations with an open, interoperable, sovereign context layer.

---

How can you track cross-platform data lineage with Atlan?

Permalink to “How can you track cross-platform data lineage with Atlan?” #

Capturing structural metadata, lineage, quality metrics, governance, and semantics all serve one organizational goal: answering business questions more accurately. What makes that possible is context. Context, however, is only as complete as the lineage that feeds it.

Context is fragmented if the lineage is fragmented. This is where Atlan comes into the picture as the platform that acts as a sovereign context layer for your organization, irrespective of what your data stack looks like. Lineage is a critical piece of that context puzzle because it establishes the flow and provenance of data across every system in your organization.

The following Atlan features help you comprehensively capture, manage, and enrich lineage for Snowflake and beyond:

• Automated lineage discovery: Automatically ingest and stitch cross-system, column-level lineage across 100-plus connectors using SQL parsing, API crawling, and native connectors.

• Granular column-level lineage: Granular column-level lineage for Snowflake and other tools in your stack, going deeper than Snowflake’s native external lineage support.

• Custom lineage capabilities: Build and extend lineage using OpenLineage or Atlan’s Lineage Builder for tools not covered by native connectors.

• Lineage editing and enrichment: Fill gaps in lineage manually or through automation, keeping the lineage graph accurate and complete over time.

• Metadata propagation over lineage: Propagate tags, classifications, quality signals, and governance rules over the lineage graph, so that context travels with data.

• AI agent integration: Integrate lineage into context for AI agents using Atlan’s MCP server, making lineage a live input to agent reasoning.

• Impact analysis: Detailed impact analysis using the lineage graph across your entire data stack, identifying downstream dependencies and notifying the right people before making changes.

All of these lineage features collectively enrich the context layer that Atlan creates for Snowflake and other tools in your data stack. Atlan is Snowflake’s 2025 Data Governance Partner of the Year and a Leader in the 2026 Gartner Magic Quadrant for Data & Analytics Governance.

Let’s look at how Atlan’s customers use these lineage features in their workflows.

---

Real stories from real customers: Extend native Snowflake lineage with an active metadata control plane

Permalink to “Real stories from real customers: Extend native Snowflake lineage with an active metadata control plane” #

---

Frequently Asked Questions

Permalink to “Frequently Asked Questions” #

How does Snowflake capture and track data lineage?

Permalink to “How does Snowflake capture and track data lineage?” #

Snowflake automatically captures lineage via write operations, dependency mapping, and procedure tracking. Users access it through the Snowsight UI, SQL views, Python SDK, or the External Lineage API.

Where is data lineage metadata stored in Snowflake?

Permalink to “Where is data lineage metadata stored in Snowflake?” #

Lineage metadata is stored in the SNOWFLAKE.ACCOUNT_USAGE schema with 45-minute to 3-hour refresh latency. Near-real-time access is available via the GET_LINEAGE function in the SNOWFLAKE.CORE schema.

Does Snowflake support column-level lineage?

Permalink to “Does Snowflake support column-level lineage?” #

Column-level lineage is supported for native Snowflake objects via the Snowsight UI, ACCESS_HISTORY view, and GET_LINEAGE function. External lineage ingestion currently supports table-level only.

What Snowflake edition is needed for full lineage features?

Permalink to “What Snowflake edition is needed for full lineage features?” #

Enterprise Edition or above is required for ACCESS_HISTORY, GET_LINEAGE, column-level lineage, the Snowsight lineage UI, and ML lineage. Basic features like OBJECT_DEPENDENCIES and QUERY_HISTORY are available in all editions.

How long is lineage metadata retained in Snowflake?

Permalink to “How long is lineage metadata retained in Snowflake?” #

Native lineage metadata is retained for one year in the SNOWFLAKE.ACCOUNT_USAGE schema. For longer retention, you can create archives by backing up lineage data to persistent objects.

---

Extending Snowflake data lineage to your entire data and AI stack for complete context

Permalink to “Extending Snowflake data lineage to your entire data and AI stack for complete context” #

Snowflake offers a solid built-in solution and foundation for lineage, and it works well if you’re working solely in Snowflake. As of the start of 2026, some OpenLineage-based connectors are available, but they are currently in preview and don’t cover all popular data sources for lineage metadata. External lineage can only be captured at a table level.

Some of these limitations can be mitigated within Snowflake, such as the one-year retention limit. However, what can’t be solved at this point is the ability to bring lineage metadata from all tools and technologies in your data stack.

That’s where Atlan comes in. It first enriches Snowflake’s lineage and also extends the lineage capabilities beyond Snowflake. With Atlan, you get granular cross-platform lineage that works with governance, quality, and business definitions. Atlan helps power the enterprise context layer, feeding AI agents, governance workflows, not just for Snowflake but also for other tools in your data and AI stack.