The Executive Insight
If you spend any time on Fabric discussions, you see the same debate on repeat:
“Should we build a lakehouse or a warehouse?”
In 2010, that was a meaningful either/or question. Data warehouses gave you structure and trust; data lakes gave you flexibility and scale. You had to choose which pain you preferred.
Fabric changes that equation.
Under the hood, both Fabric Warehouse and Fabric Lakehouse sit on top of the same OneLake storage and the same open Delta formats. They are two faces of the same platform, tuned for different ways of thinking and different skill sets.
So the real question isn’t “Which do we pick?” The real question is: “Where in our flow do we need discipline, and where do we need freedom?”
Issue #8 is about answering that question at an architectural level- so you stop having theological arguments about “team warehouse vs team lakehouse” and start designing a lake‑centric warehouse that reflects how your business actually works.
How We Got Here: The False Binary
The old story looked like this:
- Warehouses: Great for structured data, conformed dimensions, and BI. Bad at variety and scale.
- Lakes: Great at dumping anything (CSV, JSON, logs, IoT). Bad at governance, performance, and making finance sleep at night.
You were either a “warehouse shop” or a “data lake shop.” Most organizations tried to glue them together with fragile pipelines and accepted that there would always be two truths: the “real numbers” in the warehouse and the “new questions” in the lake.
Fabric’s design goal was explicitly to end that split. Microsoft calls it a “lake‑centric warehouse”:
- One logical lake (OneLake) for everything.
- Warehouse and lakehouse experiences layered on top, targeting different personas and workloads.kenwayconsulting+2
The question is no longer: “Which storage technology do we marry?”
It’s: “Which experience makes sense for which layer of our medallion flow?”
What the Documentation Really Says (Between the Lines)
If you read the decision guide and lakehouse/warehouse pages side by side, they aren’t competing products. They’re complementary roles.
- Warehouse in Fabric:
- Lakehouse in Fabric:
Microsoft’s own medallion guidance literally says:
- Bronze: Raw, in lakehouse.
- Silver: Cleaned/enriched, in lakehouse (often still wide and exploratory).
- Gold: Curated, analytics‑ready, in lakehouse or warehouse, depending on how you serve it.
The architecture question is no longer “Lakehouse or warehouse?” It’s: “Where does our gold actually live, and why?”
A Pattern from the Field: When “Engineering Purity” Collides with Executive Reality
One pattern I see in Fabric projects:
- The data engineering team falls in love with the lakehouse.
- Everything goes into the lakehouse: bronze, silver, gold.
- Reports are built directly on gold tables via SQL analytics endpoints and Direct Lake.
On paper, this is beautiful: one store, one model, open formats, modern pattern. In practice:
- Finance and regulatory teams start asking for stricter change management: versioned schemas, release cycles, impact analysis.
- The number of downstream semantic models and reports wired into the lakehouse grows- every change feels riskier.
- Data engineers discover that they’re now being asked to maintain warehouse‑like guarantees (slowly changing dimensions, auditability) in a system they mentally treated as “flexible.”
The result isn’t failure—but it is friction.
What’s actually happening is political, not technical:
- The consumption side wants a system that behaves like a warehouse.
- The production side wants to keep the freedom of a lake.
In Fabric, you have the tools to give both sides what they want. But only if you’re willing to say out loud:
“This part of the flow is lakehouse‑native. This part is warehouse‑native.”
The Strategic Shift: Lake‑Centric Warehouse, Not Warehouse vs Lake
The organizations I see winning with Fabric are doing something like this (even if they don’t use the label): lake‑centric warehouse.kenwayconsulting+2
The principles are simple:
- One lake, many doors: Everything lands in OneLake. Engineering and science experiences see it as a lakehouse; BI and analysts see it as a warehouse or semantic model.
- Medallion by intent, not just by folder name: Bronze and silver are firmly in lakehouses. Gold is wherever it best serves its consumers—often warehouse for cross‑team KPIs.
- Warehouse as the contract surface: When numbers need to be defended externally or governable internally, they graduate into warehouse tables and shared semantic models.sqlbits+2
Technically, Fabric even nudges you there:
- Warehouses can now ingest and query OneLake lakehouse files directly via COPY INTO and OPENROWSET—no separate staging or SAS token games.
- Materialized lake views and medallion patterns let you keep transformations close to the lake while still exposing stable, query‑friendly shapes.kenwayconsulting+1
You’re not choosing sides. You’re choosing where responsibility shifts:
- In the lakehouse: discovery, transformation, iteration.
- In the warehouse: commitment, contracts, and performance at scale.
The SMB Reality: You Don’t Have a Team for Everything
In a $50M–$100M SMB, you probably don’t have:
- Separate “data engineering,” “data science,” and “BI platform” teams.
- Architects who can spend weeks debating patterns.
- The appetite to maintain two completely separate platforms.
Fabric’s strength—for you—is that you don’t need to.
A pragmatic pattern I see working in lean teams:
- Start lake‑first for ingestion and transformation—because it’s cheaper and handles variety.
- Promote only the curated, cross‑domain KPIs into a warehouse when:
That might mean:
- One or two central warehouses (e.g., Finance & Performance, Operational KPIs).
- Several lakehouses for domain‑specific detail, history, and experimentation.
You use the warehouse sparingly, but with intention.
The Hopeful Part: You Don’t Have to Get It “Perfect” on Day One
The intimidating part of architecture discussions is the illusion that you must “decide for the next 10 years” up front.
Fabric’s actual behavior is more forgiving:
- You can start with a lakehouse, and only later surface subsets into a warehouse without moving data out of OneLake.
- You can run pilot workloads purely in lakehouse to learn your patterns before promoting them to a hardened warehouse gold layer.
- You can adjust the split over time as your team skills, governance maturity, and performance expectations evolve.
The important thing is not where you start. It’s how consciously you decide when to:
- Stay lakehouse‑only.
- Add a warehouse surface.
- Retire or refactor legacy chunks that no longer match your reality.
The good news: if your data is in OneLake in open formats, your past decisions aren’t dead ends. They’re refactoring candidates, not sunk costs.
Where I Fit In (For Partners and Leaders)
Most “lakehouse vs warehouse” content out there still talks to the tool chooser, not the strategist. It answers:
- “Can I do X in a lakehouse?”
- “Is feature Y now in the warehouse?”linkedin+2
Useful questions—but incomplete.
The leaders and partners I work with are asking different questions:
- “Where should our gold actually live, given our industry, regulatory posture, and team skills?”
- “How do we avoid creating yet another split brain—‘engineering truth’ in the lake, ‘executive truth’ in the warehouse?”
- “What’s the lightest‑weight medallion strategy that still sets us up for AI, governance, and performance?”enterprise-knowledge+2
That’s the layer I operate in.
I partner with:
- Microsoft and analytics partners who need an opinionated Fabric architecture story when they walk into mid‑market accounts.
- CIOs, CDOs, and CTOs who know they can’t afford three rewrites of their data platform every five years.
- Operators in F&B, healthcare, and energy who care less about “data lake vs warehouse purity” and more about “Can we trust this number on Monday morning?”
My job isn’t to pick a side in the lakehouse/warehouse debate. It’s to help you design the way they work together so your architecture reflects the real shape of your business, not the last decade’s tooling war.
Isaac Truong | Founder, Allston Yale
Enterprise-grade analytics for $50M–$100M SMBs
Power BI | Fabric | Azure | Data Strategy
📅 Book a 20-min Fabric diagnostic →
📧 Subscribe to get Friday Fabric Facts in your inbox (plus early access to templates) 💼
LinkedIn: Connect with me for daily Fabric tips
Friday Fabric Facts #8: Originally Posted on LinkedIn, March 20, 2026
