Power BI Import vs. DirectQuery vs. Direct Lake – Welcher Modus passt?

Ein Bericht soll schnell reagieren, aktuelle Zahlen liefern und im Betrieb bezahlbar bleiben. Klingt selbstverständlich – bis das Team zwischen Import, DirectQuery und Direct Lake entscheiden muss. Dann wird aus einer fachlichen Anforderung schnell eine Grundsatzdiskussion: Ist Import noch zeitgemäß? Brauchen aktuelle Daten immer DirectQuery? Und macht Microsoft Fabric mit Direct Lake die anderen Optionen überflüssig? Entscheidend ist, welche Daten du wann brauchst, wie sie bereitgestellt werden und wer die Lösung betreibt. Dieser Vergleich hilft dir, die passende Architektur für euren konkreten Anwendungsfall auszuwählen.

Die schnelle Antwort: Welchen Power-BI-Modus solltest du wählen?

Import ist für viele klassische Reporting-Szenarien der sinnvolle Ausgangspunkt. DirectQuery wird interessant, wenn Daten in einer geeigneten Quelle zur Abfragezeit benötigt werden und diese Quelle die zusätzliche Last tragen kann. Direct Lake passt besonders zu vorbereiteten Delta-Tabellen in OneLake und einem Team, das Microsoft Fabric bereits betreibt oder gezielt aufbaut. Das ist unsere Entscheidungsempfehlung, keine allgemeine Rangliste.

Klärt zuerst mit dem Fachbereich: Welche Handlung folgt auf eine neue Zahl, und wie schnell? Ein Team, das morgens den abgeschlossenen Vortag bewertet, braucht einen anderen Datenstand als eine laufende Auftragssteuerung.

Technisch gehört der Speichermodus zur Tabelle im semantischen Modell; Kombinationen sind möglich. Eine Liveverbindung vom Bericht zu einem vorhandenen Modell legt dessen Tabellenmodi noch nicht fest. Die folgende Tabelle vergleicht die grundlegenden Eigenschaften der drei Modi.

Kriterium	Import	DirectQuery	Direct Lake
Datenzugriff	Importierte Kopie im Modell	Native Abfragen an die Quelle	Benötigte Spalten aus Delta-Tabellen in OneLake
Verarbeitung	VertiPaq im Arbeitsspeicher	Quellsystem und semantisches Modell	VertiPaq im Arbeitsspeicher
Aktualität	Datenstand des letzten erfolgreichen Imports	Abhängig von Quelle, Abfrage und Caches	Abhängig von Datenbereitstellung, Framing und Bericht
Typischer Engpass	Modellgröße und Refresh	Quellleistung und parallele Abfragen	Kapazität, Speicher und Delta-Tabellen
Vorbereitung	Power Query und/oder vorgelagerte Aufbereitung	Möglichst abfragefähige, optimierte Quelle	Aufbereitung vorab in der Datenplattform
Plattform	Unterstützte Power-BI-Importquellen	DirectQuery-fähiger Connector	Fabric-Kapazität und geeignete Delta-Tabellen

PPU stellt keine Fabric-Kapazität bereit. Für Direct Lake reicht eine Premium-Per-User-Lizenz allein deshalb nicht. Kapazität und Benutzerlizenzen sind getrennt zu planen: Auf F-Kapazitäten unter F64 benötigen Berichtskonsumenten im regulären Power-BI-Service zusätzlich Pro oder PPU; individuelle Testlizenzen sind eine befristete Ausnahme.

Import: schnell im Bericht, bewusst beim Datenstand

Im Importmodus lädt Power BI Daten in das Modell, komprimiert sie und speichert sie für die Analyse. Die Abfragen laufen über die VertiPaq-Engine. Das schafft viel Freiheit für Power Query, DAX und die Modellierung. Der sichtbare Datenstand hängt allerdings vom erfolgreichen Refresh ab.

Ein wachsendes Importmodell ist zunächst ein Anlass zur Optimierung. Entfernt ungenutzte Spalten, begrenzt unnötige Historie und prüft die erforderliche Detailtiefe. Millionen Zeilen allein sind kein sinnvoller Grenzwert für einen Moduswechsel: Spaltenzahl, Datentypen und die Anzahl unterschiedlicher Werte beeinflussen den Speicherbedarf.

Bei großen Transaktionstabellen kann Incremental Refresh die regelmäßig neu geladenen Zeitbereiche begrenzen. Historische Korrekturen außerhalb dieses Fensters brauchen trotzdem eine passende Strategie.

