An architecture scenario
Imagine separate Sales, Finance, Shared Data, and Executive Analytics workspaces. Sales owns sales transactions, Finance owns budgets, and Shared Data owns common tables such as Customer, Product, and Date. Executive Analytics needs selected data from all three, but it does not want to copy everything into another lakehouse and maintain another set of pipelines. Instead, it creates shortcuts to the authoritative tables and presents them together in its own lakehouse.
This is where the beauty of Fabric OneLake shortcuts becomes obvious. To a report developer or analyst, the Executive Analytics lakehouse can look like one complete collection of tables. That person might not even know which tables are physically stored there and which are shortcuts—and usually should not need to know. Fabric resolves those paths behind the scenes, which is one reason I call Fabric “the great data unifier”: it can present one logical data estate without forcing all the data into one physical location.
What a OneLake shortcut really does
A OneLake shortcut is a reference to data stored somewhere else. The source can be another Fabric item, workspace, tenant, or cloud storage account, while the shortcut appears as a folder or table in the consuming lakehouse. The data stays at its original location, so you avoid another physical copy and ingestion process. You do not need a shortcut simply because two lakehouses exist; Spark notebooks, pipelines, dataflows, and semantic models can often connect directly when permissions allow. A shortcut becomes valuable when you want selected remote data to appear alongside local data through one organized data surface.
Same workspace, different workspace, or different tenant?
Within the same workspace, T-SQL can often query another lakehouse, warehouse, or mirrored database by using cross-database three-part naming, such as Database.Schema.Table. Across workspaces in the same tenant, Spark can also access another lakehouse directly when the user has permission, so another workspace does not automatically mean you need a shortcut. The decision changes when you want a remote table to appear through the consuming lakehouse’s SQL analytics endpoint. That endpoint discovers Delta tables registered in its lakehouse, including tables exposed through shortcuts. To make a Delta table from another workspace available through the current SQL endpoint—and therefore through the usual Power BI and Direct Lake table experience—create a shortcut under Tables.
This is how shortcuts appear in Explorer under SQL analytics endpoint, with a small paperclip-looking icon:
Across tenants, use a formal sharing pattern. Fabric External Data Sharing lets one organization share live, read-only OneLake data with another tenant without copying it. The recipient accepts the share and chooses a lakehouse, where Fabric creates a shortcut pointing back to the source. This gives the receiving organization current data without requiring a duplicate ingestion pipeline.
Tables versus Files
Where you create the shortcut matters. A regular shortcut under Files can point to any file format; Microsoft does not publish a finite extension list because the shortcut exposes the file or folder rather than interpreting it. Examples include CSV, TSV, PSV, TXT, JSON, JSONL, NDJSON, Parquet, XML, Avro, ORC, Excel, PDFs, Office documents, logs, images, audio, video, and other binary files. Whether a workload can process a file depends on whether that workload understands its format.
A Files shortcut is useful to Spark and other file-aware tools, but it is not automatically a table. The lakehouse SQL analytics endpoint, Direct Lake, and the normal Power BI lakehouse table experience expect registered Delta tables under Tables. To use raw files through those table-oriented experiences, transform or load them into Delta; the Files shortcut itself does not make them SQL-queryable. A shortcut under Tables is intended for table behavior, and its source should normally be a valid Delta table containing Parquet data files and a Delta transaction log. A folder containing only Parquet files is not a Delta table. Once registered under Tables, the shortcut can be consumed through Spark, SQL, Power BI, and Direct Lake.
Handling raw files
If file-level access is sufficient, create a shortcut under Files and process the data with Spark. If the files need to become a queryable table, use a shortcut transformation. It can copy and convert homogeneous CSV, TSV, PSV, delimited TXT, JSON, JSONL, NDJSON, Parquet, or Excel files into a managed Delta table synchronized with the source. Because Fabric creates a Delta output, this is not completely zero-copy. Shortcut transformations are convenient, but they do not replace Data Factory pipelines, copy jobs, dataflows, notebooks, or eventstreams when you need complex joins, business rules, custom orchestration, or movement outside OneLake (sadly, we still have jobs).
What about Iceberg?
Apache Iceberg is supported through OneLake metadata virtualization. When you create a table shortcut to a supported Iceberg table, OneLake generates virtual Delta metadata so Fabric workloads can use it without rewriting the underlying Iceberg data. This is especially helpful with Snowflake-managed Iceberg tables stored in ADLS, Amazon S3, Google Cloud Storage, OneLake, or supported S3-compatible storage. Snowflake can remain the system of record and primary writer while Fabric reads the same data through a shortcut. I cover the architectural choices in Three Ways to Use Snowflake Data in Microsoft Fabric.
The tradeoffs: performance, caching, and source dependency
Shortcuts are useful, but they have tradeoffs. Because the data stays at the source, performance can depend on its location, network latency, file design, availability, and the engine reading it. Creating a shortcut does not preload or copy the complete target into the consuming lakehouse. The data is fetched when a workload requests it, so the first or “cold” read—particularly from an external cloud or on-premises source—can be slower than reading a local copy.
For supported external shortcuts, OneLake shortcut caching can reduce this penalty for repeated reads. Caching is enabled at the workspace level and currently supports Google Cloud Storage, Amazon S3, S3-compatible storage, and shortcuts accessed through the on-premises data gateway. As OneLake reads an eligible file, it fetches that file from the remote source and stores it in the workspace cache. Later requests can be served from the cache instead of crossing the network again. The cache fills file by file as users access the data—it is not populated when the shortcut is created.
Cached files can be retained for one to 28 days, and each access resets the retention period. If the source has a newer version of a file, OneLake retrieves that version and refreshes the cached copy. Individual files larger than 1 GB are not cached. This cache is separate from engine-specific caching, such as Spark intelligent cache or Direct Lake loading data into memory. Caching can improve repeated-query performance and reduce cross-cloud egress costs, but it does not guarantee that a shortcut will perform exactly like a locally stored table.
Sources that do not support OneLake shortcut caching, such as ADLS Gen2, can still benefit from caching within the Fabric engine that consumes the data. Spark intelligent cache can store accessed data on the local SSD cache of each Spark node. Direct Lake loads the columns needed by a query into the semantic model’s VertiPaq memory, while the SQL analytics endpoint transparently caches accessed data in memory and on local SSD. Therefore, running the same or a similar query again does not necessarily mean that all the data must be retrieved from the original source again.
These engine-specific caches are separate from OneLake shortcut caching. They are workload-specific, can be evicted when resources are needed elsewhere, and might not be available to a different engine querying the same shortcut. If the required data is no longer cached, has changed at the source, or was not accessed by the earlier query, the engine retrieves it from the source again. The performance benefit therefore depends on which engine is used, how much data is repeatedly accessed, and whether that data remains in the relevant cache.
Performance is not the only tradeoff. A shortcut depends on the source path, permissions, schema, and availability. Moving or deleting the target can break the shortcut, and source schema changes can affect downstream consumers. You also do not have the same control over Delta table maintenance that you have with a locally owned table. When predictable performance, independent availability, regional residency, or complete maintenance control matters more than zero-copy access, copying or replicating the data can be the better decision.
Should you create a central shared-data workspace?
A shared workspace can be a strong pattern for genuinely reusable and governed data, such as Customer, Product, Date, Currency, or organizational reference tables. Other workspaces can shortcut to only what they need, providing one authoritative source without duplicate copies. However, do not turn that workspace into a dumping ground for every table another team consumes. The better design is usually a hybrid: keep enterprise-wide conformed data in a shared workspace, keep specialized data with the domain that owns it, and let consumer workspaces shortcut directly to those sources. An executive lakehouse can then combine local tables with shortcuts to Sales, Finance, and shared dimensions while presenting users with one clean experience.
Shortcuts, Mirroring, or Data Factory?
Use a shortcut when the source is in an open format such as Delta or Iceberg and virtual access satisfies your performance, security, availability, and control requirements. Use Mirroring when you want an external database or catalog represented in Fabric. When a source stores data in a proprietary database format, Mirroring replicates the selected data into OneLake as analytics-ready Delta tables; when a supported source already uses an open format, Mirroring can reference that data in place through shortcuts. Once the source is available through a mirrored database, other workspaces can shortcut to selected tables without creating more copies—“mirror once, shortcut many times.” Use Data Factory when Mirroring does not support the source or when you need substantial transformation, orchestration, custom scheduling, or destination control.
A practical decision tree
Is the source already Delta or Iceberg?
Yes ? Use a shortcut when you want zero-copy access.
No ? Continue.
Is the source CSV, JSON, Parquet, or Excel files?
Yes ? Need only Spark or file-level access?
Yes ? Create a Files shortcut.
No ? Use a shortcut transformation or load into Delta.
No ? Continue.
Is the source a supported operational database?
Yes ? Need ongoing replication into Fabric?
Yes ? Use Mirroring.
No ? Use Data Factory for controlled movement.
No ? Use Data Factory, a notebook, a dataflow, or another ingestion method.
The bottom line
Use shortcuts to make selected, trusted data appear where consumers need it without another unnecessary copy. They can give users one clean lakehouse experience across workspaces, domains, clouds, and tenants, often without users realizing shortcuts are involved. In plain English, shortcuts let a lakehouse present data owned elsewhere as part of its own organized table and folder structure. Users see the data they need, while OneLake handles where it actually lives. However, the source still matters: its location, performance, permissions, availability, and file design can affect the experience. Shortcut caching can improve repeated reads for supported external sources, but it does not preload every file or make every shortcut behave exactly like local storage. Fabric may be “the great data unifier,” but good architecture still requires deciding when virtual access is enough and when a physical copy is worth it.
The post Microsoft Fabric OneLake Shortcuts: When to Use Them and When Not To first appeared on James Serra's Blog.