Power BI Storage Modes: Import, DirectQuery, Dual und Direct Lake richtig wählen

Definition

Power BI Storage Modes beschreiben, wie Tabellen in einem Power BI dataset (semantic model) gespeichert und zur Abfrage bereitgestellt werden. Sie sind keine Visualisierungsfunktion und auch kein Ersatz für Data-Warehouse- oder Lakehouse-Architektur.

Einleitung

Wenn Reports langsam sind oder Refreshes ständig brechen, liegt es oft nicht an „Power BI“, sondern an den power bi storage modes. Der Storage Mode bestimmt, ob Power BI Daten im Arbeitsspeicher hält, live abfragt oder hybrid kombiniert – und damit, wie gut Self-Service, Performance und Datenfrische zusammenpassen.

Power BI Storage Modes im Überblick

In Power BI gibt es mehrere storage modes, die auch in composite models kombiniert werden können.

• Import: Daten werden ins Modell geladen (in-memory), komprimiert und per Refresh aktualisiert.

• DirectQuery (direct query): Daten bleiben in der Quelle; jede Interaktion erzeugt Queries gegen das Quellsystem.

• Dual (Composite model): Tabelle kann sich je nach Abfrage wie Import oder DirectQuery verhalten; typischerweise für Dimensionen in hybriden Modellen.

Zusätzlich relevant im Fabric-Kontext: Direct Lake. Dabei wird gegen Delta Tables im Lakehouse/OneLake abgefragt, ohne klassisches Importieren.

Vergleich: Vor- und Nachteile (kompakt, entscheidungsrelevant)

Die folgende Tabelle ist absichtlich praxisnah: Sie zeigt, wo du Risiken (Performance, Komplexität) erwartest und wo du messbaren Nutzen bekommst.

Aspekt | Import | DirectQuery | Dual (Composite) | Direct Lake

Performance im Report | sehr hoch, planbar | stark quellenabhängig | oft hoch, wenn gut designt | hoch bei passenden Lakehouse-Daten

Datenfrische | nach Refresh | nahe Echtzeit möglich | gemischt | nahe Echtzeit möglich

Last auf Quellsystem | gering (nur beim Refresh) | dauerhaft, je nach Nutzung | selektiv | auf Fabric/Capacity, nicht auf Quell-DB

DAX-/Modell-Flexibilität | am höchsten | teils eingeschränkt; komplexe Logik kann teuer werden | flexibel je Tabelle | gut, aber abhängig vom Modell/Source

Typische Risiken | Refresh-Fenster, Modellgröße | Timeouts, langsame Queries | höhere Modell-Komplexität | Governance/Performance-Tuning im Lakehouse

Typischer Nutzen | „Dashboards fliegen“ | „immer aktuell, ohne Kopien“ | „best of both“ | „Gold-Daten im OneLake für viele Nutzer-Tools“

Wann welcher Modus sinnvoll ist (Use Cases)

• Import: KPI-Dashboards, Plan/Ist, Controlling-Modelle mit vielen Measures. Nutzen: Nutzer bekommen schnelle Drilldowns, und die IT kann Last und Refresh-Zeiten steuern.

• DirectQuery: sehr große Daten, sehr häufige Änderungen oder wenn Daten nicht dupliziert werden sollen. Nutzen: aktuelle Zahlen ohne zusätzliche Speicherhaltung; Voraussetzung ist eine performante Quelle (z.B. SQL) und saubere Modellierung.

• Dual/Composite: wenn große Faktentabellen live bleiben sollen, aber Dimensionen (Datum, Kunde, Produkt) extrem schnell filtern müssen. Nutzen: Interaktionen fühlen sich wie Import an, ohne alles zu importieren.

Mini-Story: Ein Vertriebsreport mit Millionen Buchungszeilen war als DirectQuery träge, weil jede Slicer-Änderung neue Queries erzeugte. Nach Umstellung auf Dual für Dimensionen plus eine importierte Aggregationstabelle wurden Standardfragen („Umsatz nach Monat/Region“) sofort beantwortet, während Detail-Drilldowns weiter live blieben.

Entscheidungsrahmen: Datenvolumen, Refresh, Performance

Diese Checkliste hilft beim choosing storage ohne „kommt darauf an“-Gerede:

• Datenvolumen: klein/mittel und gut refreshbar → Import. Sehr groß oder rechtlich/organisatorisch nicht kopierbar → DirectQuery oder Direct Lake.

