Microsoft Fabric Mirroring vs ETL: When Can You Stop Building Incremental Load Pipelines?

Microsoft Fabric Mirroring can remove a surprising amount of ingestion plumbing.

It does not remove the need for data engineering.

Microsoft describes Mirroring as a way to make operational and analytical sources available through OneLake using continuous replication or metadata-based access, depending on the source. For database mirroring, changes can be replicated into OneLake as Delta tables without teams building the usual incremental extract, watermark and merge pipeline themselves.

That is significant.

But replication answers one question:

How do I keep a source-aligned copy of this data available in Fabric?

It does not automatically answer:

What does revenue mean?

Which customer record is authoritative?

How should deleted records affect history?

How do we reconcile finance totals?

Which fields contain PII?

What dimensions should Power BI use?

The best architecture uses Mirroring where it removes undifferentiated ingestion work and keeps engineering effort focused on transformation, quality and business meaning.

Actiknow’s data engineering and business intelligence work separates these concerns deliberately: ingestion gets data into the analytical platform reliably; transformation and semantic modeling make that data usable.

The Short Answer

Fabric Mirroring can often replace custom incremental ingestion when:

• The source is supported.
• You need a continuously updated source-aligned copy.
• Replication semantics meet the requirement.
• Supported tables and data types cover the required data.
• You do not need complex transformation before landing.

You still need ETL/ELT or other engineering for:

• Cleansing.
• Deduplication.
• Cross-source joins.
• Business rules.
• Slowly changing dimensions.
• Historical snapshots.
• Reconciliation.
• Data quality.
• PII controls.
• Semantic marts.
• Aggregations.
• Audit logic.

Mirroring is primarily a data-access and replication capability, not a complete analytical modeling strategy.

What Traditional Incremental Pipelines Usually Do

A conventional pipeline might:

• Read source changes.
• Track a watermark.
• Extract new/updated rows.
• Stage data.
• Merge inserts and updates.
• Process deletes.
• Handle retries.
• Maintain checkpoints.
• Detect schema changes.
• Log counts.
• Alert failures.

This plumbing can be expensive to build and operate.

Every source may implement change tracking differently.

Mirroring can absorb much of this source-to-OneLake replication work for supported systems.

What Fabric Mirroring Does

Current Microsoft documentation describes three broad patterns:

1. Database mirroring:

Continuously replicates supported operational databases into OneLake, generally as Delta tables.

2. Metadata mirroring:

Synchronizes catalog metadata and uses OneLake shortcuts so open-format data can remain at the source.

3. Open mirroring:

Lets providers or custom applications publish change data into a mirrored database landing zone using the supported open specification.

The implementation depends on the source.

Do not assume every mirrored system physically copies data in exactly the same way.

What Mirroring Can Replace

For a supported database, Mirroring may replace custom code for:

• Initial source replication.
• Incremental change capture.
• Watermark management.
• Repeated scheduled extracts.
• Basic insert/update/delete propagation.
• Landing-zone Delta maintenance.
• Some schema synchronization.
• Replication monitoring.

This can remove entire classes of pipeline maintenance.

The key phrase is “source replication.”

That boundary matters.

Mirroring Does Not Replace Transformation

Operational tables are designed for applications.

Analytics needs different structures.

You may still need to:

• Rename fields.
• Standardize types.
• Flatten structures.
• Join tables.
• Create facts and dimensions.
• Apply business calculations.
• Build conformed dimensions.
• Aggregate large datasets.
• Create reporting marts.

Mirroring can provide the raw/current input.

Transformation creates the analytical product.

Mirroring Does Not Replace Data Quality

A replicated bad value is still a bad value.

You still need controls for:

• Nulls.
• Invalid codes.
• Duplicate business keys.
• Broken relationships.
• Unexpected volumes.
• Out-of-range amounts.
• Schema changes.
• Missing records.

Replication success does not mean analytical correctness.

Mirroring Does Not Replace Reconciliation

For business-critical reporting, compare Fabric outputs against source systems.

Examples:

• Row counts.
• Financial totals.
• Order totals.
• Delete counts.
• Distinct customers.
• Daily transaction volume.
• Status distributions.

Reconciliation should detect whether the analytical result matches the intended source/business definition.

Do not use “replication is running” as a substitute for reconciliation.

Mirroring Does Not Create Business History Automatically

Operational systems often represent current state.

Analytics may need history.

Examples:

• Customer tier changes.
• Account ownership.
• Membership status.
• Product category.
• Territory.
• Employee department.

If the source overwrites the old value, a current mirrored table may not provide the historical dimension behavior the business needs.

Design snapshots or slowly changing dimensions where required.

Mirroring Does Not Define the Semantic Layer

Power BI needs governed concepts.

