Mirroring in Fabric goes public preview: zero-ETL into OneLake, and what to test first

Mirroring for Azure SQL Database, Azure Cosmos DB and Snowflake is now in public preview in Microsoft Fabric. What it does, what it costs, and how to test it properly.

Brian Bønk27 March 20245 min read

Microsoft Fabric Mirroring OneLake Azure SQL Cosmos DB Snowflake

Mirroring in Microsoft Fabric is now in public preview. Announced at Ignite in November 2023 and tested by a group of private preview customers since then, it lets you replicate Azure SQL Database, Azure Cosmos DB and Snowflake into OneLake without building a pipeline. If a large part of your week goes to keeping extract jobs alive, this is worth your attention.

The promise is simple: point Fabric at a source database, choose what to mirror, and the data lands in OneLake as Delta tables that stay in sync in near real time. No ETL code, no scheduling, no staging area to babysit.

That is a big claim. Here is what was actually released, and how I would test it before trusting it with anything important.

What Mirroring does

You create a Mirrored database item in a Fabric workspace and give it connection details for the source. Fabric takes an initial snapshot, then keeps the replica in sync as rows are inserted, updated and deleted, and as tables are created.

Under the hood, replication is built on the source's change data capture technology. For Azure SQL Database, Microsoft describes it as built on the SQL change data capture stack, but optimised for a lake-centric design: mirroring reads changes from the database transaction log and publishes them to OneLake, where they become Delta tables.

Every mirrored database also gets a SQL analytics endpoint. That means you can query the replica with T-SQL in the Fabric editor, use the visual query editor, and join it with warehouses, lakehouses and other mirrored databases in the same query. You can shortcut it into a lakehouse for notebooks, and build Power BI semantic models in Direct Lake mode on top of it.

The point is one copy of the data in an open format, readable by every Fabric engine.

What is supported in the preview

Three sources are in the public preview:

Azure SQL Database.
Azure Cosmos DB, currently for the NoSQL API only, and it requires continuous backup to be enabled on the account.
Snowflake, for customers on any cloud.

At Ignite, Microsoft also said that SQL Server, Azure PostgreSQL, Azure MySQL, MongoDB and others would follow during 2024. None of those are part of this release, so do not plan around them yet.

A Fabric administrator has to turn on the tenant setting for Mirroring before anyone can create a mirrored database. It can be enabled for the whole organisation, specific groups or specific users.

The cost model is the interesting part

Microsoft states that the compute used to replicate data into OneLake is free and does not consume your capacity. Storage for the replicas is also free up to a limit tied to capacity size. The example given: an F2 capacity includes 2 TB of storage set aside for mirroring. You pay for OneLake storage if you go above that limit or pause the capacity.

Querying is a different matter. When you query mirrored data through the SQL endpoint, a lakehouse, Power BI or notebooks, normal capacity charges apply.

For Cosmos DB there are a few extra lines in the bill to understand. If you already have continuous backup enabled, there is no extra cost. If you enable it only for mirroring, you pay for that backup feature. And if you browse the source through the Cosmos DB data explorer inside Fabric, that consumes request units on the source account.

What this means for you

After two decades in data, I have seen plenty of "no more ETL" announcements. The useful question is not whether Mirroring removes ETL. It is which of your ETL jobs are just copying tables, because those are the ones Mirroring can replace. The transformations, business rules and modelling still need a home.

Microsoft is clear on one thing, and I would take it seriously: the Cosmos DB team says that during the preview, mirroring only supports non-production workloads. If you run Azure Synapse Link for Cosmos DB in production, keep it. You can run both on the same containers while you test.

A practical way to test the preview:

Ask your Fabric admin to enable the Mirroring tenant setting for a small test group.
Pick one non-production source with a realistic change pattern, not an empty demo database.
Mirror a handful of tables and check which ones are eligible, and why some are not.
Measure latency yourself. Insert, update and delete rows in the source and time how long until the change is visible through the SQL endpoint.
Watch the source side. For Azure SQL Database, the documented checks are sp_help_change_feed for table state, sys.dm_change_feed_log_scan_sessions for progress and sys.dm_change_feed_errors for problems.
Build one Direct Lake report on the mirrored tables and compare numbers with your existing pipeline output.
Track capacity usage from queries, since replication is free but reading is not.

Step four and step six are where you learn the most. If latency is acceptable and the numbers match, you have a real candidate for retiring a copy job. If not, you have spent a few hours, not a quarter.

Also read the limitations page for each source before you start. A preview is the right time to find the table types, data types and configurations that are not supported, and it is much cheaper to find them in a test than after a design decision.

Takeaway

Mirroring is the clearest expression yet of the OneLake idea: one copy of the data, in Delta, used by every engine. The preview covers three sources, replication compute is free, and the setup really is a few clicks. Treat it as something to test properly now, and not as a production replacement until it reaches general availability.

Which of your current pipelines is only copying tables, and would you trust Mirroring to take over that job?

Sources

Enjoyed this? Get the next one by email

Occasional emails about Microsoft Fabric, SQL Server, Power BI and Synapse.