The one lake behind everything in Fabric#
Every Microsoft Fabric tenant gets exactly one OneLake — you can't create a second one or delete the one you have. No separate storage account to provision [S1]. OneLake is built on Azure Data Lake Storage Gen2, and every Fabric compute experience — Spark, the Warehouse engine, Power BI — is preconfigured to use it automatically, the way Office apps quietly save to your organization's OneDrive [S1].
Data loaded into a lakehouse or warehouse lands in OneLake as open Delta Parquet files, regardless of which engine wrote it [S2]. A table Spark writes and one the Warehouse engine writes end up in the same format, in the same lake, readable by any Fabric engine with no conversion step.
Shortcuts: reference data without copying it#
A shortcut is an embedded reference inside OneLake pointing at another storage location — inside OneLake, another workspace, or an external system like Azure Data Lake Storage, Amazon S3, or Dataverse [S3] [S4]. Shortcuts make remote data appear stored locally, so a lakehouse can read data it doesn't own without an ETL pipeline copying it first [S4]. A shortcut behaves like a symbolic link: deleting it leaves the original data untouched, but moving or deleting the target can break it [S5]. Create shortcuts interactively in the portal, or via the OneLake shortcuts REST API [S5].
Who can read what#
OneLake security has two planes. Control plane permissions govern what you can do — create items, manage a workspace. Data plane permissions govern what data you can read, and control-plane access often grants data access by default [S6]. Permissions follow a hierarchy — workspace, item, then folder (Tables/, Files/) — inheriting from the parent unless overridden. Admin, Member, and Contributor can read and write OneLake data; Viewer cannot, unless explicitly granted a OneLake security role [S6]. Authentication runs exclusively through Microsoft Entra ID [S6].
A worked example#
Your lakehouse needs sales data from another team's workspace, plus vendor files in an external ADLS account. Instead of a pipeline to copy both, you create two shortcuts: one at the other workspace's table, one at the ADLS folder [S3] [S4]. Both now appear under Tables/ and Files/ as if local — no duplication, no sync job [S4]. A Viewer on your team still can't query that data unless granted a OneLake security role [S6].
What goes wrong#
- Assuming a shortcut copies data. It's a live reference — deleting it is safe for the source; deleting or moving the source breaks it [S5].
- Assuming workspace access means data access. Being a Viewer doesn't by itself grant OneLake read access — that's a separate grant [S6].
- Standing up a separate physical lake per team. OneLake, shortcuts, and workspaces already give isolation and sharing without duplicating storage [S2] [S3].