In Short: Replication as a Feature, Not a Project
Mirroring is Fabric's answer to the oldest chore in analytics: getting operational data out of the systems that run the business and into the platform that analyses it. Point Fabric at a supported database - Azure SQL, Cosmos DB, Snowflake, an Azure Databricks Unity Catalog - and it maintains a continuously updated replica in OneLake as Delta tables, query-ready for every Fabric engine within moments of changes landing at the source.
What used to be an ingestion project - CDC configuration, pipelines, schedules, failure alerts - becomes a configuration screen. That is the promise, and for the supported sources it substantially holds.
How It Works, Briefly
Mirroring consumes the source's change feed rather than repeatedly querying tables, lands an initial snapshot, then applies inserts, updates and deletes continuously to Delta tables in OneLake. From there the data behaves like any other OneLake content: the SQL endpoint queries it, notebooks read it, Power BI can serve it through Direct Lake, and downstream medallion layers build on it.
Because replication reads changes, source impact stays modest, and freshness is near real time rather than the nightly batch that made "as of yesterday" the default caveat on every dashboard.
Open mirroring extends the pattern beyond the built-in sources: any system that can write change files in the open format can feed a mirrored database, which is how ISVs and niche sources join without waiting for a first-party connector.
Where Mirroring Beats the Alternatives
- Versus batch pipelines - no authoring, no schedule gaps, no 2am failure emails; the freshest data with the least engineering
- Versus shortcuts - shortcuts need a source that can serve analytical queries; operational databases usually should not. A mirror gives analysts a copy they can hammer without touching production
- Versus DirectQuery to the source - mirrored Delta tables query at lake speed and never pass report load back to the OLTP system
The economics reinforce the design: replication compute for supported sources is included, and mirrored data enjoys a free OneLake storage allowance tied to capacity size, so the typical cost is simply the querying you were going to do anyway.
The Caveats Worth Knowing
- It is a replica, not a transformation. Mirrored tables arrive shaped like the source; the modelling work into conformed, analysis-ready layers remains yours
- Source coverage is specific. Each source has its own prerequisites and unsupported edge cases (data types, DDL patterns); read the source-specific docs before promising a stakeholder
- Deletes and schema changes flow through. That is correct behaviour, and downstream logic must tolerate it
- Governance applies immediately. A mirrored finance database is finance data in OneLake: labels, access control and audit expectations arrive with it
The Decision Rule
Mirror operational databases you own that cannot or should not serve analytics directly. Shortcut analytical stores that already can. Pipeline what needs transformation en route or lives behind neither pattern. In estates we design, mirroring has quietly become the default first hop for OLTP sources on the supported list, and the pipeline estate shrinks accordingly - which is precisely the kind of maintenance nobody misses.
Sources and Further Reading
Frequently asked
A managed replication feature: point Fabric at a supported source database and it maintains a continuously updated, query-ready copy of the tables in OneLake as Delta tables. No pipelines to author, no schedules to manage; changes flow in near real time.
The supported list has grown steadily: Azure SQL Database and Managed Instance, Azure Cosmos DB, Snowflake, and Azure Databricks Unity Catalog among them, plus open mirroring, which lets any system that can write change files participate. Check Microsoft's documentation for the current list, as it expands regularly.
Mirroring reads change feeds rather than hammering tables with extract queries, so its footprint is modest compared with batch extraction. It is still a replication client: very high-churn sources deserve a validation pass, but for most OLTP workloads the overhead is unremarkable.
The replication compute for supported sources is included, and Microsoft grants an allowance of free OneLake storage for mirrored data that scales with your capacity SKU. Querying the mirrored tables consumes capacity like any other workload. The economics usually beat maintaining equivalent ingestion pipelines.
No. A shortcut points at data where it lives; a mirror maintains a physical, continuously updated copy in OneLake. Mirror operational databases that cannot serve analytics directly; shortcut analytical stores that already can.
