Frequently asked questions for Mirroring Snowflake in Microsoft Fabric

This article answers frequently asked questions about Mirroring Snowflake in Microsoft Fabric.

Features and capabilities

Is there a staging or landing zone for Snowflake? If so, is it outside of OneLake?

For Snowflake, we do use a landing zone to store both the snapshot and change data into OneLake, to improve performance as we're converting these files in the landing zones into delta vertiparquet.

What Snowflake object types can be replicated?

Managed tables, Iceberg tables, and views are supported for replication. External, transient, temporary, and dynamic tables are not supported. For Iceberg tables, a storage connection to the underlying Iceberg table storage is required during configuration. For details on known issues with views (such as data type mapping), see Limitations.

How do I manage connections?

Select the settings cog, then select on Manage connection and gateways. You can also delete existing connections from this page.

What authentication methods are supported for Snowflake mirroring?

The following authentication methods are supported:

• Username and password — Snowflake native authentication
• Microsoft Entra ID (SSO) — Single sign-on via Entra ID
• Key pair authentication — RSA key pair for service account scenarios

Cost efficiency

How can I reduce Snowflake compute costs from mirroring?

1. Reuse an existing warehouse. Configure mirroring to use the same Snowflake warehouse that your applications already use to update the source tables. This avoids the overhead of waking up a separate, dedicated mirroring warehouse. When your application updates a table, the mirroring replicator picks up changes almost immediately while the warehouse is still active. 2. Mirror only the tables you need. Avoid mirroring an entire database when you only need a subset of tables. Large-scale mirroring can cause significant Snowflake consumption and Fabric capacity spikes. 3. Monitor for unexpected reseeds. A reseed re-reads the full table and incurs compute cost proportional to its size. Check the Mirroring Status page for tables that repeatedly show initial-copy behavior. 4. Use Snowflake budgets and credit limits. Set Snowflake resource monitors and budgets to cap mirroring-related compute costs.

How are ingress fees handled?

Fabric doesn't charge for Ingress fees into OneLake for Mirroring.

How are egress fees handled?

If hosted outside of Azure, refer to Snowflake and your cloud documentation for egress costs. If hosted in Azure but in a different region from your Fabric capacity, data egress will be charged. If hosted in Azure in the same region, there is no data egress.

Does mirroring support scheduling or replication windows?

No. Mirroring runs continuously and does not currently support configuring replication schedules or time-based windows. The replicator polls for changes on an ongoing basis, which generates continuous Snowflake compute usage. If you need to limit compute during certain periods, you can manually stop and restart mirroring — but note that restarting triggers a full reseed of all mirrored tables.

Performance

How long does the initial replication take?

It depends on the size of the data that is being brought in.

How long does it take to replicate inserts/updates/deletes?

Near real-time latency.

Will the Power BI reports use direct lake mode?

Yes, tables are all v-ordered delta tables.

Troubleshoot Mirroring Snowflake in Microsoft Fabric

What are the replication statuses?

See Monitor Fabric Mirror replication.

Can Snowflake Mirroring be accessed through the Power BI Gateway or behind a firewall?

Yes, we support mirroring through an On-premises data gateway and through a Virtual Network (VNet) Data Gateway.

What does starting the Mirroring do?

The data from source tables will be reinitialized. Each time you stop and start, the entire table is fetched again.

What happens if I deselect a table from Mirroring?

We stop Mirroring that specific table and delete it from OneLake.

If I delete the Mirror does it affect the source mirrored database?

No, we just remove the streaming tables.

Can I Mirror the same database multiple times?

Yes, you can, but you shouldn't need to. Once the data is in Fabric, it can be shared from there.

Can I Mirror specific tables from my source database?

Yes, specific tables can be selected during Mirroring configuration.

What triggers a full reseed?

A reseed (full data reload) is triggered by any of the following:

• DDL changes that modify the DDL timestamp of a table, for example, ALTER TABLE operations that add or drop columns.
• Schema modification tools such as dbt that drop and recreate tables on a schedule.
• Stopping and restarting mirroring through the Fabric portal or API.
• An extended capacity pause. If Fabric capacity is paused for a long period, mirroring might reseed when resumed.

How do I troubleshoot unexpected or continuous reseeding?

If you see tables repeatedly going through initial copy (reseed) instead of incremental sync:

1. Check for upstream schema changes. Verify whether a tool such as dbt is modifying table definitions on a recurring schedule. Even minor DDL changes can trigger a reseed.
2. Review the Mirroring Status page. Look for tables that show repeated initial-copy timestamps at regular intervals.
3. Pause schema changes during active mirroring. If dbt runs are the cause, schedule them during maintenance windows, or pause mirroring before running schema changes.
4. Monitor Snowflake warehouse usage. Check Snowflake account usage views to see whether mirroring-related queries are dominating compute.
5. Remember that each reseed processes the full table data and incurs Snowflake compute cost proportional to table size. proportional to the table size.

