Composite models in Power BI: wanneer DirectQuery en Import combineren slim is

Een composite model in Power BI mixt DirectQuery en Import binnen hetzelfde datamodel. Klinkt handig, maar wanneer rechtvaardigt deze extra complexiteit zichzelf? En wanneer loop je juist tegen onverwachte limieten aan?

Deze keuze bepaalt namelijk niet alleen je rapportage-snelheid, maar ook je kosten, onderhoudbaarheid en schaalbaarheid. Te vaak wordt de beslissing gemaakt zonder de echte trade-offs te doorgronden.

De vraag achter de vraag: wat probeer je op te lossen?

Voor je kiest tussen een puur Import-model, puur DirectQuery of een hybrid composite model, moet je eerst helder krijgen wat het echte probleem is.

Wil je recente data combineren met historische volumes? Dan denk je waarschijnlijk aan DirectQuery voor de fresh data en Import voor de grote historische datasets. Maar misschien is incremental refresh wel de oplossing — zonder de complexiteit van een composite model.

Heb je te maken met verschillende databronnen met verschillende toegangseisen? Een transactionele database die je niet wilt belasten tijdens kantooruren, gecombineerd met een data warehouse waar Import prima kan. Hier kan een composite model echt helpen.

Of moet je kosten beheersen? DirectQuery vermijdt dataopslag, maar genereert meer queries naar je databron. Import kost geheugen maar is sneller voor complexe berekeningen.

Het punt is: composite models zijn een oplossing voor specifieke architectuurproblemen. Niet een standaardkeuze.

De criteria die er toe doen

Dataversheid versus performance

Dit is de klassieke trade-off. DirectQuery geeft je altijd de meest recente data, maar elke visual in je rapport triggert een query naar de databron. Import is razendsnel maar toont data van de laatste refresh.

Bij een composite model kun je het beste van beide werken hebben: real-time metrics via DirectQuery, historische trends via Import. Maar je krijgt ook de slechtste eigenschappen: de performance van je composite model wordt bepaald door de langzaamste verbinding.

Als gebruikers dagelijks rapporten bekijken met data die maximaal een uur oud mag zijn, overwegen veel teams DirectQuery. Maar performance-optimalisatie van Import met frequente refreshes is vaak een betere keuze.

Concrete drempel: als je refresh-interval korter is dan 30 minuten en je databron de load aankan, is Import meestal sneller dan DirectQuery — ook voor "real-time" toepassingen.

Databronbelasting en queryprestaties

DirectQuery-tabellen genereren SQL-queries bij elke interactie. Dat betekent: elke filter, elke drill-down, elk kruistabel-segment wordt een database-query.

Bij een composite model met zowel DirectQuery als Import-tabellen wordt dit complexer. Power BI moet soms beide databronnen bevragen en de resultaten combineren. Dat gebeurt niet altijd even elegant.

Import-tabellen hebben dit probleem niet — alle queries worden lokaal uitgevoerd tegen het in-memory model. Maar ze vragen wel meer geheugen en refreshtijd.

Regel van de praktijk: als je databron niet ontworpen is voor analytische queries (veel JOINs, aggregaties), dan wordt DirectQuery een bottleneck. Een transactionele OLTP-database is meestal niet geschikt voor DirectQuery, ongeacht of het onderdeel is van een composite model.

Complexiteit van DAX en relaties

Dit is waar veel composite model-implementaties vastlopen. DAX-formules werken anders wanneer ze DirectQuery en Import combineren.

Bepaalde DAX-functies zijn niet beschikbaar in DirectQuery-modus. RANKX, TOPN en complexere time intelligence functies kunnen problemen geven. In een composite model moet Power BI soms data uit beide bronnen halen om een enkele measure te berekenen.

Relaties tussen DirectQuery en Import-tabellen hebben beperkingen. Ze zijn altijd one-to-many, en cross-filtering werkt beperkt. Als je een complexe star-schema architectuur hebt met veel dimensietabellen, kan een composite model je relaties breken.

Praktijkvoorbeeld: een Sales fact-tabel in DirectQuery gekoppeld aan een Product dimensie-tabel in Import. Filteren op product-eigenschappen triggert nu queries die beide databronnen raken. Dat kan traag zijn.

Kosten en resource-beheer

DirectQuery bespaart Premium-geheugen, maar verhoogt de load op je databron. Import doet het omgekeerde: meer Power BI-kosten, minder database-impact.

Bij Azure-gekoppelde databronnen kunnen DirectQuery-costs snel oplopen. Elke query wordt doorgesluisd naar Azure SQL Database, Synapse of je data warehouse. Bij veel gebruikers betekent dat veel DTU-verbruik.

Composite models combineren beide kostenposten: je betaalt voor Import-opslag EN voor DirectQuery-queries. Plus de ontwikkel- en onderhoudskosten van een complexer model.

Berekeningsvoorbeeld: een 5GB Import-model kost ongeveer €50/maand extra in Premium capacity. Dezelfde data via DirectQuery tegen een Azure SQL Database kan €200+ per maand kosten bij intensief gebruik — afhankelijk van je database-tier.

