Power BI Direct Lake als alternatief voor Import en DirectQuery

Direct Lake is bedoeld voor teams die de snelheid van in-memory analyse willen, maar niet meer willen leven met lange refresh-cycli en extra opslag door duplicatie. Bij Import zet je data bewust in het Power BI-model, wat razendsnel is maar een aparte lifecycle krijgt voor refresh, validatie en vaak ook capacity planning. Direct Lake verschuift dat zwaartepunt naar je lakehouse, waardoor het model minder “ETL-werk” hoeft te doen.

DirectQuery lost het duplicatieprobleem op door elke interactie door te sturen naar de bron, maar dat maakt performance en gebruikerservaring kwetsbaar voor bronbelasting, latency en query-vertaling. Direct Lake zit daar tussenin: de bron is OneLake met Delta-tabellen, en Power BI kan data efficiënt in memory krijgen zonder klassieke importstappen. In de praktijk voelt dat vaak als “Import zonder refreshpijn”, zolang je Delta-ontwerp klopt.

Voor BI-consultants en data engineers is dit vooral interessant omdat het de grens tussen data platform en BI-model verschuift. Je semantic model wordt minder de plek waar je dataproblemen oplost, en meer de plek waar je business logica, measures en governance afspreekt. Dat is een volwassen manier van werken, maar vraagt ook om een volwassen Fabric inrichting.

Hoe Power BI Direct Lake werkt via Delta-tabellen in OneLake

De kern is simpel: Direct Lake gebruikt Delta-tabellen die in OneLake staan als primaire opslag voor je modeltabellen. In plaats van alle data vooraf te importeren, kan Power BI segmenten van kolomdata uit de Parquet/Delta-bestanden laden wanneer dat nodig is voor een query. Daardoor krijg je snelle interactie zonder dat je dataset een volledige kopie van je lakehouse wordt.

Omdat de “bron van waarheid” de Delta-tabellen zijn, wordt de kwaliteit van je Delta-layout meteen zichtbaar in je rapportperformance. Denk aan keuzes zoals kolomtypes, cardinaliteit, partitioning en hoe je schrijft naar Delta. Als je dit netjes doet, krijg je een semantic model dat heel snel kan reageren, terwijl de data governance en opslag centraal blijven in Fabric.

In Power BI Desktop zie je Direct Lake steeds meer als een eerste klas route binnen Fabric-workflows, bijvoorbeeld via de OneLake catalog en recente guidance rondom het maken van semantic models met Direct Lake-tabellen. Dat maakt het makkelijker om lakehouse-first te werken, maar het verandert niets aan het belangrijkste punt: je wint snelheid door techniek in je data platform, niet door een slimme toggle in de UI.

Prestatievoordelen: waarom Direct Lake vaak sneller voelt dan DirectQuery

DirectQuery is afhankelijk van hoe snel de bron query’s verwerkt en hoe efficiënt Power BI de query’s kan vertalen. Bij drukke bronnen of complexe modellen voel je dat direct in slicers en visuals, omdat elke interactie een roundtrip wordt. Direct Lake haalt die afhankelijkheid grotendeels weg door data lokaal in memory te kunnen brengen vanuit OneLake-bestanden.

Een belangrijk voordeel is dat Direct Lake slim kan omgaan met wat het laadt: niet alles hoeft vooraf naar memory. Bij DAX-uitvoering kunnen relevante kolomsegmenten en dictionary-structuren opgevraagd worden wanneer ze nodig zijn, waardoor de “time to first insight” vaak beter wordt dan een zwaar importmodel dat eerst volledig moet refreshen. Dat is precies waarom Direct Lake aantrekkelijk is voor grote feiten-tabellen en brede datadomeinen.

Toch moet je de belofte “net zo snel als Import” realistisch lezen. Import profiteert van VertiPaq-compressie en een sterk gecontroleerde in-memory structuur die Power BI zelf optimaliseert. Bij Direct Lake leunt performance veel meer op hoe je Delta-data is weggezet en of je modeltabellen goed aansluiten op fysieke tabellen, waardoor data engineering keuzes ineens BI-performance keuzes worden.

Beperkingen van Direct Lake: waar teams in de praktijk tegenaan lopen

