OneLake Shortcuts and Mirroring in Microsoft Fabric: How to Stop Copying Data
The reflex in most data teams is to copy. The data sits in an Azure storage account, an operational database or another team's lakehouse, so you build a pipeline, land a copy where the reports can reach it, and schedule it overnight. It works, and it has worked for twenty years. It is also the largest single source of cost and disagreement in a modern data estate, because every copy can drift, break or quietly go stale.
Microsoft Fabric offers two ways to break that habit. OneLake shortcuts let a lakehouse point at data that lives somewhere else and read it in place, with no copy and no pipeline to maintain. Mirroring takes an operational database and keeps a continuously updated replica in OneLake for you, without you writing the replication logic. Both aim at the same outcome: fewer copies, less orchestration, and one version of a table that everybody reads.
They are not interchangeable, and neither is free of trade-offs. This guide covers what each one does, how to choose between them and a copy pipeline, how they behave under Direct Lake, what they consume on your capacity, and the failure modes that appear once real workloads land on them.
Key Takeaways
Shortcuts reference, mirroring replicates. One reads data in place, the other keeps a managed Delta copy in OneLake on your behalf.
Both feed Direct Lake. A shortcut or mirrored table is Delta in OneLake, so Power BI can read it with no import refresh to schedule.
Copying less does not mean planning less. Permissions, region and file layout decide whether either option performs or disappoints.
What is a OneLake shortcut in Microsoft Fabric?
A shortcut is a reference inside a Fabric lakehouse that points at data held somewhere else and makes it appear as though it were stored locally. Nothing is copied. When a query runs, Fabric reads through the shortcut to the original location, so the data your report sees is the data that exists at the source right now.
Shortcuts can point at another workspace's OneLake, at Azure Data Lake Storage Gen2, at Amazon S3 and S3-compatible storage, at Google Cloud Storage and at Dataverse. In the Tables area of a lakehouse a shortcut must resolve to a Delta table, so it behaves like any other queryable table. In the Files area it can point at any folder, which suits landing zones but still leaves you a step to turn those files into tables.
The detail teams miss is identity. A shortcut to another location inside OneLake resolves using the permissions of the person running the query, so your existing workspace security still applies. A shortcut to external storage uses a stored connection, which means everyone who can read the lakehouse inherits that connection's access. That is a governance decision, not a plumbing one, and it is worth settling before the first shortcut exists.
What is Fabric mirroring, and how does it differ from a shortcut?
Mirroring creates a continuously updated, read-only replica of an operational database inside OneLake, stored in Delta Parquet format and kept current by change data capture. Unlike a shortcut it does make a copy, but Microsoft builds and runs the replication, so there is no pipeline for you to author, schedule or nurse through a failure at 2am.
Supported sources now include Azure SQL Database, SQL Managed Instance, SQL Server, Azure Cosmos DB, Azure Databricks Unity Catalog, Snowflake and PostgreSQL. Check the current list before planning around it, because it changes with almost every release.
The reason to copy at all is that transactional systems are built for writes, not for a hundred analysts scanning three years of history. Mirroring gives you an analytics-shaped Delta copy that queries cheaply and never competes with the application. The copy is read-only in Fabric: you change data at the source, and the mirror follows within seconds to minutes depending on the volume of change.
When should you use a shortcut instead of a copy pipeline?
Use a shortcut when the data is already in an analytics-friendly format and somebody else is responsible for keeping it correct. Use mirroring when the source is an operational database you need in near real time. Keep a pipeline when the data has to be reshaped, cleaned, combined or historised on the way in, because neither shortcuts nor mirroring transform anything.
Approach | Makes a copy? | Best when |
OneLake shortcut | No, reads in place | Delta or file data already curated elsewhere, and you want one version with zero orchestration |
Mirroring | Yes, managed by Fabric | An operational database is the source and you want low-latency analytics without building replication |
Copy pipeline | Yes, managed by you | The data needs transformation, history, deduplication or business rules applied before anyone reads it |
Most estates end up with all three, and that is fine. The mistake is defaulting to the pipeline because it is the familiar tool, then finding two years later that four teams maintain four slightly different copies of the same customer table. Where each dataset belongs also depends on the platform choice underneath, which we cover in our guide to warehouse, lakehouse and data mart choices.
Do shortcuts and mirroring work with Direct Lake in Power BI?
Yes, and that is much of the point. Both produce Delta tables in OneLake, and Direct Lake reads Delta files in OneLake directly rather than importing them into a model. There is no refresh to schedule, no overnight window to protect and no copy of the data sitting inside a semantic model.
Direct Lake has guardrails. If a query exceeds the limits for your capacity size, the model falls back to DirectQuery against the SQL endpoint, which is slower and behaves differently. Fallback is a signal rather than a failure: it usually means the underlying Delta files are laid out badly, not that the data is genuinely too large. Our comparison of Import, DirectQuery and Direct Lake sets out where each one earns its place.
One practical caution: a shortcut chain that reaches across regions or clouds adds latency to every Direct Lake read. It will work in a demo with a thousand rows and disappoint on a real fact table.
What do shortcuts and mirroring cost on a Fabric capacity?
A shortcut has no storage cost of its own, because you keep paying for the data wherever it lives. What it does have is a read cost on every query, plus egress charges if the source sits in another region or cloud. Mirroring is more generous: Microsoft includes an allowance of free mirrored storage that scales with capacity size and does not bill the replication compute against your capacity units, so you pay to query the result.
The consumption that surprises people is the querying, not the storing. A shortcut to a badly organised folder of small Parquet files will burn capacity units on every scan, and thirty analysts refreshing the same report will burn them thirty times. If your capacity is already under pressure, read our explainer on capacity units and throttling before you assume more compute is the answer.
Pricing terms and free allowances move with each Fabric release, so confirm the current position rather than budgeting from an article. Where sizing is genuinely open, our Microsoft Fabric consulting team models the workload against your real query patterns instead of a licence table.
What goes wrong with shortcuts and mirroring in practice?
The failures are rarely the feature itself. They are permissions, geography and file layout, in roughly that order. A shortcut created with one person's connection keeps working until that person leaves and the credential is disabled, at which point reports fail with an error that points at the lakehouse rather than the real cause.
Region mismatch is second. A capacity in one region and source storage in another adds latency to every read and a bill to every byte that crosses. Fabric will let you do it, and the demo will look fine.
The third is layout. Both options surface whatever shape the source data is in, so a table written as thousands of tiny files stays slow whichever access method you choose. Compaction and sensible partitioning are still your job, and they do more for query time than any capacity upgrade. Expect mirrored sources to need change tracking enabled, to need attention when the source schema changes, and to put real load on the source during the initial snapshot. All manageable, but only if someone plans for them before go-live.
The cheapest pipeline is the one you never build
Every copy of a table is a small ongoing liability: something to schedule, monitor, secure, pay for and reconcile when two reports disagree. Shortcuts and mirroring will not remove that work entirely, but they retire a large share of the copies that never needed to exist.
The right move is not to convert everything at once. Pick the two or three datasets that are copied most often and cause the most arguments, decide whether a shortcut or a mirror serves them better, and measure what happens to refresh windows and capacity consumption. If you are planning a broader move, our Power BI to Fabric migration work starts with exactly that audit, because the copies you retire are usually worth more than the features you adopt.