Auch die Modellstruktur verdient Aufmerksamkeit. Warum sich das nicht auf eine Geschwindigkeitsfrage reduzieren lässt, zeigt unser Beitrag Flat Table vs. Sternschema.

DirectQuery: aktuelle Quelldaten brauchen eine belastbare Quelle

DirectQuery hält für die betreffenden Tabellen keine vollständige Importkopie bereit. Power BI übersetzt Abfragen in die Sprache der Datenquelle und verarbeitet die Ergebnisse weiter. Damit hängt das Nutzererlebnis auch von der Datenbank, dem Netzwerk und gegebenenfalls einem Gateway ab.

Das kann sinnvoll sein, wenn operative Daten kurzfristig verfügbar sein müssen oder ein Import trotz Optimierung unpraktikabel bleibt. Viele Visuals und gleichzeitige Nutzer erhöhen jedoch die Quelllast.

Prüft mit dem Datenbankteam Indizes, Statistiken und vorberechnete Transformationen. Bei relationalen Quellen müssen geeignete Power-Query-Schritte in native Abfragen übersetzbar sein – das sogenannte Query Folding.

DirectQuery garantiert keine Echtzeit. Caches und die Aktualisierung der Berichtsseite beeinflussen den sichtbaren Datenstand. Verschiedene Visuals können außerdem zu unterschiedlichen Zeitpunkten abfragen.

Auch die Identität wird nicht automatisch durchgereicht. Mit unterstütztem, konfiguriertem Single Sign-on (SSO) kann die Quelle den jeweiligen Nutzer prüfen. Ohne SSO verwendet DirectQuery hinterlegte Verbindungszugangsdaten für alle Betrachter. Quellberechtigungen gelten dann für diese Identität; benötigte Nutzerfilter müssen passend abgesichert werden, etwa durch Zeilenfilter im Modell (Row-Level Security, RLS).

Direct Lake: starke Option für eine vorbereitete Fabric-Plattform

Direct Lake lädt benötigte Spalten aus Delta-Tabellen in OneLake bedarfsabhängig in den Arbeitsspeicher. Dort verarbeitet VertiPaq die Abfragen.

Direct Lake verlagert Arbeit in die Datenplattform. Bereinigung und fachliche Transformationen gehören in eine passende Datenaufbereitung. Ein gepflegtes Lakehouse erleichtert das; für einen Fachbereich mit spontanen Excel-Auswertungen entsteht zunächst eine zusätzliche Abhängigkeit.

Ein Direct-Lake-Refresh aktualisiert vor allem die Referenzen auf die Delta-Dateien. Dieser Vorgang heißt Framing und kann automatisch oder gezielt nach einer Datenpipeline erfolgen. Neue Daten müssen zuerst bereitgestellt und durch Framing erfasst werden.

Vergleicht das mit einem optimierten Import: Incremental Refresh lädt nach der Initialisierung nur die vorgesehenen Zeitbereiche neu. Direct Lake kann diesen Importaufwand vermeiden, benötigt aber weiterhin Datenaufbereitung, Framing und bedarfsabhängiges Laden. Ein Vergleich ausschließlich mit vollständigen Import-Refreshes würde den Vorteil überzeichnen.

Speicherbedarf bleibt relevant. Erste Abfragen mit neu zu ladenden Spalten können anders reagieren als Wiederholungen. Viele kleine Dateien, ungünstige Row Groups und Speicherdruck beeinflussen die Leistung.

Die wichtige Unterscheidung: Direct Lake on OneLake oder on SQL?

Wer Direct Lake bewertet, muss die Variante nennen. Das betrifft besonders den Fallback: den Wechsel einer Abfrage zu DirectQuery, wenn sie nicht über den Direct-Lake-Pfad ausgeführt werden kann.

Das folgende Schaubild zeigt, wie sich Zugriff, Berechtigungen und Fallback unterscheiden und welche Prüfungen daraus für euren Pilot folgen.

Die Direct-Lake-Variante entscheidet mit darüber, welche Berechtigungen greifen und ob ein DirectQuery-Fallback möglich ist.

Nicht materialisierte SQL-Views sind keine direkte Datenquelle für Direct Lake on OneLake. Bei der SQL-Variante können beispielsweise SQL-basierte Zeilenfilter oder solche Views einen Fallback auslösen. Ist er deaktiviert, können betroffene Abfragen fehlschlagen. Für Direct Lake on OneLake gibt es diesen automatischen Ausweichweg nicht. Kapazitätsgrenzen und Fehler müssen deshalb gezielt im Pilot geprüft werden.

