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 Aufstellung ist absichtlich praxisnah: Sie zeigt, wo du Risiken (Performance, Komplexität) erwartest und wo du messbaren Nutzen bekommst.

‍

Performance im Report:

• Import: s ehr hoch, planbar
• DirectQuery: stark quellenabhängig
• Dual (Composite): oft hoch, wenn gut designt
• Direct Lake: hoch bei passenden Lakehouse-Daten

Datenfrische:

• Import: nach Refresh
• DirectQuery: nahe Echtzeit möglich
• Dual (Composite): gemischt
• Direct Lake: nahe Echtzeit möglich

Last auf Quellsystem:

• Import: gering (nur beim Refresh)
• DirectQuery: dauerhaft, je nach Nutzung
• Dual (Composite): selektiv
• Direct Lake: auf Fabric/Capacity, nicht auf Quell-DB

DAX-/Modell-Flexibilität:

• Import: am höchsten
• DirectQuery: teils eingeschränkt; komplexe Logik kann teuer werden
• Dual (Composite): flexibel je Tabelle
• Direct Lake: gut, aber abhängig vom Modell/Source

Typische Risiken:

• Import: Refresh-Fenster, Modellgröße
• DirectQuery: Timeouts, langsame Queries
• Dual (Composite): höhere Modell-Komplexität
• Direct Lake: Governance/Performance-Tuning im Lakehouse

Typischer Nutzen:

• Import: „Dashboards fliegen“
• DirectQuery: „immer aktuell, ohne Kopien“
• Dual (Composite): „best of both“
• Direct Lake: „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.
  

‍

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.