Snowflake to Microsoft Fabric: Mirror, Migrate or Keep Both for Reporting Dashboards
Snowflake data reaches OneLake through mirroring or Iceberg shortcuts and feeds Power BI reporting dashboards.
Snowflake to Microsoft Fabric is a question many data leaders now face, and the answer is not always a migration. Teams that run Snowflake as their warehouse often find that most of their business users already work in Power BI and Microsoft 365, and ask whether Fabric should replace Snowflake, sit beside it, or simply feed the reporting dashboards. Each answer is right for some organizations and wrong for others.
This guide is for CDOs, data platform owners and analytics leaders. It sets out the three realistic paths, how Fabric mirroring works and what it costs on the Snowflake side, how Iceberg lets both platforms share one copy of data, and the governance decisions to settle before you commit.
Why Teams Compare Snowflake and Microsoft Fabric
The comparison usually starts with spend or duplication. Data is loaded into Snowflake, copied into Power BI models, and sometimes copied again for other tools, so teams pay to store and move the same data several times. At the same time, Fabric offers storage, pipelines, a warehouse and Power BI under one capacity, which makes consolidation look attractive.
Consolidation is a legitimate goal, but it is not the only one. Many organizations value Snowflake for workloads it already runs well and want Fabric mainly for reporting and Microsoft integration. A good decision starts from workloads and cost, not from vendor preference.
Where Snowflake Reporting Costs and Complexity Add Up
Power BI connects to Snowflake in Import or DirectQuery mode. Import copies data into the semantic model on a refresh schedule. DirectQuery sends each report query to Snowflake, so heavy reporting usage can translate directly into warehouse compute, which makes cost harder to predict as more people use more dashboards.
Complexity builds in other ways. Authentication, gateways and connector versions need care, definitions can drift between semantic models, and several teams may build overlapping reports on the same tables. A governed reporting layer helps most when the same Snowflake data feeds many dashboards.
Snowflake to Microsoft Fabric: Mirror, Interoperate or Migrate
There are four practical patterns, and organizations often combine them. We help clients compare them on workload fit and cost before recommending one.
| Path | When it fits | Check first |
|---|---|---|
| Mirroring into OneLake | Snowflake stays the system of record and you want its data in Fabric for Power BI and other workloads | Which tables, Snowflake compute cost, continuous replication, security rebuilt in Fabric |
| Iceberg interoperability and shortcuts | Data is, or can be, in Iceberg and both engines should use one copy | Storage connection, matching Azure region, network limits, current feature status |
| Power BI directly on Snowflake | Reporting needs are modest and few sources are involved | Warehouse cost per query, authentication, DirectQuery limits |
| Full migration to Fabric | You are consolidating on Microsoft and the workloads fit Fabric | SQL and pipeline rewrite, data sharing and dependencies, governance rebuild |
Our Microsoft Fabric migration work covers the full move when it is the right call. When it is not, mirroring or Iceberg usually delivers the reporting benefit with far less disruption.
How Snowflake to Microsoft Fabric Mirroring Works
Microsoft documents mirroring Snowflake as continuous replication of managed tables and views into OneLake, stored in an analytics-ready format with a SQL analytics endpoint on top. Iceberg tables can also be mirrored through a storage connection. Views and materialized views sync every 12 hours, and external, transient, temporary and dynamic tables are not supported.
Fabric does not charge compute for replication, and mirroring storage is free up to a limit based on capacity, but Snowflake does charge for the compute and cloud services used to read changes. Microsoft recommends mirroring only the tables you need, reusing an existing warehouse, and watching for reseeds, since schema changes from tools such as dbt can trigger full reloads. Mirroring runs continuously and cannot yet be scheduled, so plan Snowflake budgets accordingly.
Setup needs specific Snowflake permissions, and Private Link between a Fabric workspace and Snowflake is not yet supported, so private networks use a data gateway. Any granular security from Snowflake must be rebuilt in the mirrored database in Fabric.
- Snowflake to Microsoft Fabric is not always a migration. Mirroring, Iceberg sharing and direct Power BI connections are real alternatives.
- Decide by workload and cost, and count how many times the same data is copied and queried.
- Mirroring is free to replicate on the Fabric side but uses Snowflake compute, so mirror only the tables you need.
- Security does not carry across. Rebuild granular permissions in Fabric and keep one definition of each measure.
- Pilot one reporting dashboard on a handful of tables, compare Snowflake and Fabric costs, then decide.
Iceberg, OneLake and Keeping Both Platforms
Apache Iceberg gives the two platforms a shared format. Microsoft documents Snowflake on Azure writing Iceberg tables directly to OneLake, and Fabric reading Iceberg tables through a shortcut so they appear as Delta tables across Fabric workloads. Snowflake can also read Delta tables in Fabric as virtual Iceberg tables. The result is one copy of the data used by both engines.
There are limits to check. The Fabric capacity must be in the same Azure region as the Snowflake account, Snowflake reaches OneLake over the public network, and workspaces protected by private link are not yet supported. Microsoft also describes some parts of this integration as preview, so confirm current status before relying on it for production reporting.
Security, Cost Control and Reporting Governance
Running two platforms means two permission models. Decide where row-level and column-level security lives, keep sensitive data out of copies that do not need it, and make one team accountable for the definitions that dashboards use. Track Snowflake credits and Fabric capacity side by side so cost decisions rest on evidence.
Our data governance consulting work and the Power BI Governance Platform keep reporting consistent as more teams build on the same data.
Snowflake to Microsoft Fabric: What to Build First
Start with a pilot. Pick one reporting dashboard that matters, identify the five to ten Snowflake tables behind it, and try mirroring or an Iceberg shortcut for those tables only. Measure Snowflake credit use and Fabric capacity, check that definitions match, and use the results to decide how far to go. Our Power BI consulting team designs the semantic models and dashboards on top.
Numlytics is Snowflake certified and builds on Microsoft Fabric, so we are not tied to one outcome. Whether you need a Snowflake implementation, a Fabric platform or both working together, speak with a certified consultant to map your workloads and choose the path that fits.