SQL-basierte RLS wird beim direkten OneLake-Zugriff nicht einfach als Schutzregel übernommen. Entscheidend sind der tatsächlich verwendete Zugriffspfad und die wirksame Identität: der angemeldete Nutzer bei SSO oder eine fest konfigurierte Identität. Modell-RLS schützt zudem nicht automatisch einen zusätzlichen direkten Datenzugriff.

Plant diese Ebenen gemeinsam. Unser Beitrag OneLake Security: Fabric-Berechtigungen richtig planen vertieft die zugrunde liegende Berechtigungsarchitektur.

Müssen wirklich alle Tabellen denselben Modus verwenden?

Nicht immer. Ein Composite Model kann beispielsweise importierte Dimensionen mit DirectQuery-Fakten verbinden. Dual-Tabellen können je nach Abfrage ihren Cache nutzen oder am DirectQuery-Pfad teilnehmen. Das kann helfen, erhöht aber die Anforderungen an Beziehungen, Datenkonsistenz und Tests.

Hybridtabellen kombinieren historische Importpartitionen mit einer DirectQuery-Partition für aktuelle Daten. Die Echtzeit-Erweiterung ist an unterstützte Premium-/PPU-/Embedded-Konstellationen gebunden; eine reine Pro-Umgebung reicht dafür nicht. Prüft die konkrete Kapazitäts- und Lizenzkonstellation.

Bei Direct Lake ist die Variante entscheidend: Direct Lake on OneLake lässt sich im selben Modell mit Importtabellen kombinieren, etwa für Planungsdaten. Für Direct Lake on SQL unterstützt Microsoft diese direkte Mischung nicht. Ein zusätzliches Composite Model auf einem bestehenden Direct-Lake-Modell ist eine andere Architektur und muss separat bewertet werden.

Unsere Empfehlung: Führt eine solche Kombination ein, wenn sie einen messbaren Engpass löst. Zusätzliche Modi brauchen einen klaren Nutzen im Betrieb.

Praxisbeispiel: Warum ein Vertriebsteam bei Import bleibt

Das folgende Szenario ist ein konstruiertes Beispiel. Alle Zahlen sind angenommene Anforderungen und Planwerte, keine Kundenmessungen.

Ein Vertriebsteam analysiert Umsatz, Marge und Pipeline aus ERP, CRM und Planungsdateien. 80 Personen besitzen Pro-Lizenzen, 30 arbeiten zur Spitzenzeit gleichzeitig im Bericht. Eine Fabric-Plattform ist nicht vorhanden. Um 7:30 Uhr muss der abgeschlossene Vortag vollständig bereitstehen; untertägige Änderungen sind für diese Entscheidungen nicht erforderlich.

Unsere Wahl für den Pilot: Import. Die Bereitstellung aus den Quellen soll bis 6 Uhr abgeschlossen sein. Geplant sind anschließend 30 Minuten für den Modell-Refresh, 30 Minuten für die Datenprüfung und 30 Minuten Reserve bis 7:30 Uhr. Modellgröße und Refresh müssen dabei in die vorhandene Pro-Umgebung passen. Der Pilot prüft diese Annahmen. Das BI-Team verantwortet Refresh und Alarmierung, die Quellverantwortlichen die rechtzeitige Bereitstellung; der Fachbereich bestätigt die Vollständigkeit.

DirectQuery scheidet zunächst aus, weil untertägige Aktualität keinen zusätzlichen Entscheidungsnutzen liefert und jede Berichtsnutzung zusätzliche Quellabfragen verursachen kann. Direct Lake würde den Aufbau und Betrieb einer neuen Plattform erfordern, für die dieser Anwendungsfall allein noch keinen Nutzen belegt. Die Nutzerzahl allein entscheidet keinen der drei Fälle.

Ändert sich der Bedarf, ändert sich die Auswahl: Für operative Aufträge mit kurzem Reaktionsfenster und geeigneter SQL-Quelle wird DirectQuery interessant. Liegen aufbereitete Unternehmensdaten bereits in OneLake und belastet der zusätzliche Import die Bereitstellung, wird Direct Lake zum Kandidaten.

So testest du den passenden Modus vor der Festlegung

Übertrage die Entscheidung aus dem Vertriebsbeispiel auf eure Ausgangslage: Die folgende Auswahlhilfe grenzt geeignete Kandidaten ein und bündelt die Prüfpunkte, die für jeden Modus gelten.

