Wanneer kies je een Warehouse, en wanneer een Lakehouse?

De vraag komt in elk Fabric-traject: Lakehouse of Warehouse? Het eerlijke antwoord is dat de feature-vergelijking steeds minder interessant wordt, beide schrijven Delta naar OneLake, beide zijn te bevragen met T-SQL, en beide voeden Direct Lake. Lakehouse en Warehouse zijn geen concurrenten maar rollen: het verschil zit in de schrijf-engine (Spark versus T-SQL) en in wie het beheert (de data engineer versus de SQL developer). Dat inzicht haalt de religie uit de discussie, en daarna valt de beslissing op drie assen.

As 1: wie bouwt eraan?

Een Warehouse is T-SQL van voor tot achter: stored procedures, grants, transactielogica. Een SQL-team is er direct productief. Een Lakehouse leunt op Spark en notebooks voor de zware transformaties; zonder die competentie wordt het Lakehouse een duur opslagsysteem. Kies voor het team dat je hebt, of investeer expliciet in het team dat je wilt.

As 2: wat komt erin?

Gestructureerde data uit bekende bronnen past prima in een Warehouse. Zodra er semi-gestructureerde data (JSON, logs, events), bestanden of ML-workloads in het spel zijn, is het Lakehouse de natuurlijke habitat. De praktijkregel: hoe voorspelbaarder je bronnen, hoe beter het Warehouse past.

As 3: wie en wat consumeert?

Alleen rapportage en SQL-analisten? Warehouse. Ook data scientists, feature engineering en API's op dezelfde data? Lakehouse. Multi-engine toegang op één kopie van de data is precies waar het Lakehouse-model voor bedacht is.

Vergeet het SQL Analytics Endpoint niet

Het onderdeel dat mensen het minst snappen: elk Lakehouse krijgt automatisch een lees-only T-SQL-oppervlak, het SQL Analytics Endpoint. Daarmee bevraag je Lakehouse-tabellen in vertrouwd T-SQL, maak je views en pas je RLS toe, maar schrijven kan niet. Geen INSERT, UPDATE, DELETE of MERGE. Wie transactionele writes op de serving-laag nodig heeft, zit dus bij het Warehouse.

En ken de twee gotcha's die stille datafouten geven. Eén: de metadata-sync-lag, data die Spark net wegschreef is niet altijd meteen zichtbaar op het endpoint; ketens die direct na een write query'en, missen rijen. Twee: de standaard-collatie van het Warehouse is hoofdlettergevoelig, dus joins en filters breken stil op casing, en die collatie kies je alleen bij het aanmaken.

Het antwoord dat niemand wil horen

In de meeste organisaties van enige omvang is het antwoord "beide": een gesplitste medallion met het Lakehouse als fundament (Bronze en Silver, waar Spark en ML thuis zijn) en een Warehouse als serveerlaag waar SQL-workflows, volledige DML en stored-procedure-logica de boventoon voeren. De echte fout is niet de verkeerde engine kiezen; de echte fout is een dogmatische alles-in-één-engine-keuze die je over twee jaar terugbetaalt, met een team dat tegen zijn eigen gereedschap vecht.

Geruststellend detail: omdat beide naar dezelfde OneLake schrijven, is een latere verschuiving tussen de twee geen big-bang migratie maar een verplaatsing van transformatielogica. Je kiest niet voor de eeuwigheid. Leg de beslissing één keer vast als architectuurprincipe met de drie assen hierboven, en wijk alleen beargumenteerd af. Dat scheelt elke sprint dezelfde vergadering.