• Revenue.
• Customer.
• Active Member.
• Qualified Lead.
• Enrollment.
• Margin.

These definitions usually combine fields and business rules.

Mirroring moves source data.

It does not decide which definition the organization should use.

Build semantic marts and Power BI models deliberately.

Source Support Is a Hard Constraint

Fabric Mirroring supports a growing set of sources.

Microsoft’s current documentation lists sources such as Azure SQL, SQL Server, PostgreSQL, MySQL in applicable availability states, Oracle, SAP, Snowflake, Google BigQuery and others.

Support changes over time.

Before designing around Mirroring, verify the current documentation for the exact:

• Source.
• Edition.
• Region.
• Network configuration.
• Authentication.
• Table features.
• Data types.

Do not design from a generic “Fabric supports SQL” assumption.

Read the Source-Specific Limitations

This is essential.

Mirroring limitations vary by source.

Potential issues include:

• Unsupported data types.
• Primary-key requirements.
• DDL restrictions.
• Table-count limits.
• LOB behavior.
• Precision changes.
• Unsupported table features.
• Network requirements.
• Reseeding behavior.

For example, current Microsoft documentation for some SQL mirroring scenarios documents unsupported types/features and cases where DDL changes can trigger reseeding.

A POC must include the difficult tables, not only simple ones.

Understand Reseeding

Some schema or source changes can require a table to be fully reseeded.

That affects:

• Source load.
• Replication lag.
• Operational windows.
• Monitoring.
• Data availability.

Ask:

• What changes trigger reseed?
• How large are those tables?
• How long can reseed take?
• What happens to downstream reporting?
• How will the team know?

This belongs in the operating model.

Near Real Time Is Not Zero Latency

Microsoft describes Mirroring as near-real-time replication.

Do not promise instantaneous consistency.

Measure:

• Source change timestamp.
• Fabric arrival timestamp.
• Downstream transformation completion.
• Semantic-model visibility.
• Dashboard visibility.

The business cares about end-to-end freshness, not only replication latency.

Separate Bronze From Business-Ready Data

A useful architecture is:

• Source
• → Mirrored source-aligned layer
• → Clean/conformed layer
• → Business marts
• → Semantic model
• → Reports/AI

The mirrored layer should preserve enough source fidelity for traceability.

Downstream layers add business meaning.

This separation also makes troubleshooting easier.

When Mirroring Can Eliminate a Pipeline

Suppose a team currently has:

• Azure SQL source.
• Hourly ADF extract.
• UpdatedAt watermark.
• Staging table.
• MERGE into lakehouse.
• Retry logic.
• Delete workaround.

If Fabric Mirroring supports the required tables and network/security model, much of that ingestion pipeline may become unnecessary.

The downstream transformation pipeline may remain.

That is a real simplification.

When Mirroring Does Not Eliminate a Pipeline

Suppose ingestion must:

• Call a SaaS REST API.
• Handle pagination.
• Refresh OAuth tokens.
• Join endpoints.
• Normalize nested JSON.
• Backfill historical periods.
• Apply vendor-specific rate-limit logic.

Mirroring may not replace that connector/pipeline.

Use the right ingestion mechanism for the source.

When You Still Need Batch ETL

Batch remains appropriate when:

• Source only produces files.
• Data is available on a schedule.
• Business requires period-close snapshots.
• Transformations must occur before persistence.
• Source access is limited to windows.
• Replication is unsupported.
• Costs are better controlled in batches.

Modern does not mean continuous for every dataset.

Mirroring and ETL Can Work Together

A common architecture is:

• Mirroring for operational databases.
• Managed connectors for SaaS.
• File ingestion for partners.
• Custom APIs for specialized sources.

Then:

Fabric pipelines/notebooks/SQL/dbt-style transformation patterns create common marts.

Do not force every source through one ingestion mechanism.

Data Contracts Still Matter

Mirroring can propagate source changes quickly.

That can make schema governance more important.

Define:

• Expected columns.
• Types.
• Business keys.
• Required fields.
• Allowed values.
• Ownership.
• Breaking-change process.

Detect changes before they silently break downstream models.

Monitor More Than Replication Status

Operational monitoring should include:

• Replication health.
• Lag.
• Reseeds.
• Skipped/unsupported tables.
• Schema changes.
• Volume anomalies.
• Downstream transformation freshness.
• Data-quality failures.
• Semantic-model freshness.

A green mirror with a failed transformation is still a stale dashboard.

Security Does Not Automatically Propagate

Review source-specific behavior carefully.

Some source security constructs may not be propagated to the mirrored OneLake representation.

That means the analytical security model must be designed explicitly.

Review:

• Workspace access.
• OneLake access.
• SQL endpoint permissions.
• Semantic-model RLS/OLS.
• Sensitive columns.
• Service principals.
• Sharing.

Do not assume source permissions follow the data.

PII Controls Still Belong Downstream

Mirroring can make operational data analytically accessible very quickly.

That increases the importance of:

• Classification.
• Masking/tokenization where appropriate.
• Column minimization.
• Retention.
• Access reviews.
• Audit.

If a field is not needed for analytics, consider whether it should be propagated into broadly accessible downstream products.

Cost Analysis Should Include Engineering Cost

Compare more than platform charges.

Traditional pipeline cost includes:

• Compute.
• Connector licensing.
• Development.
• Monitoring.
• Incident response.
• Schema-change maintenance.
• Backfills.
• On-call effort.

Mirroring may reduce engineering overhead even when raw compute savings are not dramatic.

But measure it.

Do not assume managed always means cheaper.

Build a Mirroring POC

Test:

• Largest tables.
• Highest-change tables.
• Deletes.
• Schema changes.
• Unsupported/edge data types.
• Network isolation.
• Recovery.
• Reseeding.
• Security.
• End-to-end freshness.
• Downstream transformation.

Run it long enough to observe operational behavior.

A one-hour demo proves very little.

Migration Strategy

Do not delete existing ingestion immediately.

A safer sequence:

1. Enable Mirroring for a candidate source.
2. Run it in parallel.
3. Reconcile row counts and key metrics.
4. Measure lag.
5. Test schema changes.
6. Validate downstream transformations.
7. Validate security.
8. Cut over consumers.
9. Retain rollback path.
10. Retire old ingestion after a stable period.

Parallel validation reduces risk.

Which Pipelines Should You Replace First?

Good candidates:

• Simple CDC replication.
• High-maintenance watermark logic.
• Large operational databases already supported by Fabric.
• Pipelines whose main job is keeping a raw copy current.

Poor first candidates:

• Complex API ingestion.
• Heavy source-specific transformations.
• Regulatory pipelines with untested edge behavior.
• Sources with unsupported features.
• Pipelines combining many systems during ingestion.

Start where Mirroring removes plumbing without changing business logic.

An Executive Decision Framework

Use Mirroring when the requirement is primarily:

“Keep this supported source available in Fabric with low operational ingestion effort.”

Use ETL/ELT when the requirement is primarily:

“Transform, combine, validate and model this data into a trusted analytical product.”

Use both when:

You want managed replication into OneLake plus engineered transformation into governed marts.

That third pattern will be common.

Frequently Asked Questions

Does Microsoft Fabric Mirroring replace ETL?

It can replace parts of ingestion, particularly incremental replication for supported sources. It does not replace transformation, quality, reconciliation, historical modeling or semantic-layer work.

Is Fabric Mirroring real time?

Microsoft describes it as near real time. Actual end-to-end freshness depends on the source, replication behavior and downstream processing.

Does Mirroring copy all data into OneLake?

It depends on the mirroring type and source. Database mirroring can continuously replicate data into OneLake, while metadata mirroring can reference open-format source data through shortcuts.

Do we still need a bronze layer?

A mirrored source-aligned layer can serve a similar architectural purpose in some designs. You still need to define boundaries for raw/source-aligned, cleaned and business-ready data.

Can we stop using incremental watermarks?

For supported mirrored sources, Fabric can manage change replication so custom watermark logic may no longer be necessary for that ingestion path.

Does source security automatically carry into Fabric?

Not necessarily. Security propagation varies by source and feature. Design and test Fabric and semantic-model permissions explicitly.

Should we replace every pipeline with Mirroring?

No. Use Mirroring where its supported replication model fits. APIs, files, complex transformations and unsupported sources may still need other ingestion patterns.

Sources and Further Reading

• Microsoft Learn: Mirroring in Microsoft Fabric.
• Microsoft Learn: Get started with Mirroring.
• Microsoft Learn: Data ingestion options in Fabric.
• Microsoft Learn: Mirroring troubleshooting and source-specific limitations.

Conclusion

Fabric Mirroring can eliminate a lot of incremental ingestion code.

That is valuable because ingestion plumbing is rarely where an analytics team creates business differentiation.

Use Mirroring to keep supported source data available in OneLake.

Then spend engineering effort on the parts that still matter:

Quality.

Transformation.

History.

Reconciliation.

Governance.

Semantic modeling.

The architectural goal is not “no ETL.”

It is less unnecessary ETL and more reliable business-ready data.

If you are evaluating Microsoft Fabric Mirroring as a replacement for existing ingestion pipelines, Actiknow can help inventory the current pipeline estate, identify suitable candidates and design the downstream transformation and BI layers. Discuss your Fabric data architecture with Actiknow.