Anforderung und vorhandene Plattform bestimmen den Kandidaten; der Pilot prüft die Annahmen.

Vergleicht dieselben Kennzahlen, Filter, Detailstufen und Sicherheitsrollen. Für das Beispiel wäre zusätzlich das Ziel: 95 Prozent der typischen Interaktionen dauern bei 30 gleichzeitig aktiven Nutzern höchstens drei Sekunden. Auch das ist ein gewähltes Projektziel, keine Microsoft-Garantie.

1. Testablauf festlegen: Übersicht öffnen, Zeitraum filtern, Region wechseln, Detailseite aufrufen. Wiederholt dieselbe Folge mit dokumentierten Datenständen und mehreren Filterwerten.

2. Einzelmessung durchführen: Performance Analyzer trennt unter anderem DAX-Abfragezeit und Visualdarstellung. Exportiert die Ergebnisse und untersucht auffällige Visuals.

3. Parallelbetrieb prüfen: Führt die Folge in getrennten Sitzungen mit 30 aktiven Testnutzern oder einem entsprechend eingerichteten Lasttest aus. Messt vom Auslösen der Interaktion bis zur fertigen Darstellung; protokolliert Laufzeiten und Fehler. Performance Analyzer allein erzeugt keinen Mehrbenutzer-Lasttest.

4. Betriebszustände vergleichen: Wiederholt den Test bei Erstzugriff, warmen Wiederholungen, nach Datenänderungen und während üblicher Hintergrundlast. Bei Fabric hilft die Capacity Metrics App, Kapazitätsverbrauch und Drosselung zuzuordnen; für DirectQuery ergänzt ihr das Monitoring der Quelle.

5. Aktualität und Rechte abnehmen: Prüft Quellzeitpunkt, Bereitstellung, Modellstand und sichtbares Ergebnis sowie erlaubte und eingeschränkte Testnutzer. Nehmt Refresh-Ausfälle und bei Direct Lake das konfigurierte Fallback-Verhalten auf.

Dokumentiert je Kandidat Laufzeitverteilung, Fehlerquote, Datenalter, Betriebskosten und offene Abweichungen. Die Performanceziele gelten zusammen mit vollständigen Daten und korrekten Rechten. Für die anschließende Ursachenanalyse hilft unser Beitrag Power BI Performance optimieren.

Welche Kosten und Verantwortlichkeiten gehören dazu?

Vergleicht den gesamten Betrieb: Datenbereitstellung, Power-BI-Lizenzen, Fabric-Kapazität, Quellabfragen, Gateway, Monitoring und Pflege. Ohne Datenvolumen, Nutzungsprofil und vorhandene Verträge lässt sich kein seriöser allgemeiner Kostensieger bestimmen.

Import braucht verlässliche Refresh-Verantwortliche. DirectQuery braucht Zusammenarbeit mit den Betreibern der Datenquelle. Direct Lake braucht Zuständigkeiten für Datenplattform, semantisches Modell und Kapazität. Für diese organisatorische Seite lohnt sich unser Beitrag zum Power BI Center of Excellence.

---

Fazit: Daten, Plattform und Betrieb entscheiden über den Modus

Der passende Modus ergibt sich aus eurem benötigten Datenstand, der vorhandenen Plattform und einem belastbaren Betrieb. Import ist für viele Reporting-Szenarien ein sinnvoller Ausgangspunkt. DirectQuery lohnt sich bei kurzfristigem Datenbedarf, wenn die Quelle die Abfragelast tragen kann. Direct Lake ist besonders interessant, wenn aufbereitete Daten bereits in OneLake liegen und Fabric-Kapazität sowie Zuständigkeiten geklärt sind.

Entscheidend ist der Pilot mit realistischen Abfragen, parallelen Nutzern und wirksamen Berechtigungen. Prüft dabei Antwortzeiten, Datenalter und Betriebskosten gemeinsam. Bei Direct Lake gehört die gewählte Variante ausdrücklich in diese Prüfung. So wird aus einer Moduspräferenz eine nachvollziehbare Architekturentscheidung.

---

Der nächste sinnvolle Schritt

Du möchtest das für einen bestehenden Bericht klären? Im Power BI Coaching arbeiten wir an euren Modellen, DAX-Fragen und Performanceproblemen. Bring einen typischen Bericht, den benötigten Datenstand und eure bisherigen Engpässe mit. Daraus lässt sich eine konkrete, überprüfbare Architekturentscheidung entwickeln.