Snowflake takes another step towards open data and AI architectures

For years, the data industry has debated a recurring dilemma: how to take advantage of a platform’s advanced capabilities without becoming locked into it. Processing engines, analytics platforms, AI agents, machine learning frameworks and multiple cloud environments now coexist, so interoperability has become a strategic requirement.

The recent public preview of the Iceberg Scan Plan API in Snowflake Horizon Catalog is much more than a new technical feature. It is further proof of how open formats, and Apache Iceberg in particular, are changing the design of modern data and artificial intelligence architectures.

Apache Iceberg has established itself as one of the most important open standards in the modern analytics ecosystem. Its proposition is simple and very powerful: separate data storage from the engines that consume it.

Instead of storing information in proprietary formats tied to a single platform, Iceberg lets data live in open storage (ADLS, S3, GCS, etc.) and be consumed from multiple engines such as:

• Snowflake
• Apache Spark
• Trino
• Databricks
• Flink
• PyIceberg
• AI and machine learning engines

This approach removes much of the traditional vendor lock-in and makes it possible to build far more flexible, evolvable and sustainable architectures.

The consequence is clear: data becomes a shared asset of the organisation rather than a resource held captive by a single technology.

Although open standards have solved much of the interoperability problem, one fundamental question remained: how to ensure that security and data governance policies hold regardless of the engine accessing the data.

This becomes especially relevant when the same data is used at the same time by:

• BI teams.
• Data scientists.
• Generative AI platforms.
• Operational applications.
• Business users.

Until now it was relatively easy to share data through Iceberg, but much harder to guarantee that access policies kept being applied consistently.

Snowflake has just introduced the ability to apply protection policies to Apache Iceberg tables queried from external engines through Snowflake Horizon Catalog. The documentation states that Snowflake can apply:

• Row access policies.
• Column masking policies.
• Tag-based policies.

What is really interesting is that these policies hold even when the data is queried from external engines such as:

• Apache Spark
• Trino
• PyIceberg
• Other engines compatible with the Iceberg Scan Plan API standard.

In other words, governance is no longer tied to the query engine and now travels with the data. This is one of the pieces modern data architectures needed to achieve true enterprise interoperability.

The release note published by Snowflake on 10 September 2026 announces the public preview of the Iceberg Scan Plan API in Horizon Catalog. Although it may look like a minor feature, its relevance is significant.

According to the documentation, Snowflake now offers two mechanisms to apply policies to Iceberg tables from external engines:

• Snowflake Connector for Spark, which routes queries through Snowflake.
• Iceberg REST Catalog Scan Plan API, which temporarily shares a dataset filtered according to the defined policies.

The second option is especially interesting because it works with any engine compatible with the Iceberg standard, avoiding dependencies on proprietary connectors. This is a very significant step towards truly open ecosystems.

The answer lies in the growing technological fragmentation of artificial intelligence environments. Today it is common to find organisations where:

• Snowflake acts as the corporate data platform.
• Spark runs data engineering processes.
• AI frameworks consume data through Python.
• RAG models use external vector indexes.
• Different AI agents access shared datasets.

In this context, forcing all access through a single platform limits scalability and innovation. Apache Iceberg lets multiple tools work on the same data and, with the capabilities Snowflake has announced, the governance policies defined by the organisation can also be maintained consistently.

This brings us ever closer to the paradigm of:

Write once, govern once, consume everywhere.

The industry trend is clear. The major vendors are converging on models where:

• Data stays in open formats.
• Processing engines are interchangeable.
• Governance is centralised.
• AI agents consume data from multiple platforms.

In this scenario, standards such as Apache Iceberg become a strategic enabler. We are no longer talking only about technical efficiency, but about:

• Reducing technology dependency.
• Making future migrations easier.
• Increasing data reuse.
• Accelerating AI initiatives.
• Simplifying collaboration between platforms.

Interoperability stops being a technical feature and becomes a business capability.

I have been saying for some time that one of the most important battles in the data world will not be about who stores the information, but about who best enables its interoperability. The arrival of the Iceberg Scan Plan API in Snowflake Horizon Catalog is another example of how the industry is moving towards more open architectures, where value no longer lies only in keeping data safe, but in allowing multiple engines, tools and AI agents to use it in a secure and governed way.

In my view, this move confirms a trend we have been seeing for a while: the future of analytics platforms lies in embracing open standards such as Apache Iceberg, which make it possible to combine the best of each ecosystem without sacrificing control, security or corporate governance. Because in modern data and AI architectures, the real competitive advantage is no longer keeping data locked inside one platform, but making it work freely across all of them.

• Snowflake (10 September 2026). Iceberg Scan Plan API in Horizon Catalog (Public Preview). Snowflake Documentation.
• Snowflake (2026). Enforce data protection policies on Apache Iceberg tables from external query engines. Snowflake Documentation.
• Originally published in Spanish on Alberto Alonso’s blog.