What is Data Mirroring in Fabric and why use it for near‑real‑time analytics?

Data Mirroring in Fabric continuously replicates transactional changes into OneLake as Delta tables, providing a low‑latency replication surface for analytics. As a result, teams can run near‑real‑time queries in Fabric notebooks, SQL Warehouse, and Power BI while avoiding complex custom ETL pipelines.

Which data sources are supported for Data Mirroring in Fabric as of 2025?

Common supported sources include Azure SQL Database and Managed Instance, SQL Server (on‑premises via gateway or adapters), Azure Database for PostgreSQL, Azure Database for MySQL, Amazon RDS and other cloud databases via connectors or open mirroring, Kafka and event streaming platforms via adapters, and custom sources using Open Mirroring adapters. Verify Microsoft Learn for the latest supported connectors and prerequisites.

How does the snapshot plus CDC flow work in Data Mirroring in Fabric?

Mirroring begins with a snapshot to establish a consistent baseline, and then Change Data Capture (CDC) streams apply inserts, updates, and deletes to mirrored Delta tables. Consequently, ordering and idempotency are preserved when downstream processes apply deterministic merges into curated tables.

What are best practices to make mirrored data safe for downstream users?

Best practices include landing mirrored changes into a dedicated mirrored schema, running validation and enrichment notebooks to produce curated Delta tables, applying Delta merge upsert patterns for idempotency, recording lineage and freshness, and routing anomalies to error tables for remediation.

Can Data Mirroring in Fabric handle schema drift and evolving source schemas?

Yes. Fabric captures schema metadata and provides mapping controls, but you should implement validation checks, explicit type casts where necessary, and anomaly routing to avoid downstream failures. In practice, coordinate schema changes with governance and test mappings in staging before production.

How do I monitor replication health, lag, and failures for mirrored tables?

Monitor replication lag metrics, failed transaction alerts, and schema change notices. Additionally, create reconciliation jobs that compare source and mirrored row counts for critical tables, configure alerting for connector outages, and keep runbooks for snapshot replay and backfills.

How should I secure mirrored data and enforce governance in Fabric?

Apply Microsoft Entra RBAC to limit access, mask or expose sanitized views for PII, register mirrored datasets in the governance catalog for lineage and impact analysis, and enable audit logging for replication and user actions to meet compliance requirements.

When should I combine mirroring with Dataflow Gen2 or notebooks in Fabric?

Use Dataflow Gen2 or notebooks after mirroring: Dataflow Gen2 is ideal for visual mapping and lightweight cleanses, whereas notebooks are best for heavy computation, Delta maintenance (OPTIMIZE/Z‑ORDER), and deterministic merges. Therefore, combine dataflows for mapping and notebooks for compute‑intensive or custom logic.

How do I perform incremental feature refreshes and feed ML pipelines from mirrored data?

Mirror event or transactional streams into OneLake, then run scheduled notebooks to compute incremental features and merge them into versioned Delta feature tables. Finally, trigger model scoring pipelines to consume refreshed features, ensuring reproducibility and traceability.

Where can I find practical tutorials and companion guides for implementing Data Mirroring in Fabric?

See the Fabric Lakehouse tutorial and Data Pipelines guide for architecture and orchestration patterns, and review the Transform Notebooks article for ELT patterns. For official product guidance, consult Microsoft Learn mirroring pages and the Fabric documentation for the most up‑to‑date connector and configuration details.

Data Mirroring in Fabric - Microsoft Fabric Tutorial Series 2025

Overview What is Data Mirroring in Fabric?

Data Mirroring in Fabric is a near-real-time replication capability that continuously copies transactional data into Fabric’s OneLake, thereby enabling analytics and BI without complex ETL. As a result, teams can run up-to-date queries in notebooks, SQL Warehouse, and Power BI. Moreover, mirroring abstracts many replication complexities while preserving change-order semantics.

Key benefit: near real-time analytics with minimal engineering effort, since mirroring manages replication, snapshots, and CDC.

Sources Supported data sources for Data Mirroring in Fabric

The following sources are supported for mirroring into Fabric as of 2025; therefore, you should confirm the latest Microsoft Learn guidance for incremental updates. In practice, these cover most enterprise transactional systems and streaming sources:

Azure SQL Database and Managed Instance — native connector with CDC-based replication and minimal setup.
SQL Server (on-premises) — supported via data gateway or open mirroring adapters for secure replication.
Azure Database for PostgreSQL — native or connector-based mirroring for change capture.
Azure Database for MySQL — supported through connectors and open mirroring where applicable.
Azure Synapse and SQL Data Warehouse sources — integration paths for enterprise warehouses.
Amazon RDS and external cloud databases — via open mirroring or supported connectors for cross-cloud replication.
Kafka and event streaming platforms — ingest streams into mirrored tables using open mirroring adapters.
Custom sources via Open Mirroring — JDBC, CDC logs, and other bespoke systems can write to the mirroring endpoint with adapters.

Note: supported list evolves; consequently, check Microsoft Learn Mirroring docs for the authoritative, up-to-date list and connector-specific requirements.

Variants Types of mirroring and typical use cases – Data Mirroring in Fabric – Microsoft Fabric Tutorial Series 2025

Fabric supports several mirroring modes. For example, you may use source-native mirroring for convenience, or choose Open Mirroring for custom scenarios and cross-cloud sources. Each approach has trade-offs in latency, control, and operational complexity.

