Fabric Ingestion: Mirroring vs Shortcuts vs Pipelines
When to mirror, when to shortcut and when to build a pipeline in Microsoft Fabric - the decision, the trade-offs, and the governance gotcha to check first.
Three ways to get data into Microsoft Fabric, and teams routinely pick the wrong one because each is documented well on its own and rarely against the others.
The question is not which is best. It is whether you need a replica, a reference, or control.
The short version
| You need | Use | Why |
|---|---|---|
| A whole external database kept in sync, with no ingestion to design | Mirroring | Continuous change data capture, minimal setup |
| Data that already sits in an open format, without copying it | Shortcuts | Live read-only access, no replication |
| Transformation, orchestration, or a destination outside OneLake | Pipelines / Copy job | Control over how and when data moves |
Mirroring: a replica you did not have to build
Mirroring is the right choice when you want an entire external database or catalog available in Fabric as a unit, without designing a separate ingestion process. It keeps an analytics-ready copy of an operational database in OneLake that stays in sync with the source.
It suits operational databases that need continuous change data capture - Azure SQL, PostgreSQL, Cosmos DB and others.
Two properties worth planning around:
- The destination is read-only. Mirroring writes to a single read-only destination in OneLake. It is a replica, not a working copy.
- Mirroring storage is free up to a limit tied to your purchased capacity SKU. That is a genuine economic argument for mirroring over a hand-built copy pipeline, and it scales with the SKU you already bought.
Shortcuts: a reference, not a copy
Shortcuts are the right choice when the data is already in an open format and you want it in your unified OneLake view without copying it. Delta, Iceberg, ADLS, S3, GCS.
They work at table, folder or file level, which is finer-grained than people expect, and they give live read-only access with no replication at all.
The distinction Microsoft draws in its storage guidance is clean: mirroring suits operational databases needing continuous CDC; shortcuts suit cases where you need live read-only access without replication.
Pipelines: when you need control
Shortcuts and mirroring are not replacements for Fabric's full set of ingestion and data movement tools. Reach for a pipeline, Copy job, Copy activity or Eventstream when you need:
- Transformation on the way in
- Complex orchestration across steps or dependencies
- A destination outside OneLake - neither mirroring nor shortcuts will take you there
- Scheduled batch loads from many sources
Worth knowing before you build one: Copy job supports bulk copy, incremental copy and CDC replication without building a pipeline at all. A good number of hand-built pipelines exist because nobody checked whether Copy job already did the job.
They combine, and the combination is the good pattern
The pattern worth knowing: mirror a source once in a central workspace, then have other workspaces in the same tenant shortcut to the mirrored tables rather than each mirroring the same source independently.
One replica, many references. It avoids duplicating both the sync load and the storage.
Note that shortcuts to mirrored tables are read-only, which is consistent with the mirrored destination being read-only in the first place.
The governance question to settle before you mirror
This is the part most likely to be discovered late, and the part worth raising with your security team before a mirroring design is signed off.
Fabric community posts report that row-level security, dynamic data masking and object-level permissions are not propagated to mirrored data in OneLake. We have not been able to confirm that on a Microsoft Learn page, so treat it as a question to verify for your specific source rather than as settled fact - but verify it, because the implication is significant.
If it holds for your source, a database whose protection depends on RLS is not automatically protected once mirrored. The controls have to be re-established on the Fabric side, and "we mirrored it and the permissions came with it" is an assumption worth testing rather than inheriting.
That is not an argument against mirroring. It is an argument for checking the limitations of your specific source before committing, which Microsoft's own documentation also advises.
How to actually decide
Ask three questions in order:
- Does the data already live in an open format you can read in place? If yes, start with a shortcut. No copy, no sync, no storage.
- If not, do you need the whole source kept in sync with no transformation? If yes, mirror it, then check the security limitations for that source type.
- Do you need to change the data on the way, orchestrate steps, or land it somewhere other than OneLake? Then it is a pipeline - and check whether Copy job covers it before you build one.
Most estates end up with all three. The failure mode is not using the wrong tool once; it is using one tool for everything because it was the first one the team learned.
*Sources: Microsoft Learn - Unify data with OneLake shortcuts and mirroring; Decision guide: Copy Job, Mirroring, Copy activity and Eventstreams; Decision guide for data movement and transformation; Data storage options in Microsoft Fabric. Also the Fabric blog on mirroring benefits, use cases and pricing. Fabric product behaviour changes quickly - confirm on current Learn pages before deciding. Accurate as at 25 October 2026.*
Frequently Asked Questions
When should I use mirroring instead of a shortcut in Microsoft Fabric?
Use mirroring when you want an entire external database or catalog available in Fabric as a unit, kept in sync by continuous change data capture, without designing an ingestion process. Use a shortcut when the data already sits in an open format such as Delta, Iceberg, ADLS, S3 or GCS and you want live read-only access without copying it.
Is mirrored data in Fabric writable?
No. Mirroring writes to a single read-only destination in OneLake, and shortcuts pointing at mirrored tables are read-only as well. Mirroring produces a replica for analytics, not a working copy.
Does mirroring cost extra storage?
Mirroring storage is free up to a limit tied to the capacity SKU you have purchased, which is a real economic argument for mirroring over a hand-built copy pipeline. Check the limit for your SKU.
Do row-level security and data masking carry across when I mirror a database?
Fabric community posts report that row-level security, dynamic data masking and object-level permissions are not propagated to mirrored data in OneLake. We could not confirm this on a Microsoft Learn page, so verify it for your specific source before signing off a mirroring design. If it holds, those controls must be re-established on the Fabric side.
Do I still need data pipelines if I have mirroring and shortcuts?
Yes. Shortcuts and mirroring are not replacements for Fabric's ingestion and data movement tools. You need a pipeline, Copy job, Copy activity or Eventstream for transformation, complex orchestration, scheduled batch loads from many sources, or any destination outside OneLake. Check whether Copy job covers your case first - it supports bulk copy, incremental copy and CDC replication without building a pipeline.