Data governance

Is data ever leaving the customers Fabric tenant?

No.

Is data staged outside of a customer environment?

No, data isn't staged outside of customer environment, it's staged in the customer's OneLake.

Licensing

What are licensing options for Fabric Mirroring?

A Power BI Premium, Fabric Capacity, or Trial Capacity is required. For more information on licensing, see Microsoft Fabric licenses.

What are the Fabric compute costs associated with Mirroring?

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.

Related content

• What is Mirroring in Fabric?
• Snowflake connector overview

This article answers frequently asked questions about Mirroring Snowflake in Microsoft Fabric.

For Snowflake, we do use a landing zone to store both the snapshot and change data into OneLake, to improve performance as we're converting these files in the landing zones into delta vertiparquet.

Managed tables, Iceberg tables, and views are supported for replication. External, transient, temporary, and dynamic tables are not supported. For Iceberg tables, a storage connection to the underlying Iceberg table storage is required during configuration. For details on known issues with views (such as data type mapping), see Limitations.

Select the settings cog, then select on Manage connection and gateways. You can also delete existing connections from this page.

The following authentication methods are supported:

• Username and password — Snowflake native authentication
• Microsoft Entra ID (SSO) — Single sign-on via Entra ID
• Key pair authentication — RSA key pair for service account scenarios

1. Reuse an existing warehouse. Configure mirroring to use the same Snowflake warehouse that your applications already use to update the source tables. This avoids the overhead of waking up a separate, dedicated mirroring warehouse. When your application updates a table, the mirroring replicator picks up changes almost immediately while the warehouse is still active. 2. Mirror only the tables you need. Avoid mirroring an entire database when you only need a subset of tables. Large-scale mirroring can cause significant Snowflake consumption and Fabric capacity spikes. 3. Monitor for unexpected reseeds. A reseed re-reads the full table and incurs compute cost proportional to its size. Check the Mirroring Status page for tables that repeatedly show initial-copy behavior. 4. Use Snowflake budgets and credit limits. Set Snowflake resource monitors and budgets to cap mirroring-related compute costs.

Fabric doesn't charge for Ingress fees into OneLake for Mirroring.

If hosted outside of Azure, refer to Snowflake and your cloud documentation for egress costs. If hosted in Azure but in a different region from your Fabric capacity, data egress will be charged. If hosted in Azure in the same region, there is no data egress.

No. Mirroring runs continuously and does not currently support configuring replication schedules or time-based windows. The replicator polls for changes on an ongoing basis, which generates continuous Snowflake compute usage. If you need to limit compute during certain periods, you can manually stop and restart mirroring — but note that restarting triggers a full reseed of all mirrored tables.

It depends on the size of the data that is being brought in.

Near real-time latency.

Yes, tables are all v-ordered delta tables.

See Monitor Fabric Mirror replication.

Yes, we support mirroring through an On-premises data gateway and through a Virtual Network (VNet) Data Gateway.

The data from source tables will be reinitialized. Each time you stop and start, the entire table is fetched again.

We stop Mirroring that specific table and delete it from OneLake.

No, we just remove the streaming tables.

Yes, you can, but you shouldn't need to. Once the data is in Fabric, it can be shared from there.

Yes, specific tables can be selected during Mirroring configuration.

A reseed (full data reload) is triggered by any of the following:

• DDL changes that modify the DDL timestamp of a table, for example, ALTER TABLE operations that add or drop columns.
• Schema modification tools such as dbt that drop and recreate tables on a schedule.
• Stopping and restarting mirroring through the Fabric portal or API.
• An extended capacity pause. If Fabric capacity is paused for a long period, mirroring might reseed when resumed.

If you see tables repeatedly going through initial copy (reseed) instead of incremental sync:

1. Check for upstream schema changes. Verify whether a tool such as dbt is modifying table definitions on a recurring schedule. Even minor DDL changes can trigger a reseed.
2. Review the Mirroring Status page. Look for tables that show repeated initial-copy timestamps at regular intervals.
3. Pause schema changes during active mirroring. If dbt runs are the cause, schedule them during maintenance windows, or pause mirroring before running schema changes.
4. Monitor Snowflake warehouse usage. Check Snowflake account usage views to see whether mirroring-related queries are dominating compute.
5. Remember that each reseed processes the full table data and incurs Snowflake compute cost proportional to table size. proportional to the table size.

No.

No, data isn't staged outside of customer environment, it's staged in the customer's OneLake.

A Power BI Premium, Fabric Capacity, or Trial Capacity is required. For more information on licensing, see Microsoft Fabric licenses.

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.

Related content

• What is Mirroring in Fabric?
• Snowflake connector overview