Snowflake already allowed teams to trace data across its own objects. Since September 3, 2026, External Lineage extends that capability to external systems and is now generally available for production environments.
There is a question every data team has had to answer at some point, usually with more uncertainty than they would like:
Where exactly does this number come from?
The question may arise during an audit, a compliance review, or simply when two reports do not match. Answering it often means bringing several people together, reviewing processes, checking integrations, and manually reconstructing the data journey.
Until now, Snowflake provided native lineage between objects and columns within the platform: a map showing how tables, views, and other elements are related.
The problem is that most modern data architectures do not live entirely inside Snowflake. Data may originate in operational systems, move through orchestration and transformation tools, and ultimately reach different destinations.
This is where External Lineage comes in.
According to Snowflake’s official External Lineage documentation, the feature extends native lineage to incorporate sources and destinations outside Snowflake, providing a more complete view of how data moves across the wider data ecosystem.
What can you do now that was more difficult before?
Dependency analysis
Before modifying a table or process, teams can analyze which objects and destinations depend on it, including elements located outside Snowflake.
This makes it easier to anticipate the impact of a change and reduce the risk of breaking downstream processes.
Auditing and compliance
Lineage helps document where data comes from across different systems, making investigations easier when an organization needs to demonstrate the origin of specific information.
Instead of manually reconstructing the journey, teams can use the lineage graph available in Snowflake.
Migrations and architecture modernization
When migrating legacy systems to the cloud, understanding dependencies between systems becomes especially important.
External Lineage makes it possible to visualize how different parts of a data pipeline are connected, even when some of those components are outside Snowflake.
Faster troubleshooting
When incorrect data reaches a report or business process, lineage helps reduce the number of systems and transformations that need to be investigated.
The goal is not to automatically identify where the error occurred, but to narrow down the data path that needs to be reviewed.
Data lineage: what it does and what it does not do
It is important to be precise.
Data lineage shows how data is related and which systems it has passed through. It helps teams understand upstream and downstream dependencies and follow the path of data across a pipeline.
However, lineage alone does not determine data quality or explain the business meaning of a metric.
For example, knowing that a KPI comes from a particular table does not necessarily answer questions such as:
- What exactly does this KPI mean?
- Who is responsible for this data?
- What quality rules should it meet?
- Which policy should apply to this information?
These questions belong to other areas of data governance, including data quality, semantic context, classification, and ownership.
Why does External Lineage matter beyond the technical team?
Traceability is often presented as an engineering concern, but its impact goes much further.
The first benefit is trust in data.
When the origin of a figure is documented and can be queried, organizations become less dependent on someone remembering how a particular report was built. This reduces friction between teams and makes it easier for users to trust the data they rely on to make decisions.
The second benefit is the cost of answering data-related questions.
An audit, internal review, or question about the origin of a KPI can move from requiring a manual reconstruction to relying on the lineage information available in the platform.
The exact savings will vary from one organization to another, but the change is significant: moving from reconstructing the data journey to being able to query it.
How does External Lineage work with OpenLineage?
Snowflake uses OpenLineage as a standard for receiving lineage information from external tools.
The overall process is straightforward:
- A tool such as dbt or Apache Airflow generates OpenLineage events.
- These events are sent to Snowflake’s External Lineage REST endpoint.
- Snowflake incorporates the information into the lineage graph.
- External objects appear in Snowsight as external nodes.
- The lineage can also be queried using SQL.
Snowflake provides specific guidance for configuring dbt with External Lineage, while OpenLineage provides documentation for integrating Apache Airflow with OpenLineage.
The advantage of using OpenLineage is that organizations do not need to build a proprietary metadata exchange model from scratch for every tool that already supports the standard.
Can lineage be queried using SQL?
Yes. And this is one of the most interesting capabilities when it comes to automating data governance processes.
Snowflake allows lineage information to be queried through the SNOWFLAKE.CORE.GET_LINEAGE function. It can be used to query upstream and downstream relationships and work with external objects once their lineage information has been ingested into the account.
The details and syntax are available in the official Snowflake documentation for GET_LINEAGE.
This makes it possible to use lineage as operational information, rather than simply as a visual representation for investigating incidents.
Start with what matters
External Lineage has capacity limits and a one-year retention period, which means deciding which data flows to include is a design decision rather than a minor implementation detail. Snowflake’s current documentation specifies, among other limitations, a maximum of 20,000 external lineage edges stored per account and up to 15,000 edges generated by a single event.
For that reason, the most effective approach is usually not to try to trace everything from day one.
Instead, start by identifying the flows that support business-critical decisions:
- Data presented to executive teams.
- Indicators used in regulatory reporting.
- Information supporting billing processes.
- Data used in critical financial or business processes.
- Pipelines that feed multiple reports or applications.
These are precisely the flows someone is likely to ask about:
Where does this data come from?
Once that core is covered, expanding the lineage map makes sense. Trying to document everything from the beginning can result in a huge graph that nobody actually uses.
External Lineage as part of a Data Governance strategy
External Lineage addresses one specific part of data governance: traceability.
But a complete Data Governance strategy needs to combine traceability with other capabilities, such as data quality, classification, access policies, semantic context, and ownership.
Snowflake brings these capabilities together through Horizon Catalog, which combines data cataloging, governance, quality, protection, and lineage. More information is available in the Snowflake Horizon Catalog documentation.
The key is therefore not to view External Lineage as an isolated solution, but as one more component of a broader data governance architecture.
Could you explain where every piece of data in your dashboard comes from?
Traceability no longer has to stop at the Snowflake boundary.
With External Lineage, Snowflake expands the map to connect the different systems involved in the data journey, providing a more complete view of how information reaches the processes and decisions that depend on it.
At Bravent, we help data teams implement Data Governance, traceability, and data management strategies across their analytics platforms, focusing on the flows that truly support the business.
Let’s talk: info@bravent.net