De eerste beperking is conceptueel: Direct Lake is geen magische “Import maar dan zonder consequenties”. Je semantic model verwacht fysieke tabellen die goed passen op je modelstructuur, en als je je model baseert op views of constructies die niet als geschikte fysieke tabellen landen, kun je gedrag krijgen dat meer op DirectQuery lijkt. Dit is precies waar teams soms alsnog extra structuren gaan bouwen, waardoor je onbedoeld weer extra datakopieën introduceert.

Daarnaast bestaan er functionele beperkingen die je modellering beïnvloeden, vooral rond berekeningen en modelobjecten die niet op dezelfde manier werken als je gewend bent in pure Import. Guidance uit het ecosysteem (zoals Tabular Editor documentatie) benoemt bijvoorbeeld beperkingen rond calculated columns en calculated tables in combinatie met Direct Lake tabellen. Dat betekent dat je soms business logica verplaatst naar het lakehouse of naar measures, in plaats van naar modelkolommen.

Tot slot is “freshness” anders dan bij Import. Je denkt minder in refreshvensters en meer in hoe je Delta-tabellen worden bijgewerkt en beheerd, omdat Direct Lake direct op de OneLake data leunt. Dit is fantastisch als je platformproces strak is, maar pijnlijk als je data pipeline rommelig is of als tabellen vaak van schema veranderen.

Wanneer kies je Direct Lake en wanneer toch Import?

Kies Direct Lake wanneer je werkt met grote volumes, een centraal Fabric lakehouse of warehouse als bron hebt, en je team de data engineering discipline kan dragen. Dan is de winst het grootst: minder duplicatie, minder klassieke refresh-operatie en vaak een snellere gebruikerservaring dan DirectQuery. Dit past vooral bij organisaties die OneLake als standaard datalaag neerzetten en Power BI daar bovenop willen laten schalen.

Kies Import wanneer je maximale controle, voorspelbaarheid en modelleercomfort nodig hebt, of wanneer je team primair BI-gedreven is en minder grip heeft op de Delta-laag. Import blijft voor veel scenario’s de referentie voor performance en flexibiliteit, juist omdat VertiPaq veel optimalisaties “voor je regelt”. Ook als je veel semantische transformaties in het model doet, of als je afhankelijk bent van features die in Direct Lake lastiger zijn, is Import vaak de kortste weg naar stabiele waarde.

In de praktijk is de meest volwassen keuze steeds vaker hybride: grote feiten in Direct Lake en kleinere, veranderlijke of feature-gevoelige tabellen in Import binnen een composite semantic model. Microsoft publiceert hier expliciet richting en voorbeelden voor, waardoor “het beste van twee werelden” meer is dan een slogan. Als je dit goed ontwerpt, krijg je schaal op je feiten en flexibiliteit op je dimensies.

Praktische richtlijnen om Direct Lake echt te laten vliegen in Fabric

Begin bij je lakehouse, niet bij je rapport. Direct Lake beloont Delta-tabellen die ontworpen zijn voor analyse, dus denk aan duidelijke stermodellen in je curated layer en consistente keys, datatypes en naming. Als je het platform al op orde brengt, wordt je Power BI semantic model kleiner, eenvoudiger en sneller te beheren.

Maak performance een gedeelde verantwoordelijkheid tussen data engineering en BI. In Import kon een BI-team veel oplossen met modellering en refresh tuning, maar bij Direct Lake bepalen schrijfsnelheid, partitioning en Delta-maintenance veel meer van je uiteindelijke beleving. Dat is precies waarom Direct Lake teams dwingt tot volwassen samenwerking, en waarom training op Fabric fundamentals vaak direct rendement oplevert.

Tot slot: ontwerp bewust voor groei. Direct Lake is vooral sterk wanneer je verwacht dat datavolumes blijven toenemen en je niet elk kwartaal je refresh-window wil heronderhandelen. Als je nu al voelt dat Import “net” werkt, is Direct Lake vaak het moment om je architectuur future-proof te maken, mits je beperkingen en modellering vooraf meeneemt.

Samenvatting

Direct Lake is een Fabric-specifieke opslagmodus voor tabellen in een Power BI semantic model. De data blijft in OneLake als Delta, en Power BI kan kolomsegmenten on demand in memory laden om DAX-queries snel af te handelen. Dit geeft vaak een betere mix van performance en operationele eenvoud dan DirectQuery, terwijl je de extra datakopie van Import vermijdt.