Fabric Lakehouse or Warehouse: Which Should a Mid-Market Team Actually Build On?
You are on the Create item screen of a new Microsoft Fabric workspace. Lakehouse and Warehouse sit side by side in near-identical language, and nothing tells you which one you will regret in eighteen months. Nothing is loaded yet, which is the best moment to decide and the worst moment to know enough.
The familiar argument does not help: outside Fabric, lake versus warehouse was about storage, cheap open files against expensive proprietary ones. Inside Fabric it is gone: both items write Delta to OneLake in open Parquet on the same capacity. If those concepts are still fuzzy, our comparison of data warehouses, lakehouses and data marts covers them outside any one vendor.
What differs inside Fabric is narrow: which item you can write to with T-SQL, what your team can maintain, and what your semantic model binds to.
Key Takeaways
The SQL endpoint decides it: a Lakehouse endpoint reads only, so anything that writes through T-SQL belongs in a Warehouse.
Skills are a hard constraint: Power Query will feed a Lakehouse, but only a Warehouse is an item a T-SQL team can own end to end.
Re-pointing is the costly part: once a Direct Lake model and live reports bind to an item, switching is a project, not an edit.
What is the difference between a Fabric Lakehouse and a Warehouse?
A Fabric Lakehouse stores Delta tables and raw files in OneLake, is worked through notebooks, pipelines and dataflows, and exposes a SQL analytics endpoint that is read-only for data. A Fabric Warehouse is a T-SQL database you read and write, with stored procedures and DDL, whose tables also land in OneLake as Delta. Same storage, different front door.
You are choosing an interface and its limits, not a storage tier. The Warehouse's T-SQL surface is also narrower than SQL Server's: no identity columns, and primary keys are metadata rather than enforced.
What should decide Lakehouse or Warehouse in a small data team?
Four things, none of them features: whether anything writes through SQL, which language your team writes, what shape your sources arrive in, and who fixes it on a Friday afternoon.
Write-back through SQL. If anything has to insert or update rows through T-SQL, the choice is already made. The next section is why.
The language your team writes. A T-SQL and Power Query team can own a Warehouse from day one, and a Lakehouse will take their Dataflow Gen2 loads too, so this is not about Python. It bites when a fix outgrows a dataflow: on a Warehouse that is a stored procedure they already write, on a Lakehouse a notebook and a ticket for your one Spark person.
The shape of your sources. A Warehouse loads CSV and Parquet perfectly well. What it has no home for is a folder of mixed JSON nobody has shaped yet, which a Lakehouse's Files area takes as it arrives.
The Friday afternoon test. Ask who gets the call when the load fails and Monday's board pack is at risk. A failed Warehouse procedure gives them a T-SQL error on a line number. A failed notebook gives them a Spark application in the monitoring hub and a stack trace. Only one is a Friday fix for whoever answers the phone.
Does the read-only SQL endpoint rule out a Lakehouse for your workload?
For anything that writes, yes. The Lakehouse SQL analytics endpoint supports SELECT, views, functions and row-level security, but will not accept INSERT, UPDATE, DELETE or MERGE against Lakehouse tables. Those changes go through Spark, a pipeline or a dataflow, so anything whose natural write path is T-SQL is Warehouse work.
That one constraint settles more Fabric architecture arguments than any other, and it catches teams late: the endpoint connects like a SQL database right up until the first UPDATE fails.
Workload | Build it on | Why |
Plan numbers written back from a form | Warehouse | INSERT and UPDATE need a writable T-SQL target |
CSV drops and API extracts whose schema keeps moving | Lakehouse | The Files area takes raw formats with no agreed schema |
Spark work over large or semi-structured files | Lakehouse | Notebooks write Delta directly, so T-SQL adds nothing |
One serving layer for semantic models and Excel users | Whichever item holds your gold tables, and only one | A Direct Lake model binds to one item, so two serving layers drift apart |
Verify these in your own tenant; Fabric moves quickly.
Which item wins in four common mid-market scenarios?
Finance write-back: a writable T-SQL target; a Power BI shop with no Python: Warehouse. A CSV and API landing zone: Lakehouse; a mixed estate choosing what the semantic model reads: one serving item.
Finance wants to write plan numbers back. Verdict: a writable T-SQL target, never the Lakehouse. A Power Apps form will not bind straight to a Warehouse table and patch it: the connector wants an enforced primary key, and the Warehouse has none. What holds up is a stored procedure on a Warehouse table, called from the form through a flow. Fabric SQL database is built for row-level write-back and worth pricing against that plumbing. Prove the write path on a throwaway table before promising a date.
A Power BI shop with three report developers and no Python. Verdict: Warehouse, and do not introduce notebooks at all. Fabric will not make you provision a cluster, so provisioning is not the objection. It is adding a second language, a second set of logs and a second failure mode to a team with one of each.
A landing zone for CSV files and API extracts. Verdict: Lakehouse. Land files as they arrive, shape them into Delta once you understand them, and stop negotiating schemas with a supplier who changes their export every quarter.
A mixed estate deciding what the semantic model reads from. Verdict: one serving item, and make it the Warehouse unless every gold table is built by Spark and only Power BI will ever read it. Two serving layers means two definitions of revenue inside a year. If you are already there, that is an untangling job rather than a build, and where our Microsoft Fabric consulting engagements start.
Should you run a Lakehouse and a Warehouse together?
Only if somebody owns each layer. The pattern is well worn and sound: a Lakehouse for bronze and silver, a Warehouse for the gold tables reports and Excel users read, one serving layer on top.
One limit matters. From a Warehouse you can query Lakehouse tables in the same workspace using three-part names, so SQL endpoint consumers and Excel users get one endpoint whichever item a table came from. That does not reach the semantic model: a Direct Lake model reads Delta files in OneLake, not your cross-database query, so it still binds to one item and you still have to choose. You cannot write across that boundary either: the Warehouse reads Lakehouse tables but cannot insert into them.
The overhead is where small teams get hurt: two permission models, two places a table can be wrong, and a debate every time somebody adds one. For a two-person team, a single Warehouse carrying bronze through gold is often the better call.
What is expensive to change once reports are live?
Three things: table and column naming, which item the Direct Lake model binds to, and anything that hardcoded a three-part name. None are hard on day one; all are expensive once reports depend on them.
A Direct Lake model reads Delta tables from the item it was built over, and the service has no button for swapping items. Plan for a rebuild of its tables and relationships rather than a setting you flip: measures usually survive, column references and visuals often do not. Confirm what your tenant allows. Our comparison of Import, DirectQuery and Direct Lake covers the storage mode in detail.
Naming is the quiet one: a three-part name is item, schema, table, so every view, procedure and saved Excel connection spells out the item it was built on, and nothing warns you when that changes.
Cost scales with how much is bound to it. Moving a few tables before anyone builds on them is an afternoon. Moving a serving layer with thirty tables and live reports is a project with a test plan, a cutover and weeks of people telling you a number changed. Agree naming before the first report ships.
Choose for the write path, not the architecture diagram
Reference architectures show a Lakehouse feeding a Warehouse feeding a semantic model. That is a picture, not a decision. The real one is narrower: does anything write through T-SQL, can your team maintain the item without one indispensable person, and what will the semantic model be stuck to?
Answer those honestly and the Create item screen stops being a coin toss. A T-SQL team with a write-back requirement should build the Warehouse and feel no guilt about it. If this is part of a broader platform move, our Power BI to Fabric migration work settles the serving-layer question first.
