Laying out a Microsoft Fabric lakehouse for analytics

Microsoft Fabric bundles data engineering, warehousing, real-time analytics, and Power BI onto one storage foundation called OneLake. The pitch is fewer moving parts. The risk is that "one platform" gets read as "no architecture required", and six months later the workspace list looks like a shared drive.

Three decisions do most of the work: how you layer the data, where your workspace boundaries fall, and whether your semantic model reads in Direct Lake mode. Get those right and the rest of Fabric is configuration.

Layer the lakehouse before you load it

Use the medallion pattern — bronze for raw ingested data, silver for cleaned and conformed tables, gold for the business-ready star schemas your reports read. In Fabric each layer is a set of Delta tables in a lakehouse, and every table is queryable as it lands because OneLake stores it in open Delta-Parquet.

Draw workspace boundaries on ownership

A Fabric workspace is the unit of access control, capacity assignment, and deployment. The boundary that survives contact with a real organisation is domain ownership: one workspace per data domain, split into development and production, rather than one giant analytics workspace everyone shares.

• Bronze and silver live in an engineering-owned workspace.
• Gold and the semantic model live in a workspace the domain team owns.
• Report authors get access to the gold workspace, never to raw ingestion.

Read gold with Direct Lake

Direct Lake lets a Power BI semantic model query Delta tables in OneLake directly — no import refresh, no DirectQuery round-trip to a warehouse. You point the model at the gold tables and it reads the Parquet. A minimal table definition for a gold fact looks like this:

CREATE TABLE gold.fact_sales
USING DELTA
PARTITIONED BY (order_date)
AS
SELECT
  s.order_id,
  s.customer_key,
  s.product_key,
  CAST(s.order_ts AS DATE) AS order_date,
  s.quantity,
  s.net_amount
FROM silver.sales AS s
WHERE s.is_valid = true;

Partitioning the fact on order_date keeps Direct Lake scans bounded when a report filters to a period, which is almost always. The moment a query cannot be served from the Delta files, Direct Lake silently falls back to DirectQuery — so watch for that in the capacity metrics rather than discovering it as a slow report.

None of this is exotic. It is the same discipline a warehouse-plus-lake architecture always needed, expressed in one platform instead of four. Fabric removes the integration work between those layers; it does not remove the need to decide what the layers are.