OneLake explained: one copy of your data, and what a shortcut actually is

Every Fabric workspace sits on one shared lake. Shortcuts let that lake point at data held somewhere else without copying it. Together they change how much data movement a platform really needs.

This is the first post in a short series on the building blocks of Microsoft Fabric. The aim is plain explanations of the parts you will meet in any Fabric project, starting with the one underneath everything else: OneLake.

One lake per organisation

OneLake is the storage layer of Microsoft Fabric. Every Fabric tenant gets exactly one, in the same way every Microsoft 365 tenant gets one OneDrive. Workspaces are folders inside it, and every lakehouse, warehouse and mirrored database you create stores its data there.

That sounds like a detail. It is not. In older Azure estates, each service tended to keep its own copy of the data: one in the data lake, one in the warehouse, another imported into Power BI. Every copy needed a pipeline, a schedule and someone to notice when it fell behind.

In Fabric, the lakehouse, the warehouse, Spark notebooks and Power BI all read the same tables in the same open format. The data is stored once. Different engines simply take turns reading it.

What a shortcut is

A shortcut is a pointer. It appears as a folder or table inside a lakehouse, but the data stays where it already lives. Nothing is copied.

Shortcuts can point at:

• Other places in OneLake, such as a table in another workspace's lakehouse or warehouse.
• Azure Data Lake Storage Gen2 and Azure Blob Storage.
• Amazon S3, S3-compatible storage and Google Cloud Storage.
• Dataverse, and files in OneDrive and SharePoint.
• On-premises storage, through the Fabric data gateway.

Once a shortcut exists, anything in Fabric can use the data behind it as if it were local. A notebook can read it, the SQL analytics endpoint can query it, and a Power BI semantic model can report on it.

For data held in another cloud, Fabric can cache files for a configurable number of days, which cuts repeated egress charges from the other provider.

Why shortcuts matter in practice

The biggest benefit is not having to build a pipeline just to move data from one place to another. Three common cases:

• A finance team's curated tables in one workspace can be shared with sales in another, without a second copy drifting out of step.
• An existing Azure data lake can be brought into Fabric on day one, rather than migrated table by table.
• Data a partner or supplier holds in their own storage account can be queried in place, with their permission.

This is the practical side of an idea we wrote about in query where your data lives. Moving data should be a choice you make for a reason, not the default.

What shortcuts do not do

Shortcuts are not a transformation tool. If the source data is messy, the shortcut shows you messy data. The cleaning, conforming and modelling covered in our Bronze, Silver and Gold and star schema posts still has to happen.

Security needs thought too. People reading through a shortcut need permission on the target data, and access to external storage runs through a connection whose credentials someone has to own. It is one of the areas we check when a Fabric rollout starts to sprawl.

Where to go next

The next post covers mirroring, which does for operational databases what shortcuts do for files. If you want to see how OneLake fits your own estate, our Microsoft Fabric page explains how we approach it, and the Fabric FAQs cover the common questions.

Store it once, point at it everywhere, and copy only when there is a reason to.