Organizations increasingly want Snowflake and Microsoft Fabric to coexist without duplicating data or fragmenting governance. With Fabric OneLake and open table formats like Iceberg and Delta, there are now multiple ways to make Snowflake data available inside Fabric—each with different tradeoffs around cost, performance, and ownership.

This post walks through three practical architectures for using Snowflake data in Fabric OneLake, when each option makes sense, and the key tradeoffs to consider.

The most important decision across all three options is which platform is the system of record and primary writer—most tradeoffs flow directly from that choice.

1) Snowflake-managed Iceberg table + OneLake shortcut

In this pattern, Snowflake reads and writes an Iceberg table stored in external object storage such as ADLS or S3 (instead of Snowflake-native tables). Microsoft Fabric does not copy the data; instead, Fabric creates a OneLake shortcut to the Iceberg table’s storage location so Fabric engines can query the data in place. Snowflake remains the system of record and the primary writer.

This option is best when you already have Iceberg tables managed by Snowflake and want zero data duplication while still enabling Fabric analytics. The tradeoff is that Fabric access is largely read-oriented, and the experience is less native than using Delta format (how everything is stored in OneLake) in terms of table discovery and management.

From a cost perspective, you pay for Snowflake compute to create and maintain the Iceberg tables and for Fabric compute when querying the data. You do not pay for OneLake storage, ingestion pipelines, or replication. Any additional cost depends on where the external storage lives and whether cross-service or cross-region reads apply.

When to use this option

• You already have Snowflake-managed Iceberg tables in external object storage
• Snowflake must remain the system of record and primary writer
• You want zero data duplication and minimal architectural change
• Fabric is used mainly for read-only analytics or exploration

When to avoid this option

• You want Power BI Direct Lake with a fully native Delta experience, rather than Direct Lake enabled via Iceberg→Delta virtualization
• You expect Fabric to write to, optimize, or manage the tables natively (for example, Delta optimization, compaction, or schema evolution owned by Fabric)
• You want first-class table discovery, governance, and lifecycle management that aligns fully with Fabric-native Delta tables

One-line summary:

Best for quick, low-friction access to existing Snowflake Iceberg data with minimal change, but limited Fabric-native capabilities.

More info: Unify data sources with OneLake shortcuts – Microsoft Fabric | Microsoft Learn

2) Snowflake writes Iceberg tables directly into OneLake

In this model, Snowflake is configured to write Iceberg tables directly into OneLake, creating a single shared physical copy of the data that both Snowflake and Fabric can access. No shortcut and no replication are required, and Fabric works directly against the Iceberg data where it lives.

This is the cleanest long-term architecture for open table interoperability, assuming current Iceberg support in OneLake meets your needs and Snowflake remains the primary writer (or you are comfortable defining shared write semantics).

Cost-wise, you pay for Snowflake compute to write and maintain the Iceberg tables and for Fabric compute to run analytics workloads. You do not pay for duplicate storage, replication, or ingestion jobs. This is often the most cost-efficient option at scale when both platforms need access to the same data.

When to use this option

• You want a single shared physical copy of data across Snowflake and Fabric
• Snowflake remains the primary writer, but Fabric needs deep analytical access
• You are intentionally adopting open table formats for long-term interoperability
• You want to minimize storage duplication and ongoing data movement costs

When to avoid this option

• You need Fabric-native Delta features (such as Direct Lake without relying on Iceberg→Delta virtualization)
• You want Fabric to be the primary write, optimization, and lifecycle management engine
• Your organization is not ready to clearly define write ownership, schema evolution, and conflict resolution between Snowflake and Fabric

One-line summary:

Best long-term architecture for shared analytics using open table formats, with strong cost efficiency and clean data ownership.

More info: Use Snowflake with Iceberg tables in OneLake – Microsoft Fabric | Microsoft Learn, Building an Iceberg Lakehouse with Snowflake and Microsoft OneLake

3) Fabric mirroring from Snowflake to OneLake (Delta format)

With mirroring, Fabric continuously replicates Snowflake tables into OneLake and stores them as Delta tables, delivering the most seamless Fabric-native experience across Lakehouse, Warehouse, Power BI Direct Lake, and AI workloads.

This option is ideal when you want maximum simplicity and performance inside Fabric and are comfortable with Snowflake no longer being the primary analytics engine for those datasets.

From a cost standpoint, you pay for Snowflake compute and cloud services to read source tables and capture changes, and you pay for Fabric capacity to perform replication, optimization, and downstream analytics. You do not pay for OneLake storage for the mirrored data (the mirroring storage cost is free up to a limit based on capacity – for more information, see Cost of mirroring and Microsoft Fabric Pricing), nor do you pay for building or operating ingestion pipelines. While storage is effectively free in OneLake, mirroring is typically the most compute-intensive option.

When to use this option

• You want the most seamless, high-performance Fabric experience
• Power BI Direct Lake, Warehouse, and AI workloads are top priorities
• Fabric will be the primary analytics platform going forward
• You prefer simplicity over shared-write complexity

When to avoid this option

• Snowflake must remain the primary analytics engine
• You want to avoid continuous replication compute costs
• You are standardizing on open formats like Iceberg across platforms

One-line summary:

Best for Fabric-first analytics teams that want maximum performance and simplicity, at the cost of higher compute usage.

More info: Microsoft Fabric Mirrored Databases From Snowflake – Microsoft Fabric | Microsoft Learn, Tutorial: Configure a Microsoft Fabric Mirrored Database From Snowflake – Microsoft Fabric | Microsoft Learn

Summary comparison table

Dimension	Snowflake-managed Iceberg + Shortcut	Snowflake writes Iceberg to OneLake	Fabric Mirroring (Delta)
Primary writer	Snowflake	Snowflake	Fabric
Physical data duplication	❌ None (shared external storage)	❌ None (shared OneLake storage)	✅ Yes (replicated into OneLake)
Format in OneLake	Iceberg	Iceberg	Delta
Fabric experience	Read-oriented, less native	Good, improving	⭐ Best / most native
Power BI Direct Lake	⚠️ Supported via OneLake Iceberg→Delta virtualization*	⚠️ Supported via OneLake Iceberg→Delta virtualization*	✅ Supported (native Delta)
Ongoing sync	Manual / external	Native (shared)	Automatic (CDC-based)
Separate storage charges	Yes (external storage)	❌ No (included with Fabric capacity)	❌ No (included with Fabric capacity)
Compute cost	Snowflake + Fabric	Snowflake + Fabric	Snowflake + Fabric (highest)
Best for	Minimal change, zero-copy	Long-term open architecture	Fabric-first analytics

*Direct Lake support for Iceberg relies on OneLake’s ability to surface the table as Delta, which may not be guaranteed for all Iceberg configurations or evolution patterns (more info).

Iceberg support in OneLake is evolving quickly, and the gap between Iceberg and Delta experiences in Fabric is narrowing. Over time, Option 2 becomes increasingly attractive as a long-term, open-table architecture—while mirroring remains the fastest path to a fully Fabric-native experience today.