Last updated: October 14, 2026
By ZapAI Team
TL;DR: In Microsoft Fabric, lakehouse vs warehouse comes down to engine and write needs. Both keep Delta tables in OneLake and share one SQL engine for reads. Pick Lakehouse for Spark, Python, and mixed or unstructured data. Pick Warehouse for T-SQL teams and multi-table transactions. Most mature builds use both, with lakehouses for bronze and silver and a warehouse or lakehouse for gold. Settle security early, because the two items enforce it differently.
A Fabric Lakehouse is a Spark-first store for structured and unstructured data with a read-only SQL endpoint. A Fabric Warehouse is a T-SQL store with full DML and multi-table transactions. Both write Delta tables to OneLake.
Somebody on the team creates a lakehouse because the tutorial said so. Six weeks later the SQL folks want to run an UPDATE and can’t. So the fabric lakehouse vs warehouse argument starts, usually in a meeting that should have happened before anything got built.
Good news. It’s rarely an either-or call. Both items sit on the same storage, and data written by one can be read by the other without a copy. The real decisions are about who writes the data, in what language, and how you lock it down. Our Fabric architecture overview covers OneLake and workloads at a high level. This post goes a level lower, into the details that decide projects.
Bias disclosed. We sell Fabric consulting, so we’d love you to call us. You probably won’t need to for a single-team build.
What’s the Actual Difference Between a Fabric Lakehouse and a Warehouse?
The write engine. A lakehouse is written by Apache Spark and read by SQL through an endpoint. A warehouse is read and written with T-SQL, including transactions that span several tables.
Storage isn’t the difference. Microsoft’s Warehouse and Lakehouse decision guide, updated September 14, 2026, says both store data in Delta Lake format in OneLake and share the same SQL engine. Its decision tree is short. Spark (Python, Scala, Spark SQL, or R) points to Lakehouse. T-SQL points to Warehouse. Need multi-table transactions? Warehouse. Unstructured data, or not sure what’s coming? Lakehouse.
That last branch is underrated. A lakehouse has a Files area for PDFs, JSON dumps, images, and CSV drops, plus a Tables area for Delta tables. A warehouse holds tables. That’s it.
The warehouse side gets full DQL, DML, and DDL in T-SQL, so COPY INTO, INSERT, UPDATE, DELETE, CREATE TABLE AS SELECT, stored procedures, and transactions that commit or roll back across several tables together. That matters when a nightly load touches a fact table and three dimensions and you’d rather fail cleanly than half-load.
Which One Fits Your Team’s Skills and Data?
Match the item to the people writing the transformations. Notebook-heavy data engineers belong in a lakehouse. SQL developers and BI developers who live in stored procedures belong in a warehouse.
Skills decide more projects than features do. A team of four SQL Server veterans handed a lakehouse will write PySpark slowly and resent it. A Python team forced into stored procedures will rebuild half of pandas in T-SQL. Neither is a platform problem.
- Data scientists training models on raw event data? Lakehouse, no contest.
- Semi-structured feeds like JSON from APIs or IoT, which land as files first and get flattened later.
- A finance data mart with slowly changing dimensions, audited loads, and procedures your DBA already understands. That’s warehouse territory, and our Fabric Data Warehouse team builds a lot of these.
- Mixed teams. Use both and agree on which layer each group owns.
One wrinkle worth knowing. Spark can write into a warehouse through the Spark connector for Fabric Data Warehouse, which stages the data and then runs COPY INTO. Microsoft says writes need Runtime 2.0, and the connector supports interactive Microsoft Entra user sign-in only, not service principals. Planning to run it from an unattended schedule under a service principal? Test that first.
What Can the SQL Analytics Endpoint Do, and Where Does It Stop?
It reads. Every lakehouse gets a free T-SQL endpoint for SELECT queries, views, functions, and procedures, but it can’t insert, update, or delete rows. Writes go through Spark.
Per Microsoft’s SQL analytics endpoint documentation (updated October 1, 2026), the endpoint provisions automatically and runs on the same engine as Fabric Data Warehouse. Power BI connects to it like any SQL source. Metadata sync picks up new or changed Delta tables without a manual import.
The gotchas live in the limitations list, and they cause real support tickets.
- Only tables under the /Tables folder show up. Delta files sitting in /Files don’t, and neither do external Delta tables created with Spark code unless you add a shortcut.
- Delta column mapping by ID isn’t supported. By name is.
- A workspace tops out at 150 warehouse and SQL analytics endpoint items combined. Fine for most teams. Painful for anyone who spins up a lakehouse per source system.
- Adding a foreign key constraint in the endpoint blocks further schema changes on that table, like new columns.
So when an analyst asks why a table isn’t visible in SQL? Usually it’s in the wrong folder.
How Does Security Differ Between Lakehouse and Warehouse?
A warehouse secures data with T-SQL, including row-level security, column-level security, object permissions, and dynamic data masking. A lakehouse can use OneLake security roles, which follow the data across Spark, SQL, and Power BI.
The OneLake security guide for SQL analytics endpoints describes two modes. In delegated identity mode, which new endpoints start in, SQL permissions govern everything and queries run under the item owner’s identity. In user identity mode, the signed-in user’s identity passes through to OneLake, and row and column rules come from OneLake roles. Dynamic data masking isn’t supported in OneLake security, so masked columns still need SQL.
Three details from that page should shape your design.
Switching modes makes every SQL analytics endpoint in the workspace briefly unavailable and cancels running queries. It also deletes existing SQL roles, which can’t be recovered, and removes table-valued functions. Pick the mode before go-live. Changing it on a Tuesday afternoon is a bad day.
Warehouse security doesn’t travel. RLS and CLS defined in a warehouse are enforced only through its SQL endpoint. Microsoft warns that users reading that warehouse data through a OneLake shortcut might see the full data regardless of those SQL policies.
OneLake roles mainly govern Viewers. Workspace Admins, Members, and Contributors already have data access, per Microsoft’s OneLake data security overview, so handing analysts the Contributor role quietly bypasses most of your row rules. Easy mistake. Expensive one.
Does One Cost More or Run Faster Than the Other?
Neither has its own price tag. Both draw compute from the same Fabric capacity, and OneLake storage is billed per GB on top of that. Cost depends on how much work each engine does.
The meter is different, though. Microsoft’s warehouse consumption guide says warehouse queries and SQL analytics endpoint queries both roll up under Warehouse in the Capacity Metrics app, measured in vNodes of four vCores, and most of that activity is classed as background with 24-hour smoothing. Spark is billed separately, with one capacity unit equal to two Spark vCores, and you pay only while a session is active. When a query joins a warehouse to a lakehouse endpoint, usage lands on whichever item the query started from.
Performance is mostly about table hygiene. Delta file sizes, V-Order, and clustering move query times more than the item type does. One thing that does differ is that the warehouse manages its own compute with nothing to tune, while Spark lets you size pools, which is great until someone picks XX-Large nodes for a 2 GB job.
Our rule of thumb? Don’t pick an item to save money. Pick it for the team, then watch the Capacity Metrics app for a month.
How Do You Use Both in a Medallion Architecture?
Land raw data in a bronze lakehouse, clean it in a silver lakehouse, and serve gold from either a lakehouse or a warehouse. Microsoft documents both patterns.
The medallion architecture guide on Learn lists Pattern 1, every layer as a lakehouse, and Pattern 2, bronze and silver as lakehouses with gold as a warehouse. It also recommends giving each layer its own workspace for tighter governance.
| Layer | Usual item | Who writes it | Why |
|---|---|---|---|
| Bronze | Lakehouse | Pipelines, shortcuts, Spark | Raw files in original format, shortcuts to ADLS Gen2 or Amazon S3 without copying |
| Silver | Lakehouse | Spark notebooks or materialized lake views | Dedupe, standardize, conform keys at scale |
| Gold (Spark team) | Lakehouse | Spark or materialized lake views | Keeps one engine end to end |
| Gold (SQL team) | Warehouse | T-SQL procedures | Star schemas, transactional loads, SQL security, familiar tooling |
Materialized lake views shifted this choice. They let you define silver and gold transformations declaratively in Spark SQL, with Fabric handling refresh order and data quality rules, according to Microsoft’s overview. PySpark authoring is still preview. A Spark team that once moved gold into a warehouse just for SQL-style modeling now has less reason to.
Building the pipelines between layers is the bulk of the work, and it’s the core of our Fabric lakehouse implementation services.
Which Works Better With Direct Lake and Power BI?
Both work. Direct Lake reads Delta tables from lakehouses and warehouses straight into Power BI’s in-memory engine. The difference shows up in security and fallback behavior, not speed.
Microsoft’s Direct Lake overview describes two flavors. Direct Lake on SQL uses the SQL analytics endpoint and falls back to DirectQuery when a table is a SQL view or when the source uses SQL granular access control. Direct Lake on OneLake never falls back, and here’s the trap. SQL-based row-level security isn’t applied, and queries still succeed.
Read that twice. If your row rules live in warehouse T-SQL and the report uses Direct Lake on OneLake, those rules don’t filter the report. Put RLS in the semantic model, or in OneLake security, and test with a Viewer account. It’s the first thing our Power BI consulting team tests on a Direct Lake model.
What Changes If You’re Migrating From Synapse or SQL Server?
Most SQL estates land in the warehouse, because procedures and T-SQL move with the least rewriting. Spark workloads from Synapse or Databricks usually land in a lakehouse.
Microsoft’s Migration Assistant for Fabric Data Warehouse handles Azure Synapse dedicated SQL pools, SQL Server and other SQL Database Engine platforms, and Teradata metadata in preview. It takes a DACPAC, a zip of .sql files, or a direct connection, converts the schema, and lists the failed objects to fix, optionally with Copilot. A few things won’t come over cleanly.
- SQL-authenticated users. Replace them with Microsoft Entra identities.
- Column-level encryption isn’t supported, so plan app-layer encryption or masking.
- IDENTITY columns behave differently than in SQL Server. Code that relies on sequential values needs review.
- External tables and multi-statement table-valued functions are currently unsupported.
For the platform-level comparison, read our Fabric vs Azure Synapse breakdown. For sequencing and cutover, our Fabric migration approach covers parallel runs and validation.
Lakehouse or Warehouse, Which Should You Pick?
Start from who writes the data and what shape it’s in. Use the table below, then plan to use both once you have more than one team.
| If this is true | Lean toward |
|---|---|
| Your engineers write Python, Scala, or Spark SQL | Lakehouse |
| Your developers write T-SQL and stored procedures | Warehouse |
| You need multi-table transactions with rollback | Warehouse |
| You store files, JSON, images, or data science features | Lakehouse |
| You need dynamic data masking on SQL reads | Warehouse, or the endpoint in delegated mode |
| You want one set of row and column rules across Spark, SQL, and Power BI | Lakehouse with OneLake security |
| You’re migrating a Synapse dedicated pool or SQL Server warehouse | Warehouse |
| You’re migrating Spark notebooks and Delta tables | Lakehouse |
| Analysts only need to query, not load | Lakehouse SQL analytics endpoint |
Still torn? Build the bronze and silver layers as lakehouses either way. You’ll lose nothing, and the gold decision can wait until you see who actually shows up to write it.
Wrapping Up
The lakehouse and the warehouse share storage and a SQL engine, so the choice is about write engine, transactions, data types, and security model. Pick by team skills. Lock in the SQL endpoint access mode before go-live, and check how your row rules behave under Direct Lake.
ZapAI is a Microsoft Dynamics 365, Power Platform, Fabric, and AI consulting firm based in Irving, Texas. We help US companies design OneLake layers, choose between lakehouse and warehouse, and move off Synapse or SQL Server. For a layer-by-layer recommendation built on your actual sources and team, book a Fabric architecture review.
Questions Data Teams Ask About Fabric Lakehouse vs Warehouse
Can a warehouse query lakehouse tables without copying them?
Yes, through cross-database queries. A warehouse can join its own tables to a lakehouse’s SQL analytics endpoint with three-part names, and nothing gets duplicated. Usage is billed to the item where the query started.
Why can’t I run UPDATE against my lakehouse in SQL?
Because the SQL analytics endpoint is read-only by design. Modify the data with Spark, using a notebook MERGE or a materialized lake view, or move the tables you need to update into a warehouse.
Is the warehouse just a SQL Server database in the cloud?
Not quite. It speaks T-SQL, but data sits in Delta Parquet in OneLake, compute scales on its own, and there are no indexes to manage. Some SQL Server features, like SQL authentication and column-level encryption, aren’t supported, and IDENTITY columns behave differently. Test your procedures before assuming a lift and shift.
Lakehouse vs warehouse for the gold layer, does it really matter?
Less than people think. Direct Lake reads either one. Pick the warehouse if your gold modelers write T-SQL or need SQL-native masking, and stay in a lakehouse if your team lives in notebooks or materialized lake views.
Does OneLake security replace warehouse RLS?
Partly. OneLake security roles cover lakehouse data across Spark, the SQL endpoint in user identity mode, and Direct Lake, but they don’t support dynamic data masking, and Microsoft documents RLS there as single-expression only, with no dynamic RLS. Warehouse T-SQL security still governs warehouse data, and it doesn’t follow that data through shortcuts.
Which one is cheaper to run?
Neither, on paper. Both consume the same Fabric capacity units, and storage is billed the same way in OneLake. What costs money is inefficient work, like unoptimized Delta files, oversized Spark pools, or a report hammering a SQL endpoint in DirectQuery fallback. Watch the Capacity Metrics app for a month before you redesign anything.