Unified Governance for the Interoperable Lakehouse with Snowflake Horizon Catalog

Govern every engine, from reads to writes: Centralize your governance for policy-protected Apache Iceberg™ tables without compromising flexibility.

Open lakehouses give organizations the freedom to store Apache Iceberg data on any cloud storage and process it with a variety of engines and platforms. Interoperability evolves in levels, progressing from multi-engine governance under a single platform, to cross-platform catalog interoperability, to a fully open ecosystem. Yet even at the multi-engine level, open architectures often come at a steep price: fragmented security and inconsistent governance. Organizations have long been forced to choose between compute flexibility and data governance — until now.

In our previous post, we shared Snowflake’s pragmatic, phased journey toward open, interoperable governance. We began by updating the Snowflake Connector for Spark, giving customers a production-ready capability to enforce Snowflake’s row access and column masking policies on their Iceberg tables, while leveraging the Connector’s advanced join and pushdown capabilities for optimal Spark performance. Alongside that launch, we discussed the Iceberg REST Scan Plan API as the open, longer-term foundation for cross-engine governance.

Now, we are delivering on that foundation.

Announcing public preview: Fine-grained access control for reads and writes via the Iceberg REST Catalog API

We are taking a major leap forward for open data architectures. By combining our next-generation policy evaluation engine with native support for the Apache Iceberg REST Scan Plan API, Snowflake Horizon Catalog is the first catalog in the industry to deliver fine-grained access control for all Iceberg tables — whether Snowflake-managed or unmanaged.

Any Iceberg-compatible engine including Apache Spark™, Trino, PyIceberg, Apache Flink and DuckDB that support the Iceberg Scan Plan API can now be used to query these tables. Instead of deploying separate, engine-specific security plugins, data teams define fine-grained data protection policies centrally in Snowflake Horizon Catalog and enforce them seamlessly across every engine that implements the latest Iceberg REST specification.

Before this launch, external engines simply couldn’t access policy-protected tables: any attempt to query them immediately fails with an error. With the native support for Scan Plan API, the catalog can evaluate the user’s identity against all row access and column masking policies, materializing an authorized scan plan before granting access. The engine only ever sees the exact slice of data it is permitted to process. However, the Iceberg Scan Plan specification stops there — it is limited strictly to reads.

This is where Snowflake Horizon Catalog goes further. We extend governance beyond the read path, enabling users to both read and write to policy-protected tables. The external engine does not need to understand Snowflake’s policy language or implement a custom connector; it simply interacts with the standard Iceberg REST catalog interface while Horizon Catalog acts as the central authority where governance decisions are defined and evaluated. This eliminates the massive engineering overhead of maintaining fragmented security models or juggling different engines for reads and writes.

As Srinivas Podila, Lead Member of Technical Staff at Salesforce, explains:

“Salesforce's Enterprise Data Lakehouse spans multiple external query engines, so consistent governance can't depend on any single one. As we extend our internal role-based access control framework to enforce tagging and masking policies natively, Snowflake's Horizon Catalog lets us extend those same fine-grained access control policies to external engines reading our Iceberg data — defining protection rules once and enforcing them consistently, without building separate engine-specific integrations.”

Under the hood: How governed reads and writes work

By leveraging the open Iceberg REST Catalog interface, Horizon Catalog acts as the central gatekeeper for any engine compatible with the latest Iceberg SDK. When an external engine queries a policy-protected table, the workflow is seamless:

1. Request and policy evaluation: The external engine sends a standard REST Catalog request. Horizon Catalog evaluates the query context against active row access and masking policies on the table. Snowflake Horizon’s built-in optimization bypasses scan plan materialization based on policy evaluation whenever possible, keeping query latency low.
2. Governed reads: If the policy evaluation in the first step determines that dynamic filtering or masking is required, Horizon Catalog generates a precisely filtered, governance-enforced data set (scan plan). The external engine doesn’t see unauthorized rows or unmasked values.
3. Governed writes: When an external engine appends or modifies data, Horizon Catalog validates the writer's privileges and the policy context up front, enforcing policy compliance before any changes are committed.
4. External execution: The external engine processes the data using its own compute, while leveraging Horizon Catalog as the single source of truth for governance decisions.

This architecture ensures fine-grained, cross-engine protection across both Snowflake-managed and customer-managed Iceberg storage, without forcing a performance penalty on every read and write.

Unified governance for your lakehouse

