Data Warehouse or Medallion Architecture Lakehouse? What on Earth do I Choose When Moving into Microsoft Fabric?!

If you're moving into Microsoft Fabric, there’s one question I see that always comes up before almost anything else: how do I organise my data? Do you stick with what's worked for years, a Data Warehouse, or move to a Medallion Architecture Lakehouse? There isn't a single right answer, but there is a right answer for your situation and it depends entirely on where you're starting from.

The Case for the Traditional Data Warehouse

Data Warehouses have been the go-to for a reason. Built on T-SQL, they do a fantastic job of staging data and presenting report-ready tables. Stored procedures, persistent tables and views make them excellent at forming clean, business-ready data. They're also generally agnostic and portable, the same skillset and structure work whether you're on-prem or in the cloud.

What Changes in Fabric

Microsoft Fabric hasn't made the Data Warehouse obsolete, you can build one in Fabric using a near-identical T-SQL experience, with full read and write support. But Fabric's real strength is how naturally it works with the Lakehouse.

When data lands in a Lakehouse as a Delta table, it's automatically exposed for T-SQL querying through the SQL analytics endpoint, no load step required. A Data Warehouse doesn't work this way: data still has to be explicitly loaded in, whether through T-SQL, pipelines, or stored procedures, before it's queryable. That's not a flaw in the Warehouse, it's simply a different model and one that adds a layer of orchestration the Lakehouse doesn't need.

When to Stick with the Data Warehouse

The strongest case for staying put is when you already have a well-structured Data Warehouse reliably supporting business-critical reporting. If it works, redesigning it around a Medallion Architecture just to have one is a waste of time and money. There's no obligation to move everything to a Lakehouse just because Fabric makes it possible.

When to Move to a Medallion Architecture Lakehouse

If you're starting fresh, though, the balance changes. A Medallion Architecture Lakehouse in Fabric gives you capabilities that simply don't exist in the traditional Data Warehouse world:

Database Mirroring
— near real-time replication of source systems straight into OneLake, without building custom ETL.
Materialized Lake Views
— now generally available in Fabric let you define a full Bronze-to-Silver-to-Gold pipeline as declarative SQL statements rather than hand-built Spark jobs or dataflows.
Shortcuts
— reference data in place across sources without duplicating it.

Together, these push you toward something close to refreshless data orchestration. And when your Gold layer tables are Lakehouse-native, Power BI can query them directly through Direct Lake mode. This means fresher data, faster, without the traditional import-and-refresh cycle a Data Warehouse depends on.

My Takeaway

If you've already got a well-established Data Warehouse doing its job, moving to a Medallion Architecture Lakehouse isn't automatically the smart move, it may just cost you time and money for something you already have. But if this is a fresh start, this is exactly the moment to build on the Medallion Architecture and let Fabric's native capabilities do the heavy lifting.

The question you should be asking isn't "Warehouse or Lakehouse?" in the abstract. It's "what do I already have, and what am I actually trying to solve?"

Blog Post

Data Warehouse or Medallion Architecture Lakehouse? What on Earth do I Choose When Moving into Microsoft Fabric?!