Mirroring Snowflake in Microsoft Fabric

Mirroring in Fabric provides an easy experience to avoid complex ETL (Extract Transform Load) and integrate your existing Snowflake warehouse data with the rest of your data in Microsoft Fabric. You can continuously replicate your existing Snowflake data directly into Fabric's OneLake. Inside Fabric, you can unlock powerful business intelligence, artificial intelligence, Data Engineering, Data Science, and data sharing scenarios.

For a tutorial on configuring your Snowflake database for Mirroring in Fabric, see Tutorial: Configure Microsoft Fabric mirrored databases from Snowflake.

Why use Mirroring in Fabric?

With Mirroring in Fabric, you don't need to piece together different services from multiple vendors. Instead, you can enjoy a highly integrated, end-to-end, and easy-to-use product that is designed to simplify your analytics needs, and built for openness and collaboration between Microsoft, Snowflake, and the 1000s of technology solutions that can read the open-source Delta Lake table format.

What analytics experiences are built in?

Mirrored databases are an item in Fabric Data Warehousing distinct from the Warehouse and SQL analytics endpoint.

Mirroring creates these items in your Fabric workspace:

• The mirrored database item. This enables downstream scenarios like data engineering, data science, and more. Mirroring manages:
  • The replication of managed table and view data into OneLake and conversion to Parquet, in an analytics-ready format.
  • The replication of Iceberg table metadata into OneLake using shortcuts to and conversion to the storage that contains your Iceberg tables. OneLake automatically converts these Iceberg tables to Delta Lake formatted tables for use across Fabric workloads.
• A SQL analytics endpoint

Each mirrored database has an autogenerated SQL analytics endpoint that provides a rich analytical experience on top of the Delta Tables created by the mirroring process. Users have access to familiar T-SQL commands that can define and query data objects but not manipulate the data from the SQL analytics endpoint, as it's a read-only copy. You can perform the following actions in the SQL analytics endpoint:

• Explore the tables that reference data in your Delta Lake tables from Snowflake.
• Create no code queries and views and explore data visually without writing a line of code.
• Develop SQL views, inline TVFs (Table-valued Functions), and stored procedures to encapsulate your semantics and business logic in T-SQL.
• Manage permissions on the objects.
• Query data in other Warehouses and Lakehouses in the same workspace.

In addition to the SQL query editor, there's a broad ecosystem of tooling that can query the SQL analytics endpoint, including SQL Server Management Studio (SSMS), the MSSQL extension for Visual Studio Code, and even GitHub Copilot.

Supported Snowflake object types

The following table lists which Snowflake object types are supported for mirroring:

Security considerations

To enable Fabric mirroring, you will need user permissions for your Snowflake database that contains the following permissions:

• CREATE STREAM
• SELECT table
• SHOW tables
• DESCRIBE tables

For more information, see Snowflake documentation on Access Control Privileges for Streaming tables and Required Permissions for Streams.

Supported authentication methods

The following table lists which authentication methods are supported for mirroring for Snowflake:

Mirroring Snowflake behind firewall

Check the networking requirements to access your Snowflake data source. If your Snowflake data source is not publicly accessible and is within a private network, create a virtual network data gateway or install an on-premises data gateway to mirror the data. The Azure Virtual Network or the gateway machine's network must connect to the Snowflake instance via a private endpoint or be allowed by the firewall rule. To get started, see Tutorial: Configure Microsoft Fabric mirrored databases from Snowflake.

Private Link and workspace identity:

• Private Link: Direct Private Link connectivity between a Fabric workspace and Snowflake isn't yet supported. In the interim, use a virtual network data gateway or on-premises data gateway for private connectivity.
• Workspace identity: Workspace identity authentication isn't currently supported for Snowflake mirroring.

Mirrored Snowflake cost considerations

Fabric compute used to replicate your data into Fabric OneLake is free. The Mirroring storage cost is free up to a limit based on capacity. For more information, see Cost of mirroring and Microsoft Fabric Pricing. The compute for querying data using SQL, Power BI, or Spark is charged at regular rates.

Fabric doesn't charge for network data ingress fees into OneLake for Mirroring.

There are Snowflake compute and cloud query costs when data is being mirrored: virtual warehouse compute and cloud services compute.

• Snowflake virtual warehouse compute charges:
  • Compute charges will be charged on the Snowflake side if there are data changes that are being read in Snowflake, and in turn are being mirrored into Fabric.
  • Any metadata queries run behind the scenes to check for data changes are not charged for any Snowflake compute; however, queries that do produce data such as a SELECT * will wake up the Snowflake warehouse and compute will be charged.
• Snowflake services compute charges:
  • Although there aren't any compute charges for behind the scenes tasks such as authoring, metadata queries, access control, showing data changes, and even DDL queries, there are cloud costs associated with these queries.
  • Depending on what type of Snowflake edition you have, you will be charged for the corresponding credits for any cloud services costs.

In the following screenshot, you can see the virtual warehouse compute and cloud services compute costs for the associated Snowflake database that is being mirrored into Fabric. In this scenario, majority of the cloud services compute costs (in yellow) are coming from data change queries based on the points mentioned previously. The virtual warehouse compute charges (in blue) are coming strictly from the data changes are being read from Snowflake and mirrored into Fabric.

Cost optimization recommendations

To minimize Snowflake compute costs from mirroring, consider the following best practices:

• Reuse an existing warehouse. Instead of creating a dedicated warehouse for mirroring, configure mirroring to use the same warehouse that your applications already use to update the source tables. This approach avoids unnecessary warehouse wake-up and auto-suspend cycles. When your application updates a table, the mirroring replicator picks up changes almost immediately while the warehouse is still active, so you don't need to wake a separate warehouse. Some organizations might prefer a dedicated warehouse for budget isolation. This preference is a trade-off between cost savings and budgeting granularity.
• Mirror only the tables you need. Mirroring an entire database can cause unexpectedly high Snowflake consumption and Fabric capacity spikes. Start by selecting only the tables required for your analytics scenarios. You can add tables later as needed.
• Monitor for unexpected reseeds. A reseed (full data reload) processes the entire table and incurs compute cost proportional to the table size. Schema changes - including those triggered by tools such as DBT - can cause continuous reseeds. Monitor the Mirroring Status page for tables that show repeated initial-copy behavior, and review the Reseeding section below for triggers and troubleshooting guidance.
• Be aware that mirroring runs continuously. Mirroring doesn't currently support scheduling or replication windows. The replicator continuously polls for changes, which generates ongoing Snowflake compute usage. Plan your Snowflake budgets accordingly.

For more information of Snowflake specific cloud query costs, see Snowflake docs: Understanding overall cost.

Next step

Related content

• How to: Secure data Microsoft Fabric mirrored databases from Snowflake
• Monitor Fabric mirrored database replication