• Aktualisierungsfrequenz: täglich/mehrmals täglich reicht oft Import mit Incremental Refresh. Minutenaktuell oder „immer jetzt“ → DirectQuery oder Direct Lake.

• Performance-Erwartung: viele DAX-Measures, komplexe Filter, viele Nutzer → lieber Import oder Composite mit Aggregations (aggregation tables). Reines DirectQuery nur, wenn die Quelle das zuverlässig trägt.

Konfiguration und Migration zwischen Modi

Konfiguration erfolgt in Power BI Desktop pro Tabelle (Storage Mode). Ein pragmatisches Vorgehen reduziert Risiko und Zeitaufwand:

• Start: MVP im Import, um Semantik, KPIs und DAX zu stabilisieren (messbar: Ladezeiten, Nutzerfeedback, Refresh-Stabilität).

• Skalierung: identifiziere teure Tabellen und stelle selektiv auf DirectQuery um; setze Dual für Dimensionen und prüfe Aggregations.

• Migration nach Fabric: Wenn Daten als Delta Tables im Lakehouse liegen, kann Direct Lake sinnvoll sein; Ziel ist, dass auch nicht-IT-affine Nutzer auf saubere Gold-Daten zugreifen und in Power BI oder Excel sofort losbauen können.

Wichtig: Nach einer Umstellung ändern sich Query-Pläne und Performance-Profil. Plane daher Regressionstests (Top-10 Reportseiten, Kernfilter, Refresh) fest ein.

Kompatibilität: Modellerstellung, Datenquellen, Live Connection

DirectQuery ist nicht jede Datenquelle gleich gut geeignet: Quellen mit schwacher SQL-Übersetzung, fehlenden Indizes oder hoher Latenz werden schnell zum Bottleneck. Live Connection ist ein Sonderfall: Der Report verbindet sich zu einem externen Modell (z.B. SSAS/Azure Analysis Services) und ergänzt keine eigenen importierten Tabellen im selben Modell; damit ähnelt es „DirectQuery auf ein semantisches Modell“ und schiebt Modellierung in die zentrale Instanz.

Best Practices je Storage Mode

• Import: Incremental Refresh nutzen, Modell schlank halten, Sternschema bevorzugen, Measures statt berechneter Spalten, Refresh-Fenster operationalisieren.

• DirectQuery: Query-Last minimieren (weniger Visuals pro Seite, klare Filterpfade), Quelle optimieren (Indizes, Views), DAX-Logik simpel halten, Timeouts und Gateway stabil betreiben.

• Dual/Composite: Dimensionen als Dual, Fakten strategisch (DirectQuery oder Import), Aggregations für Standardfragen, konsequente Governance damit kein „Hybrid-Chaos“ entsteht.

FAQ zu Storage Modes

Was sind die häufigsten Ursachen für langsame Reports bei DirectQuery?

Zu komplexe Visuals, fehlende Indizes/Partitionierung in der Quelle, zu viele gleichzeitige Nutzer und schlechte Modellierung (kein Sternschema) sind typische Treiber.

Kann man Import und DirectQuery mischen?

Ja, über composite models. Dual ist dabei ein wichtiger Baustein, weil Dimensionen extrem häufig genutzt werden und sonst jede Interaktion Queries auslöst.

Ist Direct Lake automatisch besser als Import?

Nein. Direct Lake ist stark, wenn Daten sauber als Delta Tables im Lakehouse liegen und Governance/Performance passen. Für viele KPI-Modelle bleibt Import die stabilste Performance-Wahl.

Welche Begriffe sollte das Team sicher verstehen?

Import, DirectQuery, Dual, Direct Lake, Refresh, DAX, Aggregations, Live Connection und semantic models – sonst werden Entscheidungen schnell zufällig statt systematisch.

Glossar

• Import: Daten werden in Power BI gespeichert; Abfragen laufen in-memory.

• DirectQuery: Power BI sendet Queries an die Quelle; Daten bleiben „dort“.

• Dual: Tabelle kann je nach Abfrage Import- oder DirectQuery-Verhalten annehmen.

• Composite model: Mischmodell aus Import/DirectQuery (inkl. Dual).

• Direct Lake: Abfrage von Lakehouse/Delta Tables (Fabric/OneLake) ohne klassischen Import.

Wortanzahl Text: 780