What it is
Mirroring is a continuous replication service that copies data from a transactional source into OneLake as Delta-Parquet, then keeps it in sync via change-data-capture. The result: a near-real-time read replica of your OLTP system inside Fabric, queryable by every workload.
Supported sources
- Azure SQL Database
- Azure SQL Managed Instance
- Azure Cosmos DB (NoSQL and Mongo APIs)
- Snowflake
- Databricks Unity Catalog
- Open Mirroring API (for sources Microsoft doesn't natively cover)
How it works
Mirroring reads the source's native CDC feed (e.g. Azure SQL's change feed, Cosmos DB's change feed) and lands the rows in a Mirrored Database item in OneLake. From a Lakehouse, Warehouse, or Power BI perspective, the mirrored data looks like ordinary Delta tables. Latency is typically seconds.
Common patterns
- Same-day analytics on OLTP. Mirror the production database; build the medallion model on top; semantic models stay current without ETL windows.
- Mongo / Cosmos for Power BI. Document-shaped data, mirrored as table-shaped data in OneLake. Power BI consumes via Direct Lake.
- Snowflake → Fabric coexistence. Mirror Snowflake into OneLake. Fabric workloads read; Snowflake continues to write. Useful during migration.
Best practices
- Mirror tables, not databases. Pick the tables that earn it; skip noisy operational tables that no one analyzes.
- Treat mirrored data as bronze. Don't build your semantic model directly on mirrored tables — silver/gold transformation belongs in the medallion layer.
- Monitor lag. The mirroring monitor shows seconds-of-lag per table. Set Activator on it.
- Don't mirror sensitive columns. Use source-side filters or column projection where supported.
Common pitfalls
!
Mirroring as a substitute for design. Mirroring eliminates ingestion friction. It doesn't replace medallion architecture, semantic modeling, or governance.