Actionable Data Analytics
Join Our Level Up Your Data Email List for Data News Sent to Your Inbox

Mirroring for SQL Server in Microsoft Fabric

Microsoft Fabric continues to evolve as a unified data platform, and one of its most exciting new capabilities is mirroring for SQL Server. This feature allows organizations to replicate transactional data from on-premises SQL Server directly into Microsoft Fabric, eliminating the need for complex pipelines, orchestration, or incremental load processes.

In this guide, you’ll learn what SQL Server mirroring in Fabric means, its key benefits and use cases, how to get started, monitoring options, use cases, and limitations you should be aware of.

Mirroring for SQL Server is a low-cost solution to bring data from various systems into a single platform. It is a replication feature that specializes in data capture, allowing for continuous, real-time movement from SQL Server to OneLake in Microsoft Fabric. Once set up, the SQL Server databases behave like real-time streams that update, insert, and delete data into Fabric automatically without manual intervention.

The mirroring experience is consistent with other sources such as Azure SQL Database, Snowflake, and Databricks. But now, organizations with on-premises SQL Server or VM-based SQL Server can take advantage of the same seamless replication.

Benefits and Advantages of Mirroring for SQL Server

One of the main advantages of Mirroring for SQL Server is the ability to replicate transactional data into Microsoft Fabric seamlessly.

Implementing mirroring for SQL Server offers several benefits and advantages:

  • No pipeline development needed: Avoid building ETL or ELT workflows.
  • Near real-time data availability: Updates flow quickly into Fabric for analytics.
  • Cost efficiency: Mirrored data movement does not consume Fabric capacity units or require additional storage fees beyond included limits.
  • Seamless integration: Replicated data is instantly available for Power BI reporting, data warehousing, and machine learning workloads.

Supported SQL Server Versions

SQL Server mirroring in Fabric supports versions 2016 through 2025, covering the vast majority of enterprise deployments.

This demo guide will use SQL Server 2019. If you’re running the 2016 version or later, you are fully supported.

Prerequisites for Mirroring

Before you begin, ensure the following requirements are met:

  1. SQL Server Agent running – The agent must be active for replication tasks.

  2. On-premises data gateway installed – Required for secure connectivity between SQL Server and Fabric.

  3. Proper access rights – Database users must have sufficient permissions to replicate tables.

  4. Primary keys on tables – Essential for tracking changes during mirroring.

  5. Supported data types – Some SQL Server data types are not compatible with Fabric (details in the limitations section).

For reliability, configure separate gateways for development and production environments, ideally in clustered setups.

How to Configure Mirroring for SQL Server in Microsoft Fabric

Step-by-step outline of mirroring for SQL Server in Fabric:

Set up your SQL Server environment

  • Ensure SQL Server Agent is running.
  • Verify database availability (E.g., AdventureWorks OLTP).

Configure the gateway

  • Install and connect the on-premises data gateway.
  • Allocate sufficient resources to handle initial data seeding.

Connect Fabric to SQL Server

  • In the Microsoft Fabric workspace, select New Item>Mirroring>Mirrored SQL Server (Preview).
  • Enter SQL Server name, database name, and authentication details.
  • Choose the appropriate gateway.

Select tables to replicate

  • By default, all tables appear selected. Only choose those needed for analytics.
  • Tables or unsupported columns will flag an alert, indicating a problem.

Start replication

  • Fabric begins initial seeding. The duration depends on the database size.
  • Tables become available in OneLake for querying and analytics.

Validate replication

  • Query replicated tables in Fabric using T-SQL.
  • Test updates and deletes from SQL Server to confirm mirroring.

Monitoring Mirroring in Fabric

Once replication is active, monitor the data to ensure its integrity and performance. Microsoft Fabric provides two main options:

  1. APIs – Access logs programmatically for troubleshooting.
  2. Workspace monitoring settings – Enable event hub monitoring to stream logs into a real-time analytics database.

Using these tools, you can track:

  • Replication status per table
  • Last sync time
  • Rows updated, inserted, or deleted
  • Errors such as gateway downtime

Power BI dashboards can also surface to help teams stay on the same page by making monitoring data easy to view and share.

Limitations to Consider

While mirroring for SQL Server is powerful, do consider these constraints:

  • All mirrored tables must have primary keys.
  • Certain SQL Server data types are unsupported or cannot be replicated (E.g., SQL_VARIANT, XML, IMAGE, NTEXT).
  • As of now, mirroring is in public preview, with some regional restrictions.
  • Large datasets may consume more time to replicate initially.
  • Deletes may lag and sometimes require more time or manual resync.

Mirroring for SQL Server Use Cases

You can use mirroring for SQL Server in Fabric in particular scenarios:

  1. Operational reporting. Build near-real-time Power BI dashboards directly from mirrored SQL Server data.
  2. Data warehousing. Continuously load SQL Server tables into Fabric’s OneLake as part of your modern analytics platform.
  3. Machine learning and AI. Use transactional SQL Server data as input for predictive models. 
  4. Hybrid cloud strategies. Extend the value of on-premises SQL Server investments without heavy migration costs.

Key Takeaways

The availability of mirroring for SQL Server in Microsoft Fabric is a big step forward for organizations to cost-effectively and quickly integrate their on-premises data with the cloud.

However, only mirror the tables you need for analytics. This keeps replication efficient and avoids unnecessary storage usage.

Conclusion

A direct path into Fabric allows you to mirror databases with minimal setup; you only need to verify that SQL Server Agent and a gateway are functioning. From there, you can funnel your data directly into Fabric, where you can instantly use it for advanced analytics, reporting, and machine learning capabilities.

If your team relies on SQL Server, now is the perfect time to experiment with this feature during its public preview phase. Start small, replicate critical tables, monitor the process, and scale up as you get more comfortable.

Microsoft Fabric still continues to erase the boundary between cloud and on-premises data, and the SQL Server mirrors are the latest step forward in that direction.

Frequently Asked Questions

Question: Can I mirror all SQL Server tables into Fabric?

Answer: While possible, it’s not recommended. For efficiency, only mirror the tables needed for reporting, analytics, or machine learning. Some SQL Server data types are not supported, and tables must include a primary key.

Question: Does mirroring consume Fabric capacity or storage?

Answer: No. Data movement through SQL Server mirroring does not consume Fabric capacity units. Additionally, storage is included—typically 1 TB per capacity unit—so you won’t pay extra unless you exceed your allocation.

Question: How can mirroring issues be troubleshooted?

Answer: Check connection details, firewall settings, and consider rebinding the data source or recreating the mirrored database if necessary.

comment [ 0 ]
share
No tags 0

No Comments Yet.

Do you want to leave a comment?

Your email address will not be published. Required fields are marked *

For security, use of Google's reCAPTCHA service is required which is subject to the Google Privacy Policy and Terms of Use.

I agree to these terms.