Overview#
Fabric storage is organized around OneLake, the single logical lake provisioned with each Fabric tenant [S1]. Lakehouses, mirrored databases, warehouses, Eventhouses with OneLake availability, and Direct Lake semantic models all rely on this shared lake pattern so data can be reused across engines without routine copying [S1] [S2] [S3].
Core concepts#
A lakehouse stores structured tables and unstructured files in OneLake, with managed tables represented as Delta/Parquet and exposed to Spark and SQL surfaces [S2]. Shortcuts behave like references to data in another OneLake location or external storage, allowing consumers to analyze data in place while leaving the target data owned by its source [S4].
Mirroring brings external operational databases into OneLake with low-code replication, converting replicated data into analytical form for downstream Fabric engines [S5]. The storage design is therefore not just a lakehouse feature: it is the shared substrate that makes lakehouse, mirroring, warehouse, Direct Lake, and real-time cold paths interoperate [S1] [S2] [S5].
How it works and best practices#
Use Delta tables in the managed table area when the data must be queryable through lakehouse SQL endpoints and Direct Lake models [S2] [S6]. Use shortcuts when the source remains authoritative elsewhere and the goal is governed reuse without another copy [S4]. Use Mirroring when the source is an operational database and the requirement is ongoing replication into Fabric rather than a one-time load [S5].
File layout is a storage concern with query consequences. V-Order, optimized write, compaction, partitioning, and Delta transaction-log metadata all affect how efficiently engines discover and scan data in OneLake [S7] [S8] [S9].
Implementation example#
The storage pattern below separates where data is authoritative from how Fabric should expose it. Lakehouse managed tables are the right serving target when SQL endpoint and Direct Lake consumers need Delta tables, shortcuts are the right reference when ownership stays elsewhere, and Mirroring is the right analytical copy path for supported operational databases [S2] [S4] [S5] [S6].
storage_contract:
raw_partner_files:
fabric_path: lakehouse/files/partner
integration: shortcut
owner: partner-platform
curated_sales_tables:
fabric_path: lakehouse/tables/gold_sales
format: delta
serving:
- sql_analytics_endpoint
- direct_lake_semantic_model
operational_orders:
integration: mirroring
analytical_store: onelake_delta
Inference: this contract is a design artifact, not a Fabric product schema. The sourced mechanics are OneLake's shared storage model, shortcut references, lakehouse managed Delta tables, SQL endpoint serving, Direct Lake reads, and Mirroring into OneLake [S1] [S2] [S3] [S4] [S5] [S6].
# Illustrative Spark transformation shape for a managed Delta table.
# Validate exact table names and workspace paths in your Fabric environment.
orders = spark.read.table("bronze_orders")
clean = orders.dropDuplicates(["OrderId"]).where("OrderId IS NOT NULL")
clean.write.format("delta").mode("overwrite").saveAsTable("silver_orders")
The example is intentionally small: the claim-backed point is that lakehouse tables use Delta/Parquet in OneLake and Spark is one write path for lakehouse tables, while query serving happens through SQL endpoint or Direct Lake surfaces [S2] [S3] [S6].
What goes wrong#
Creating separate physical lakes for each group is an anti-pattern in Fabric because it removes the benefit of a tenant-wide OneLake and reintroduces storage duplication [S1]. Treating SQL endpoint permissions as the only data boundary is also unsafe, because Spark and OneLake access paths can bypass permissions that exist only on the SQL endpoint [S6] [S10].
Internals#
Architecture & design#
OneLake maps the tenant to a single namespace, with workspaces and items represented beneath that namespace [S1]. Lakehouse tables use Delta over Parquet, and the Delta transaction log records which immutable Parquet files make up a current table version [S9].
How it works internally#
Delta readers reconstruct a consistent snapshot from checkpoint and log entries rather than relying only on directory listings [S9]. Lakehouse SQL metadata sync reads Delta log information for tables in the managed Tables area, which is why table placement and Delta format are operationally important [S6].
Performance characteristics#
Small files, high-cardinality partitioning, and poorly chosen write settings can slow both metadata discovery and query execution [S6] [S8]. V-Order improves read-side scan behavior at write time, while compaction and optimized write control the number and size of Parquet files produced by Spark jobs [S7] [S8].
Worked example#
A team can land raw data into a lakehouse, curate Delta tables with Spark, expose gold tables through the SQL analytics endpoint, and serve BI through Direct Lake over the same OneLake data [S2] [S6]. If a partner dataset already lives in ADLS or another workspace, a shortcut can expose it beside local tables without a replication pipeline [S4].