Snowflake AI data interoperability bets on Iceberg and Horizon Catalog
Snowflake is pitching governed Iceberg access as an answer to fragmented AI data pipelines, with policy enforcement and rollout details still requiring scrutiny.
By Colin Brandt · Enterprise Reporter
· 3 min read
Snowflake AI data interoperability is the company’s answer to a familiar enterprise AI problem: data spread across warehouses, lakehouses and processing engines, each with its own copies and controls. Snowflake is positioning its Horizon Catalog and Apache Iceberg support as a shared, governed table layer for those workloads, rather than announcing a new foundation model or a discrete AI product launch.
The pitch matters because model access has become easier while the data around a model remains difficult to use safely across systems. In an AWS Marketplace Series interview published by SiliconANGLE on Aug. 11, Snowflake partner engineering leader Zahir Gadiwan said customers need trusted data, business context, governance and scalable infrastructure to operate together. The interview was part of paid coverage sponsored by AWS, so its claims are Snowflake’s view of the architecture, not an independent performance assessment.
How does Snowflake AI data interoperability work?
Horizon Catalog integrates Apache Polaris and exposes an Iceberg REST catalog API, according to Snowflake’s documentation. That lets external query engines connect to Snowflake-managed Iceberg tables through a Horizon endpoint while using Snowflake users, roles, policies and authentication.
Snowflake lists Apache Spark, Flink, Dremio, DuckDB, Trino, PyIceberg, StarRocks and Apache Doris among engines integrated with that API. The practical objective is to let a company use more than one compute engine against common tables rather than maintain a separate replicated dataset, permissions model and audit trail for every tool. Snowflake says this can reduce duplication, but customers will still need to confirm whether their specific pipelines create copies elsewhere.
The write path needs careful treatment. In a March 17 Snowflake post, the company described external-engine writes to Snowflake-managed Iceberg tables as a public preview, while external reads were generally available. Current documentation describes both read and write workflows and includes a diagram labeling them generally available, but the supplied documentation does not give a dated announcement confirming the change. Teams should verify availability for the engine and region they plan to use.
Governance remains an engine-by-engine problem
Open table access does not mean identical controls in every runtime. Snowflake says policy enforcement through its Spark connector was generally available, but enforcement maturity varies across other Iceberg REST-compatible engines. Its own technical comparison also says fine-grained policies do not automatically follow a query when it crosses between platforms, potentially requiring policies to be administered in both systems or concentrated in one policy authority.
That distinction is material for AI workflows, where access to sensitive data may be as important as access to the table itself. Enterprise security is an organization-wide program covering controls, policies, people and recovery planning, not a catalog capability alone.
Snowflake is also adding a semantic layer to the argument. Gadiwan said Cortex Analyst can combine Iceberg tables with Snowflake tables into a semantic view, adding business meaning beyond raw schemas; he said Cortex Analyst and Cortex Agents are designed to apply that context. Snowflake’s broader position is that production AI needs data, permissions and business context alongside models. The evidence does not show that interoperability by itself solves those operational problems.
There is a cost question, too. Snowflake lists Horizon Iceberg REST Catalog API requests at 0.5 credit per million calls, with billing scheduled to begin in the second half of 2026, subject to change. For operators, the evaluation is straightforward: identify the catalog owner, engines needing read or write access, policy behavior in each engine, and whether the proposed design actually eliminates pipeline copies.
This story draws on original reporting from SiliconANGLE.
