In Short: A Pointer, Not a Pipeline
Shortcuts are OneLake's virtualisation feature: a lakehouse can contain pointers to data that physically lives elsewhere - another workspace, ADLS Gen2, Amazon S3, Google Cloud Storage, Dataverse - and every Fabric engine treats that data as if it were local. No ingestion pipeline, no schedule, no second copy drifting out of date.
For estates with existing lakes, this is the feature that changes the Fabric adoption conversation from "migrate everything" to "point at what you have". It is also one of the easiest features to overuse without thinking about performance and cost, so the caveats below are earned.
What You Can Point At
- Other Fabric workspaces - the internal case: one team's Gold tables consumed by another team without duplication, the backbone of domain designs
- ADLS Gen2 - the most common bridge: an existing Azure lake appears in Fabric while pipelines keep running as-is
- Amazon S3 and Google Cloud Storage - cross-cloud reach, with egress economics to respect
- Dataverse - Power Platform business data available for analytics without export jobs
A shortcut to a folder of Delta tables is the sweet spot: the tables query at near-native quality from Spark, SQL endpoints and even Direct Lake in supported configurations. Shortcuts to raw files (CSV, JSON) work too, but you inherit whatever performance those formats deserve.
The Three Patterns That Earn Their Keep
Adopt Fabric without a migration. Point a lakehouse at the existing ADLS lake, build medallion layers and semantic models on top, and migrate physical storage later or never. Weeks of onboarding become an afternoon.
Bridge Databricks and Fabric. A shortcut to Delta tables that Azure Databricks maintains gives BI teams governed access in Fabric while engineering keeps its tooling - the pragmatic middle ground we recommend in many Databricks vs Fabric conversations, and now complemented by Unity Catalog mirroring.
Share within Fabric without copies. Cross-workspace shortcuts let a central data team publish curated tables once and every consuming team reference them, which is how One Copy survives organisational boundaries.
The Caveats That Deserve Respect
- Performance follows the source. A shortcut is a network read to wherever the data lives; caching helps repeated access, but a slow or throttled source is a slow table
- Cross-cloud egress is real money. Heavily queried S3/GCS shortcuts can generate meaningful transfer charges on the source side; measure before institutionalising
- The credential does the reading. Shortcuts authenticate with a stored connection, so Fabric-side permissions decide who sees the data - review that in the same breath as your security model
- Deletion semantics differ. Deleting a shortcut removes the pointer, not the data; deleting through a shortcut can affect the source. Teach the difference before someone learns it operationally
Shortcut, Mirror or Copy?
A one-paragraph decision rule. Shortcut when the source is already analytical-grade and you want zero duplication. Mirror when the source is an operational database and you want a continuously replicated, query-ready copy in OneLake. Copy via pipeline when data needs transformation, isolation or history that the source will not hold. Most mature estates use all three deliberately, and the failure mode is using one of them for everything.
Sources and Further Reading
Frequently asked
A pointer inside a lakehouse (or KQL database) to data stored somewhere else: another Fabric workspace, ADLS Gen2, Amazon S3, Google Cloud Storage or Dataverse. The data stays at its source but appears and queries like a local table or folder in OneLake.
No. Reads go to the source system (with caching to reduce repeated egress). That is the point: one copy of the data, visible in multiple places, rather than a scheduled duplication job that can drift.
When the source is already well-managed and analytical-grade: an existing data lake, a Databricks-maintained Delta table, Dataverse. Shortcuts remove the ingestion pipeline entirely. Copy (pipelines, mirroring) still wins when you need transformation on the way in, isolation from source load, or the source format is not directly consumable.
Fabric-side consumption applies when you query, and the source cloud may charge egress for data read across clouds. Caching mitigates repeated reads, but a heavily queried cross-cloud shortcut deserves a cost check before it becomes a habit.
Access is governed on the Fabric side by workspace and item permissions (with OneLake data access roles for finer control), while the shortcut authenticates to the source with a stored connection. Users do not need source-system accounts, which is convenient and something governance reviews should note: the shortcut's credential is doing the reading.
