What Mirroring actually does#
Fabric Mirroring is a fully managed, serverless replication service: point it at a supported external database and Fabric continuously copies that data into OneLake, converting it to Parquet files in Delta Lake format — no ETL pipeline to build or maintain [S1]. Inside Data Factory, it's presented as a data-movement method that keeps a near-real-time replica of an operational database in OneLake, so analytics run against that replica instead of hitting production [S2].
Three approaches, not one#
"Mirroring" covers three mechanisms [S1]. Database mirroring physically copies table data into OneLake. Metadata mirroring is lighter — it syncs only catalog structure through OneLake shortcuts, leaving data where it lives. Open mirroring flips the model: a developer writes change data directly into a mirrored database item via public APIs and a landing zone URL, useful when a source has no native connector [S1].
What's free and what isn't#
Background replication compute doesn't consume Fabric capacity units, regardless of data volume [S1]. Storage for replicated data is also free up to one terabyte per purchased capacity unit — an F64 capacity includes 64 TB free — with charges only if you exceed that allowance or leave the capacity paused [S1]. Downstream analytical work is billed normally: querying the mirrored data through SQL, Power BI, or Spark consumes capacity units like any other workload [S1].
A worked example#
Say your order-management system runs on Azure SQL Database. Rather than exporting nightly extracts, Mirroring gives a low-latency, low-cost path to continuously replicate that database into OneLake without touching its design [S3]. Once mirrored, that data is queryable as Delta tables from Power BI, SQL, Spark, and KQL, with no ETL job in between [S1] [S2].
Supported sources#
Database mirroring supports (GA or preview) Azure Cosmos DB, Azure SQL Database, Azure SQL Managed Instance, Azure Database for PostgreSQL, Azure Database for MySQL (preview), SQL Server, Snowflake, Oracle, SAP, Google BigQuery (preview), and Fabric SQL database (auto-configured); Azure Databricks and Dremio (preview) use metadata mirroring instead [S1].
What goes wrong#
- Assuming Mirroring replaces every ingestion tool. It's built for keeping an operational replica current, not general transformation [S2].
- Forgetting downstream compute is billed. Replication is free, but every query against the mirrored data draws capacity units as usual [S1].
- Assuming unlimited free storage. The free tier scales with capacity size (1 TB per CU); exceeding it, or a paused capacity, brings charges [S1].
- Confusing metadata mirroring with a full copy. It syncs only catalog structure via shortcuts — the data itself never moves [S1].