Scope: Multi-engine data access via Apache Iceberg, external catalog integration, cross-organizational data sharing, CDC and data integration patterns, and data portability across the Snowflake ecosystem

Target Audience: Data architects, platform engineers, data engineers, technology leaders, solution architects, sales engineers, and technical account managers who design, operate, and advise on data platforms spanning multiple engines, tools, and organizational boundaries

Prerequisites: Familiarity with the five Snowflake Well-Architected Framework pillars. Core WAF pillar guidance should be adopted before applying this lens.

Out of Scope: Foundational Snowflake architecture (covered by WAF pillars), single-engine Snowflake deployments without external integration needs, application-layer integration patterns

Current state (Q1 2026). Open table formats and catalog protocols have matured substantially, but cross-platform governance, policy enforcement, and business logic portability remain uneven across the industry. Customers operating heterogeneous data estates will encounter real friction in these areas today. Snowflake is actively working to close these gaps and shares the open, interoperable future-state vision — this lens calls out current limitations explicitly so architecture decisions are grounded in present capabilities rather than projected ones.

Organizations increasingly operate multi-engine data ecosystems where Spark, Trino, Flink, DuckDB, and other engines need governed access to the same data. Apache Iceberg has emerged as the open table format standard enabling this, and Snowflake sits at the center—as both a catalog provider (through Horizon Catalog's Polaris APIs) and a catalog consumer (through Catalog-Linked Databases and catalog integrations). Snowflake created Apache Polaris and contributed it to the Apache Software Foundation, where it graduated to a Top-Level Project in February 2026.

Snowflake's interoperability is bidirectional by design. Through the Iceberg REST catalog protocol, Snowflake serves as both a catalog provider (external engines connect to Polaris APIs in Horizon Catalog to read and write Snowflake-managed Iceberg Tables) and a catalog consumer (Snowflake connects to any external Iceberg REST-enabled catalog to read and write Iceberg Tables managed elsewhere). This bidirectional openness is a defining characteristic: rather than requiring all data to be imported into a proprietary format, Snowflake participates as a peer in the open Iceberg ecosystem.

Interoperability extends beyond data formats to semantic definitions. Snowflake co-founded the Open Semantic Interchange (OSI) initiative—a vendor-neutral standard (spec v0.1 finalized January 2026, Apache 2.0 license) for exchanging semantic models (metrics, dimensions, relationships) across BI, AI, and analytics platforms. With 50+ member organizations including Salesforce, Databricks, dbt Labs, Oracle, and Collibra, OSI ensures that business logic defined in one tool is portable to others without manual re-creation.

Snowflake's Iceberg support continues to advance: Apache Iceberg v3 support adds new data types (geography, geometry, nanosecond, variant), default values, deletion vectors, and row lineage. These are distinct features with different purposes: deletion vectors enable merge-on-read write optimization, improving write throughput by deferring physical deletes. Row lineage is a separate capability providing standardized CDC semantics (INSERT, UPDATE, DELETE, MERGE) readable by both Snowflake and external engines — including externally-managed Iceberg tables. Iceberg v3 is in Public Preview in Snowflake as of March 2026, and ecosystem-wide adoption remains limited — most production tables are on v2. See the Feature Status table for Snowflake's current support status.

The core WAF pillars address universal Snowflake architecture concerns. This lens provides the additional guidance that arises when Snowflake participates in a broader data ecosystem—catalog strategy, table format selection, cross-engine governance, semantic model portability, CDC patterns (Streams + Tasks, Dynamic Tables, Dynamic Iceberg Tables), Delta Lake interop, cross-organizational sharing, and integration surface continuity. Apply this lens alongside the pillars, not instead of them.

Bring compute to data, not data to compute: Let engines query data in place rather than copying it to each consumer. Snowflake enables this through Horizon Catalog, Catalog-Linked Databases, and Iceberg Tables on customer-managed storage.

Embrace open standards; work toward unified governance: Use Apache Iceberg, the Iceberg REST catalog protocol, and Snowflake Horizon to provide open-format flexibility. In OSS engine deployments, Horizon can serve as a single governance control plane. In vendor co-existence deployments, governance fragmentation is a current operational reality — design policies to be duplicated across catalogs in the interim while working toward convergence on cross-vendor enforcement standards.

Share data securely without copying: Prefer Secure Data Sharing and Data Clean Rooms over file extracts to eliminate governance gaps, staleness, and storage duplication.

Preserve optionality through open standards: Snowflake's support for ANSI SQL, Apache Iceberg, PostgreSQL wire protocol (Snowflake Postgres), and standard APIs (JDBC, ODBC, REST, Polaris) ensures that skills and workloads remain portable. Evaluate portability alongside capability—not instead of it.

Design for resilience across the integration surface: Extend continuity planning beyond databases to the full integration layer—catalog endpoints, external engine connections, Shares, Clean Rooms, and pipelines—using Failover Groups and Client Redirect.

Enable semantic interoperability across tools: Adopt the Open Semantic Interchange (OSI) standard so that metrics, dimensions, and business logic definitions are portable across BI, AI, and analytics platforms—eliminating redundant semantic definitions and ensuring consistent meaning across the ecosystem.

Security and governance for interoperable architectures extends the Security & Governance pillar into territory the base pillar does not cover: governing data that is accessed by external engines through Horizon Catalog's Polaris APIs, consumed from external catalogs via Catalog-Linked Databases, shared across organizations through Secure Data Sharing and Data Clean Rooms, and described by portable semantic models through OSI. Each of these access paths introduces governance surface area—authentication, authorization, audit, and policy enforcement—that must remain consistent regardless of which engine or tool initiates the query. The unique challenge is preventing governance fragmentation: when multiple engines can reach the same data, the catalog must be the single control plane, not a collection of per-engine policies.

Outbound access: External engines configure their Iceberg REST catalog client to point at the Horizon endpoint—no Snowflake-specific libraries required. Engines authenticate via OAuth and receive vended credentials for storage access. See Access Iceberg tables with an external engine through Horizon Catalog for engine-specific configuration (Spark, Trino, Flink, DuckDB, Dremio, and others).

Inbound access via CLD: See Use a catalog-linked database for Iceberg tables for setup, including catalog integrations for AWS Glue REST, Unity Catalog, and other Iceberg REST catalogs.

Horizon Catalog is the recommended path for all Snowflake customers. Apache Polaris and Snowflake Open Catalog serve a specific use case: organizations that require a vendor-neutral, fully decoupled catalog, or that need an open-source exit ramp. Positioning: Horizon for governed multi-engine access; Polaris/Open Catalog for OSS-first shops or where Snowflake compute is explicitly out of scope. Do not default to recommending Open Catalog in situations where Horizon would meet the requirement.

Operational excellence for interoperable architectures extends the Operational Excellence pillar with concerns specific to multi-engine and multi-catalog environments: establishing repeatable CDC pipelines using native Snowflake mechanisms (Streams + Tasks, Dynamic Tables, Dynamic Iceberg Tables), automating metadata synchronization from external catalogs through Catalog-Linked Databases, reading upstream Delta Lake tables via Delta Direct, maintaining semantic model portability through OSI-compatible definitions, and curating governed data products that are discoverable across the ecosystem.

CDC with Streams + Tasks: See Getting Started with Streams & Tasks for the imperative CDC pattern using CREATE STREAM, SYSTEM$STREAM_HAS_DATA(), and MERGE logic in scheduled Tasks.

Dynamic Tables: See Creating Dynamic Tables for declarative pipelines where Snowflake manages incremental refresh to a target lag.

Dynamic Iceberg Tables: See Creating Dynamic Iceberg Tables for pipelines that output to Iceberg format on external storage, making results accessible to external engines through Horizon.

Iceberg ingestion: All standard Snowflake ingestion methods work with Iceberg tables (GA since Nov 2024): COPY INTO, Snowpipe, and Snowpipe Streaming. Teams do not sacrifice ingestion capabilities by choosing Iceberg format.

Delta Direct: See Create an Iceberg table from Delta files for reading Delta Lake tables directly in Snowflake with auto-refresh.

Reliability for interoperable architectures extends the Reliability pillar beyond database availability to the full integration surface. When external engines depend on Horizon Catalog's Polaris API endpoint, cross-organizational collaborators rely on Shares and Clean Rooms, and ingestion flows through Openflow or Snowpipe, each becomes a continuity concern the base pillar does not specifically address. Snowflake extends its managed DR capabilities to open-format data: Iceberg tables—including Dynamic Iceberg Tables—replicate through Failover Groups alongside standard tables, eliminating the need for custom replication engineering. The unique challenge is ensuring the entire interoperability layer fails over together, not just the databases.

Failover Groups: Configure with OBJECT_TYPES = DATABASES, SHARES, ROLES so the entire interoperability surface fails over together. Including SHARES covers Data Sharing consumers and Clean Room collaborators; including ROLES replicates access policies. See Failover Groups for setup.

Iceberg table replication: Iceberg tables replicate through Failover Groups like standard tables. Because they depend on external volumes (account-level objects), the source external volume must include a storage location in the target region—a one-time setup. In a self-managed Iceberg deployment, cross-region DR requires custom replication for both catalog metadata and data files; Snowflake manages both as a platform capability. See Configure replication for Iceberg tables for details.

Data protection: Snowflake extends Time Travel and UNDROP ICEBERG TABLE to Snowflake-managed Iceberg data, providing recovery safeguards within the configured DATA_RETENTION_TIME_IN_DAYS window. These capabilities do not apply to externally-managed Iceberg tables — tables whose catalog and lifecycle are owned outside Snowflake (e.g., Databricks-managed, Glue-managed). For externally-managed tables, data recovery is the responsibility of the owning platform. Factor this into table ownership decisions when DR requirements are strict.

Performance for interoperable architectures extends the Performance pillar with considerations unique to multi-engine data access. Table format selection (native vs. Iceberg vs. Dynamic Iceberg) directly affects query optimization, caching behavior, and cross-engine read performance. Credential flows—how external engines authenticate and receive vended storage tokens through Horizon—introduce latency that compounds at scale if metadata caching and TTLs are not tuned. Delta Direct's ability to read Delta Lake tables as Iceberg avoids the performance penalty of legacy external tables.

Cost optimization for interoperable architectures extends the Cost Optimization pillar with cost dimensions specific to multi-engine and multi-catalog environments. Horizon Catalog API calls are billed as Cloud Services, data movement between engines creates storage and transfer costs, and the choice between Snowflake-managed services and self-managed infrastructure affects total cost of ownership across four dimensions (direct, hidden, opportunity, exit).

The decisions in this section involve tradeoffs that are more context-dependent than a simple table can capture. Use the table as a starting framework, not a prescriptive rulebook. Real-world deployments — particularly those involving multiple vendor platforms or multi-writer Iceberg tables — will encounter nuances not fully represented here.

The following table shows features referenced in this lens and their current availability status. GA items are confirmed available; preview items may have limitations. Status is as of the lens publication date — check Snowflake Release Notes for the latest.

Feature status is tracked in the Feature Status section. Check Snowflake Release Notes for the latest.