Open Mirroring: extensible and flexible, suitable for custom connectors and streaming sources.
Source-native Mirroring: managed connectors that simplify configuration for Azure-hosted databases.
Metadata Mirroring: synchronizes schema and metadata to support catalog and governance.

Start Quick setup and prerequisites for Data Mirroring in Fabric

Before enabling mirroring, ensure an active Fabric capacity, correct network connectivity to your source, and permissions to write to the destination Lakehouse. Then, walk through the mirroring wizard or set up Open Mirroring adapters for custom sources. First, validate connectivity and snapshot performance on small tables, and only then scale to high-volume tables.

High-level steps
1. Enable Fabric capacity and create a Lakehouse
2. Choose mirroring type (native or open)
3. Configure source connector and credentials
4. Define landing/mirrored database and table mappings
5. Validate initial snapshot and start CDC streaming

Also, document runbooks for connector restarts and schema change procedures to reduce downtime.

Mechanics How mirroring works under the hood

Mirroring performs an initial snapshot followed by continuous CDC. In effect, the system persists change events and applies them to mirrored Delta tables in OneLake. Therefore, consumers can query mirrored tables almost immediately after events arrive, subject to replication lag and downstream processing.

Snapshot then CDC flow

The snapshot establishes a consistent starting point, and then change events (inserts, updates, deletes) stream continuously; thus, ordering and idempotency are preserved when applied correctly.

Type mapping and schema handling

Fabric maps source types to Delta equivalents; however, ambiguous types should be explicitly cast to avoid runtime issues. Consequently, add mapping rules in the mirroring configuration or handle them in downstream notebooks.

Patterns Design patterns and idempotent landing for mirrored data

Design mirroring pipelines so downstream consumers receive curated, reliable data. For that reason, separate raw mirrored tables from curated outputs, and use notebooks or Dataflow Gen2 to apply business logic.

Landing to mirrored database then transform

Mirror raw changes into a mirrored schema, and then run deterministic notebooks to validate, enrich, and merge into curated tables. This two-step approach improves traceability and reduces risk to production analytics.

Delta merge for idempotent downstream writes

# Conceptual example
1. Mirrored changes land in mirrored_db.raw_orders
2. Notebook reads raw_orders, applies validation
3. Notebook merges validated rows into curated.orders using Delta merge

Finally, generate lineage and freshness metrics so consumers know data provenance and latency.

Operate Operational considerations and monitoring for mirroring

Operational monitoring is critical. Therefore, track replication lag, failed transactions, and schema drift. Additionally, set up alerts and a reconciliation job to reconcile source and mirrored row counts periodically.

Replication lag metrics — monitor end-to-end latency to meet SLAs.
Failure alerts — notify engineering teams on connector outages or apply automated restarts.
Schema change detection — surface unexpected changes to governance teams.

Moreover, maintain recovery playbooks that outline snapshot replays and backfill strategies in case of prolonged outages.

Trust Security, governance, and lineage for mirrored data

Mirrored data often contains sensitive operational records, so enforce strict access controls. Use Microsoft Entra RBAC, mask PII via sanitized views, and register mirrored datasets in the catalog for lineage. Consequently, auditors and consumers can understand where data originated and how it was transformed.

Least-privilege access and role separation
Column-level masking or sanitized views for PII
Register mirrored datasets for lineage and impact analysis
Audit logs for replication and access

Recipes Practical recipes and examples combining mirroring with Fabric tools

Use these templates to combine mirroring, notebooks, and pipelines into robust analytics flows. For example, you can power near-real-time dashboards or feature stores while keeping curated outputs stable.

Recipe A — Near-real-time dashboard

1. Mirror orders table from Azure SQL to mirrored_db.orders
2. Notebook validates and transforms mirrored_db.orders to curated.orders_hourly
3. Materialize hourly aggregates and expose to SQL Warehouse for Power BI

Recipe B — CDC-driven feature refresh

1. Mirror event streams into OneLake mirrored tables
2. Notebook computes incremental features and merges into features.feature_store_v1
3. Trigger model scoring pipeline using refreshed features

See orchestration examples in the Data Pipelines guide and transform patterns in the Transform Notebooks article for end-to-end templates: Data Pipelines in Fabric, Transform Data Using Notebooks.

FAQ Frequently asked questions about Data Mirroring in Fabric

Does mirroring support my on-prem and cloud databases?

Yes. Fabric supports many Azure-hosted databases natively and also supports open mirroring adapters for on-prem and cross-cloud systems; however, confirm connector compatibility and network requirements for your specific sources.

How immediate is mirrored data available for querying?

Typically, mirrored data is available within seconds to minutes depending on source CDC throughput and network latency; nonetheless, always measure replication lag for critical SLAs.

What should I do when the source schema changes?

Coordinate schema changes with governance, add explicit mappings or casts in mirroring configuration, and route unexpected changes to anomalies tables for remediation before promotion.

Where can I read official guidance and stay updated?

Follow Microsoft Learn mirroring pages for the authoritative documentation, and consult companion internal articles for practical patterns: Fabric Lakehouse Tutorial, Data Pipelines in Fabric, and Transform Notebooks.

Links References and living resources

This article is maintained as a living document; verify Microsoft Learn mirroring pages for updates. Last updated: October 2025