Governance en beveiliging

Composite models introduceren extra beveiligingslagen. Row-level security moet geconfigureerd worden voor zowel DirectQuery als Import-tabellen, maar werkt niet identiek.

Row-level security in DirectQuery delegeert filtering naar de databron. Bij Import wordt filtering gedaan in Power BI zelf. In een composite model kunnen deze twee methoden conflicteren.

Data governance wordt ook complexer: welke data komt uit welke bron, wie is verantwoordelijk voor data quality, hoe versiebeheer je het model? Bij een puur Import of puur DirectQuery-model zijn deze vragen makkelijker te beantwoorden.

Import + DirectQuery composites: de volledige analyse

Een hybrid composite model combineert Import-tabellen (vaak dimensies en historische data) met DirectQuery-tabellen (meestal real-time fact-tabellen). Dit is de meest voorkomende vorm.

Performance op elk criterium

Dataversheid: Uitstekend voor de DirectQuery-componenten, Import-componenten volgen de refresh-planning. Dit is vaak precies wat je wilt: actuele metrics, stabiele historische context.

Databronbelasting: Gemiddeld tot hoog. DirectQuery-queries blijven je transactionele systemen raken, Import-refreshes belasten de databron periodiek. Je hebt beide lasten.

DAX-complexiteit: Hoog. Cross-source relationships hebben beperkingen. Sommige DAX-patterns werken niet of worden omgezet naar langzame query-plans.

Kosten: Beide kostenposten: Premium-capacity geheugen voor Import-data plus query-kosten voor DirectQuery-verbindingen.

Governance: Complex. Verschillende beveiligingsmodellen, verschillende data-lineage, verschillende failure-modes.

Concrete use cases waar dit werkt

Dit model werkt goed wanneer je een transactionele databron hebt die je niet zwaar wilt belasten, maar wel actuele data uit nodig hebt. Bijvoorbeeld: een ERP-systeem waar je current stock levels uit DirectQuery haalt, maar historical sales data importeert uit een data warehouse.

Ook nuttig bij multi-source scenarios: klantgegevens uit een CRM (Import voor stabiliteit), real-time website-metrics uit Google Analytics via DirectQuery. Verschillende toegangspatronen, verschillende bronnen.

En bij compliance-situaties: gevoelige HR-data blijft in de databron (DirectQuery), algemene bedrijfsdata wordt geïmporteerd voor snelheid.

Wanneer het misgaat

Composite models falen vaak bij complexe relationele structuren. Als je star-schema afhankelijk is van bidirectionele filtering tussen Import en DirectQuery-tabellen, loopt het vast.

Ook bij intensief DAX-gebruik. Geavanceerde time intelligence, RANKX over grote datasets, complexe many-to-many relaties — dit alles wordt traag in een composite scenario.

En bij schaalbaarheidseisen. Een composite model met 50 gelijktijdige gebruikers presteert anders dan hetzelfde model met 5 gebruikers. DirectQuery-kosten schalen lineair, Import-kosten niet.

Puur DirectQuery: wanneer alles real-time moet

Sommige organisaties kiezen voor volledig DirectQuery-modellen: alle tabellen blijven in de databron, geen Import-cache.

Performance op elk criterium

Dataversheid: Perfect. Elke query toont de laatste data uit de databron. Geen refresh-delays, geen cache-inconsistenties.

Databronbelasting: Zeer hoog. Elke visual, elke filter genereert database-queries. Je databron wordt een bottleneck bij veel gebruikers.

DAX-complexiteit: Beperkt. Veel DAX-functies werken niet in DirectQuery-modus. Time intelligence is beperkt, complexe measures worden omgezet naar inefficiënte SQL.

Kosten: Laag voor Power BI (geen geheugen-gebruik), hoog voor je databron (veel DTU/compute).

Governance: Relatief eenvoudig. Alle data blijft in de bron, security-model is consistent.

Ideale scenario's

DirectQuery werkt uitstekend voor operationele dashboards met simpele metrics. Denk aan: huidige voorraadniveaus, dagelijkse verkopen, real-time KPI's voor management.

Ook goed voor explorerende analyses op grote datasets waar je niet vooraf weet welke data je nodig hebt. Import zou te veel geheugen kosten voor alle mogelijke combinaties.

En voor situaties met strikte data governance: data verlaat nooit de databron, alle access control gebeurt daar waar het hoort.

Waarom het vaak niet werkt

DirectQuery-implementaties falen meestal omdat de databron niet geschikt is. Een transactionele database met genormaliseerde tabellen presteert slecht voor analytische queries.

Performance-problemen ontstaan ook door complexe DAX. Iteratorformules zoals SUMX worden omgezet naar geneste subqueries die exponentieel traag worden.

En bij veel gelijktijdige gebruikers wordt je databron overbelast. DirectQuery schaalt slecht zonder query-caching en connection pooling.

Puur Import: maximale controle en snelheid

Import-modellen laden alle data in Power BI's in-memory engine. Eén keer per dag (of vaker) worden de data gerefresht.