Enforcing policies across external engines solves a critical access challenge, but cross-engine enforcement is only one piece of the puzzle. For an open lakehouse to be truly governed, policy evaluation cannot live in a vacuum; it must be continuous and integrated directly into the broader governance lifecycle.

This is where Snowflake Horizon Catalog brings our vision for unified governance to life. Rather than forcing organizations to stitch together fragmented point solutions for discovery, access control and auditing, Horizon Catalog serves as the central control plane for your entire lakehouse. With this launch, Horizon connects external engines directly into Snowflake's end-to-end continuous governance loop: Discover, Protect and Trust.

1. Discover: Know your data

Governance starts with understanding what data you hold. Snowflake Sensitive Data Classification automatically inspects your data to identify where sensitive information lives, right down to the column level. You don't have to manually hunt for PII to earn this visibility — it is built in. Horizon seamlessly translates these discoveries into tags across your lakehouse, enabling you to identify exactly what needs protecting before any engine accesses it.

2. Protect: Attribute-based access control (ABAC) for reads and writes

Once sensitive data is classified, context turns into protection. With Snowflake’s ABAC, data teams can define a masking or row access policy once and assign it to a tag. Any Iceberg table or column bearing that tag automatically inherits the protection based on its attributes. Whether an external engine is reading data or appending new writes, Horizon Catalog enforces these ABAC policies centrally, ensuring consistent security without duplicating policy logic across your open lakehouse.

3. Trust: One audit plane for humans and AI

Unified governance requires a single, verifiable source of truth. Snowflake Access History and Lineage provide a complete audit trail of how data moves and who accesses it. Operations originating from external engines through the Iceberg REST Catalog are captured directly in Horizon. More importantly, this single plane tracks both human and agentic workflows. Whether a data analyst queried an Iceberg table in Spark, or a Snowflake Cortex AI agent accessed it, you have complete visibility and verifiable records of policy enforcement across your entire lakehouse.

This continuous, engine-agnostic approach is exactly how organizations are achieving true openness. Luca Falsina, Principal Software Engineer II, and Abhro Bhaduri, Group Product Manager at Booking.com, describe their approach:

“Snowflake’s Horizon Catalog helps Booking.com mature governance across its open, federated lakehouse—applying consistent, fine-grained access controls to a single copy of Iceberg data, regardless of whether it’s processed by Spark, PyIceberg, Flink, or another external engine. This enables vendor neutrality, compute optionality, and interoperability without compromising centrally managed policy enforcement.”

These examples illustrate the precise customer outcome we are working toward: a single governance model that can span data location, compute engine and cloud environment without requiring a separate governance model for every access path.

What’s next: Building the open governance foundation together

We believe open governance requires more than a data catalog that simply lists metadata. It demands shared industry primitives for identity, catalog context and auditability. While Horizon Catalog’s Scan Plan integration provides a pragmatic, production-ready model for centralized enforcement available today, our vision encompasses the broader open source ecosystem.

That vision is taking shape in the community with initiatives that delegate policy enforcement to external engines and make context portable across catalogs. Snowflake engineers Prashant Singh and Russel Spitzer led an open source effort to introduce Read Restrictions in the Apache Iceberg community, establishing an open standard where a single policy is defined once and enforced consistently by engines implementing the specification. As this standard evolves across the engine ecosystem, we are exploring how to integrate it into Snowflake Horizon to further advance open, interoperable governance.

We are also currently exploring the use of the new Labels contribution to exchange catalog-tracked table metadata. Labels are defined as a standardized read path for exchanging catalog-owned metadata, returning optional, key-value pairs when an object is loaded. They provide a path to share catalog context across tools, making them usable for non-sensitive use cases like data discovery, cost attribution and AI semantics. However, because Labels lack first-class key-value entities, inheritance semantics and policy enforcement rules, they cannot synchronize governance controls or deliver true 'author-once, enforce-everywhere' policy behavior.

Snowflake remains committed to driving community standards forward while delivering immediate, secure value to our customers. We believe rigorous governance versus an open architecture is a false tradeoff. The goal is interoperability without compromise.

Get started

Ready to bring unified governance to your open lakehouse? Define row access and masking policies on your Iceberg tables in Snowflake today, and enforce protection across external query engines for both reads and writes. Follow the Scan Plan API documentation to configure your Iceberg REST catalog, connect your engines and test policies in minutes.

S Muralidhar, Vishwa Lakkundi and Prashant Singh also contributed to this post.