What it is
The Fabric Warehouse is a fully managed, T-SQL data warehouse that stores data as Delta-Parquet in OneLake. Unlike a classic warehouse, your tables are open: a Lakehouse in another workspace, a notebook in Spark, or an external Trino cluster can read them directly. Unlike a Lakehouse, the Warehouse supports stored procedures, multi-table ACID transactions, and the full T-SQL DDL/DML surface area that BI teams expect.
Compute and storage are separated. Storage scales with OneLake (no provisioning), and compute scales automatically with the workload — billed in Capacity Units against your Fabric SKU.
When to use it
Pick the Warehouse when:
- Your team is fluent in T-SQL and wants stored procedures, views, and triggers.
- Your data arrives structured (CDC, mirrored OLTP, or an ETL that already lands rows in tables).
- You need cross-table ACID writes (refunds + inventory + ledger in one transaction).
- You're building a classic star schema and don't want a Spark dependency.
Pair with a Lakehouse when raw data lands files-first. They cross-query freely.
How it fits in Fabric
Warehouses sit alongside Lakehouses in a workspace, share the same OneLake, and expose the same SQL connection model. The Warehouse's tables show up under Tables/ in OneLake; the Lakehouse's SQL endpoint and the Warehouse use the same compute engine. From a query perspective, both look like SQL databases. The difference is that the Warehouse owns the write path (you can INSERT, MERGE, DELETE) while a Lakehouse's SQL endpoint is read-only.
Star schema accelerator
- Provision the Warehouse + adjacent Lakehouse. One Lakehouse holds raw and Silver tables, the Warehouse holds the Gold star schema. Same workspace if domain ownership is shared; separate workspaces otherwise.
- Ingest with pipelines or mirroring. Use Copy Job into the Lakehouse for batch loads, Mirroring for CDC from Azure SQL or Snowflake. Avoid loading directly into the Warehouse — keep the raw landing in the Lakehouse.
- Transform with cross-database
CREATE TABLE AS. The Warehouse can read Lakehouse tables:CREATE TABLE wh.fact_sales AS SELECT ... FROM lh.silver.sales. No movement, no extra copies. - Wrap with stored procedures. Idempotent procs for each fact and dimension build. Parameterize a
load_date; call from a Fabric pipeline on a schedule. - Expose to Power BI via Direct Lake. Build the semantic model on top of the Warehouse's Delta tables. Same Direct Lake benefits as a Lakehouse.
Best practices
- Star schema, not 3NF. Fabric Warehouses are columnar — query patterns aligned to a star schema win.
- Use surrogate keys. Hash- or sequence-based; never rely on natural keys for joins to dimensions.
- Statistics matter. Auto-stats handle most cases, but high-cardinality dimensions sometimes need a manual
CREATE STATISTICS. - Keep transactions small. Cross-table ACID is wonderful, but a single transaction over millions of rows blocks downstream readers.