The Problem Mirroring Solves
One of the biggest challenges in today's modern data platforms isn't building reports or dashboards. It's efficiently moving data from source systems to analytical environments.
Organizations often spend a significant amount of time building, monitoring, and scheduling data pipelines to handle the ingestion process. These pipelines take time to manage, they can fail, and they often need a lot of maintenance.
Microsoft Fabric Mirroring takes a different approach. Instead of constantly extracting and loading data, mirroring loads the destination with the data only once. After that, a sync is established between the source and the destination and whenever the source changes, that change is reflected on the destination.
From a business perspective, that means engineering teams can spend less time on pipeline ingestion and more time providing value through analytics. It also means data becomes available much faster for data analysts, data engineers, and business users.
It's important to understand that mirroring doesn't replace data engineering. You still need modeling, transformation, cleansing, and business logic. What mirroring does is take away the challenging part: landing the data into Microsoft Fabric in a simple and efficient way.
In this demo, I'll show you how to mirror an Azure SQL Database onto Fabric, how it works, and what business value it can provide. Let's get started.
Setting Up the Source Database
For this demo, we've provisioned an Azure SQL Database called AdventureWorks2022, using the same sample data from AdventureWorks. This will be the source operational database that gets mirrored onto the Fabric destination.
Here's a quick overview of how everything is set up on the source side:
- Pricing tier: This is a very important setting. The database must be at minimum a Standard S3, 100 database transaction units (DTUs) for mirroring onto Fabric to work.
- Storage: Configured with 100 DTUs and 2 GB of storage.
- Cost: The payment plan comes out to $161 USD per month.
Setting Up the Mirrored Database in Fabric
On the Fabric side, I've created a workspace called Azure Source Database Mirrored, where I'll actually create the mirrored database.
- Search for "mirrored Azure" — you'll see a number of different database options.
- Select Mirrored Azure SQL Database, since we want the source to be an Azure SQL Database.
- Enter the connection string settings. You only need the server name & database name.
- Enter your credentials.
This is the final step of the initial setup process to land the data. From here, Fabric loads and tries to find all the tables you want to replicate.
Selecting Tables and Handling Data Type Errors
We selected all tables, since we want to replicate the whole database. At this point, you may see some errors — these are typically related to data types:
- XML data type: Not currently supported in Fabric.
- NVARCHAR in a primary key column: Also not currently supported in Fabric. When this happens, that column will be excluded entirely.
Landing the Data
Once you connect, you can name the mirrored database so you can tell the difference between the source and the mirror. From here, the initial landing of data begins and you'll need to wait a few minutes.
Here's what makes this approach different: normally, an ingestion process like this would require pipelines, dataflows, notebooks, copy activities — all sorts of activities to move data from one system to another. With mirroring, that's not a factor. We're simply replicating the data, and the source system and Fabric communicate via the SQL Server transaction log.
After the initial data landing, Fabric only looks at the transaction log going forward. So every time something changes in SQL Server (or Azure SQL Database, or whatever source you're using), it's immediately reflected on the destination in Fabric.
While this is running, you'll see a status view showing:
- Table name
- Status (e.g., running)
- Rows replicated
- Rows completed
- Delayed rows
"Rows replicated" simply tells you how many rows have synced — it should match exactly between the source and the destination.
Testing the Replication
Once loading finished, the rows had been fully replicated, and it only took about two minutes, which is pretty good.
To actually verify what's happening on the mirrored Fabric side, you need to go to the SQL Analytics endpoint, rather than just relying on row counts.
Here's how the test went:
- Source side: We tested the CountryRegionCurrency table, which has 3 fields and 109 rows.
- Fabric (mirrored) side: The same table should show the same 3 fields and the same 109 rows.
And that's exactly what happened.
Testing a Schema Change
A further capability that really stands out with mirroring is how it handles schema changes. Let's say a column is added on the source — for example, in an ERP system — and the schema changes. In our test, we added a new column to the source and populated it with values.
Depending on what changes in the source database (or the ERP, or whatever system you're using), it should reflect automatically on the Fabric side.
A few things to note about timing:
- Inserts, updates, and deletes usually sync much faster than schema changes.
- A schema change should still complete in roughly a minute.
In our test, after about a minute, the change had been reflected: the new field appeared with the values we'd populated in the source. This shows that replication works very well and is quite fast — only about a minute for schema changes.
Why Fabric Mirroring Stands Out
This demo shows why Fabric mirroring is so simple, easy to use, and such a powerful tool. It removes the overhead of building and maintaining ingestion pipelines while keeping your Fabric destination continuously in sync with your source — whether that's a simple data change or a full schema update.
I hope this gave you a better understanding of how Microsoft Fabric Mirroring works and what kind of business value it can bring to modern data platforms.
If you have any suggestions or questions, please write them in the comments. Thank you for reading!