In Short: One Lake, Provisioned by Default
OneLake is the storage foundation of Microsoft Fabric: a single, logical data lake for the whole tenant, created automatically, that every Fabric workload uses. Lakehouses, warehouses, KQL databases, semantic models in Direct Lake mode, notebooks: all of them read and write the same store, in the same open format. Microsoft's own analogy is deliberate - OneLake is to an organisation's data what OneDrive is to its files.
The idea sounds administrative, but it is the platform's most consequential design decision. Most enterprise data pain is copy management: extracts feeding marts feeding models, each copy with its own refresh, cost and version of the truth. OneLake's answer is architectural: one copy, many engines.
What OneLake Actually Is
Technically, OneLake is a tenant-wide instance of hierarchical cloud storage, organised by workspace. Every workspace is a folder in the lake; every item's data (lakehouse tables, warehouse tables, KQL data) lives beneath it. There is nothing to provision and no storage account to manage: capacity brings the lake with it.
Data lands as Delta Parquet: open Parquet files under the Delta Lake transaction log, the same format used by Azure Databricks and much of the open ecosystem. That choice matters twice over. Inside Fabric, it is why every engine can read every table. Outside Fabric, it means your data is not locked in a proprietary format: any Delta-aware tool can read it through OneLake's ADLS-compatible APIs.
One Copy: The Claim Worth Testing
The platform's headline promise is that engines share data rather than copy it.
- A pipeline lands sales data in a lakehouse table
- The SQL analytics endpoint queries it with T-SQL, no load step
- A notebook trains against it in Spark, no extract
- Power BI serves it through Direct Lake, no import refresh
- Shortcuts extend the same trick to data in ADLS, S3, GCS or Dataverse, which stays where it is and appears in the lake
In real estates the claim holds well enough to change designs: the classic chain of staging database, warehouse, mart and import-mode model collapses into medallion layers in one lakehouse, per our medallion architecture guide, with the semantic model reading the Gold layer directly.
What It Changes Economically and Organisationally
Fewer copies, fewer reconciliations. Every eliminated extract is an eliminated refresh schedule, storage line and "why do these numbers differ" meeting. This is where OneLake quietly pays for Fabric estates.
Storage is cheap; capacity is the real bill. OneLake storage is billed like ordinary cloud object storage, separate from capacity - typically a small line. Design attention belongs on compute consumption, not gigabytes.
Governance gets one front door. One lake means one place for security, sensitivity labels and lineage to attach, and one estate for domains to organise. That is simpler than governing a dozen storage accounts, but it also concentrates the blast radius of sloppy permissions: the lake is only as governed as you configure it to be.
The Practical Take
Treat OneLake as the default answer for analytical storage on a Microsoft platform and demand a reason to deviate, not the other way round. Existing lakes do not block adoption: shortcuts and mirroring bring external data into the lake's namespace without migration, which is how most estates start. The organisations that struggle with OneLake are the ones that recreated their copy habits inside it - one lake, but five hand-copied versions of every table. The architecture removes the need for copies; the discipline to stop making them is still yours.
Sources and Further Reading
Frequently asked
OneLake is the single data lake that comes with every Microsoft Fabric tenant - one logical store, provisioned automatically, that every Fabric workload (lakehouses, warehouses, Power BI, real-time, data science) reads from and writes to. Microsoft's own analogy is OneDrive, but for an organisation's analytical data.
No. OneLake exists the moment your tenant has Fabric capacity. There is no storage account to provision, no networking to design for basic use, and no per-workspace lakes to reconcile: workspaces are folders within the one lake.
Delta Parquet: open-source Parquet files with the Delta Lake transaction layer. Every Fabric engine reads and writes the same format, which is what makes the One Copy idea work - and it means Spark tools outside Fabric, including Azure Databricks, can work with the same files.
That the same physical data serves every engine without duplication: a table written by a pipeline can be queried by the SQL endpoint, loaded by a notebook and served to Power BI via Direct Lake, all from one copy. Shortcuts extend the idea to data that lives outside Fabric entirely.
OneLake storage is billed separately from compute at rates comparable to standard cloud object storage, and it is usually a small line next to capacity cost. The economic win is the copies you stop making: fewer duplicated marts, extracts and staging stores.