Performance op elk criterium

Dataversheid: Afhankelijk van refresh-frequentie. Kan variëren van minuten tot dagen, afhankelijk van je Premium-capaciteit en databron-performance.

Databronbelasting: Laag tot matig. Alleen tijdens refresh-momenten. Kan geoptimaliseerd worden met incremental refresh voor grote datasets.

DAX-complexiteit: Geen beperkingen. Alle DAX-functies beschikbaar, complexe measures worden snel uitgevoerd tegen de in-memory data.

Kosten: Hoog voor Power BI (geheugen-intensief), laag voor je databron (weinig queries).

Governance: Matig. Data wordt gekopieerd naar Power BI, wat extra beveiligingslagen vereist. Maar wel eenvoudiger dan composite scenarios.

Wanneer Import de beste keuze is

Import-modellen zijn perfect voor analytische workloads met complexe DAX-berekeningen. Time intelligence, statistical functions, ML-features — alles werkt optimaal.

Ook ideaal voor dashboard-performance. Gebruikers krijgen sub-seconde responstijden, ongeacht hoeveel collega's tegelijk hetzelfde rapport bekijken.

Bij mixed-source scenarios waar je data uit Excel, SharePoint, web API's en databases combineert. DirectQuery kan niet alle databronnen aan.

Import-beperkingen

De 1GB-limiet per dataset in Power BI Pro is vaak het probleem. Premium verhoogt dit naar 10-100GB, maar grote datasets vragen veel geheugen.

Complexe refresh-dependencies kunnen ook problemen geven. Als je data uit 10 verschillende bronnen haalt, kan één trage verbinding de hele refresh blokkeren.

En bij real-time requirements is Import niet geschikt. Je kunt niet elke minuut refreshen zonder je databron te overbelasten.

Beslissingsmatrix: welke architectuur past bij jouw situatie

Deze tabel helpt bij de concrete keuze gebaseerd op je belangrijkste requirement:

Concrete drempelwaarden

Kies Import wanneer:

• Je dataset kleiner is dan 5GB EN je kunt leven met refresh-intervals van 30+ minuten
• Je hebt complexe DAX-requirements (time intelligence, statistical functions, ML)
• Je hebt meer dan 20 gelijktijdige gebruikers die interactief met het model werken
• Je databron is geoptimaliseerd voor transactionele workloads, niet voor analytics

Kies DirectQuery wanneer:

• Data moet echt real-time zijn (binnen 5 minuten na wijziging in de bron)
• Je dataset is groter dan 25GB EN je hebt een analytische databron (data warehouse, lakehouse)
• Je hebt minder dan 10 gelijktijdige gebruikers OF een krachtige databron met query-caching
• Data governance vereist dat data nooit gekopieerd wordt

Kies Composite wanneer:

• Je hebt duidelijk verschillende requirements per tabel-type (real-time facts + historische dimensies)
• Je databron kan DirectQuery-load aan voor specifieke tabellen, maar niet voor alles
• Je hebt multi-source architectuur met verschillende toegangspatronen
• Je team heeft ervaring met complexe Power BI-architecturen

Edge cases: wanneer geen van deze oplossingen werkt

Soms past geen van de drie hoofdopties. Dan heb je alternatieve architecturen nodig.

Incremental refresh als tussenoplossing

Bij grote historische datasets met dagelijkse updates kan incremental refresh een Import-model praktisch houden. Je importeert alleen de laatste maand, archiveert de rest automatisch.

Dit geeft je Import-performance voor recente data, zonder de geheugen-impact van volledige historische datasets. Beter dan een composite model voor veel scenario's.

Dataflow-preprocessing

Complexe data-transformaties kunnen beter in dataflows dan in Power BI zelf. Preprocessing in de cloud kan DirectQuery praktischer maken door de query-complexiteit te verlagen.

Of je kunt dataflows gebruiken om verschillende databronnen voor te aggregeren, waarna Import van de dataflow eenvoudiger wordt dan een composite model.

Paginated Reports voor operational data

Voor operationele rapporten met real-time data zijn Paginated Reports vaak beter dan Power BI. Ze kunnen direct tegen transactionele databronnen draaien zonder de complexiteit van composite models.

Azure Analysis Services als tussenschil

Voor enterprise-scenario's kan een semantic layer in Azure Analysis Services helpen. Dit creëert een geoptimaliseerde analytische databron waar Power BI DirectQuery tegen kan draaien.

Je krijgt real-time data-access zonder je transactionele systemen te belasten. En complexe DAX-logic kan in de Analysis Services-laag, in plaats van beperkt te worden door DirectQuery-capabilities.

Beslisregels in 3 zinnen

Als je data echt real-time moet zijn en je hebt een krachtige analytische databron, kies DirectQuery. Als je complexe berekeningen nodig hebt en kunt leven met periodieke updates, kies Import met frequent refresh. Alleen als je bewust verschillende tabellen verschillende behandeling nodig hebben, overweeg dan een composite model — maar verwacht extra complexiteit.