Power BI DirectQuery: Definition, Mechanik, Abgrenzung

Power BI DirectQuery ist ein Verbindungsmodus in Power BI: Statt Daten vorab in den Power-BI-Speicher (VertiPaq-Modell, die interne Datenablage von Power BI) zu laden, holt der Bericht sie erst dann, wenn jemand auf einen Filter oder eine Kachel klickt. Jede Nutzerinteraktion löst eine Datenbank-Abfrage (SQL, die Sprache zum Abfragen von Datenbanken) an die angebundene Quelle aus; Antwortzeit und Rechenkosten des Berichts hängen deshalb daran, wie schnell und wie teuer diese Quelle antwortet.

Was ist Power BI DirectQuery?

DirectQuery ist einer von drei Datenverbindungs-Modi in Power BI. Die anderen beiden sind der Import-Modus (Daten werden regelmäßig in Power BI kopiert und dort gehalten) und das Composite Model (eine Mischung aus beiden). Welchen Modus ein Bericht benutzt, entscheidet sich beim Anbinden der Datenquelle und gehört zur Definition des Berichts-Datenmodells (Semantik-Modell, die Sammlung aus Tabellen, Beziehungen und Kennzahlen, aus der der Bericht seine Zahlen zieht). Ein späterer Wechsel setzt eine Neu-Anbindung der betroffenen Tabellen voraus. Der Modus lässt sich pro Tabelle setzen, sodass innerhalb desselben Modells DirectQuery-Tabellen und Import-Tabellen nebeneinander existieren können; dieses Muster heißt Composite Model.

Was Power BI im DirectQuery-Modus tatsächlich vorhält, ist ausschließlich das Metadaten-Modell: Tabellen-Schemata, Beziehungen, DAX-Kennzahlen, Rollen für Row-Level Security. Es liegen keine Zeilen im Semantik-Modell. Beim Öffnen des Berichts, bei jedem Filter, jedem Slicer-Klick und jedem Seitenwechsel erzeugt die Power-BI-Engine SQL-Abfragen, übersetzt sie in den Dialekt der jeweiligen Connector-Schicht und sendet sie an die Quelle. Der Connector zu Azure Databricks arbeitet dabei gegen ein SQL Warehouse als Ausführungsziel, der Snowflake-Connector gegen ein Warehouse in Snowflake, der SAP-HANA-Connector gegen die HANA-Engine. Die Konnektor-Liste ist geschlossen; Microsoft dokumentiert die unterstützten Datenquellen (u. a. Azure SQL Database, Azure Databricks, Azure Synapse, Snowflake, BigQuery, SAP HANA, SAP BW). Andere Quellen kennen den Modus nicht.

Der Modus existiert, weil zwei technische Grenzen des Import Mode ihn nötig machen: die Modell-Größenlimits im Power-BI-Dienst (1 GB in Pro-Kapazitäten, bis 100 GB komprimiert in Premium- und Fabric-Kapazitäten) und die Refresh-Fenster (8× pro Tag in Pro/PPU, bis 48× in Fabric F-SKUs). Für Faktentabellen mit Milliarden Zeilen und für Berichte mit Live-Daten-Anspruch reichen beide Grenzen nicht. DirectQuery umgeht sie, tauscht Modell-Größe und Refresh-Latenz aber gegen Query-Latenz zur Laufzeit und gegen Compute-Kosten auf Quell-Seite.

Betrieblich hat der Modus Konsequenzen, die im Semantik-Modell nicht sichtbar sind. Nicht alle DAX-Funktionen sind verfügbar: Zeitintelligenz-Funktionen wie SAMEPERIODLASTYEAR funktionieren nur mit einer korrekt konfigurierten Datumstabelle, komplexe Filter-Kontext-Manipulationen und einige Textfunktionen lassen sich nicht in SQL übersetzen und werden entweder blockiert oder mit Performance-Einbuße nachbearbeitet. Berechnete Spalten unterliegen Einschränkungen; berechnete Tabellen sind nicht möglich, weil sie eine Materialisierung im Modell voraussetzen würden. Aggregations-Tabellen (User-defined Aggregations) können Anfragen auf lokal importierte Aggregate umleiten, bevor der Query an die Quelle geht. Row-Level Security aus dem Unity Catalog oder aus einer SQL-Server-Datenmaske wirkt transitiv, weil jede Query im Kontext des angemeldeten Nutzers ausgeführt wird.

Abgrenzung zu Import Mode, Composite Model, Direct Lake und Databricks SQL Warehouse

DirectQuery wird häufig mit dem Gegen-Modus (Import Mode), mit dem Hybrid (Composite Model), mit einer neueren Fabric-Zugriffsschicht (Direct Lake) und mit dem darunterliegenden Compute-Objekt (Databricks SQL Warehouse) verwechselt oder gleichgesetzt. Die Abgrenzung verläuft entlang zweier Achsen: wo die Daten liegen (im Semantik-Modell versus in der Quelle) und wer die Query ausführt.

Begriff	Achse	Kernunterschied
Import Mode	Datenort	Power BI lädt Daten periodisch in das VertiPaq-Column-Store-Modell und beantwortet Abfragen aus diesem lokalen Speicher. Höchste Antwortzeit, voller DAX-Umfang, unabhängig von Quell-Verfügbarkeit; Preis sind Refresh-Latenz und Modell-Größenlimits.
Composite Model	Datenort	Hybrid aus Import- und DirectQuery-Tabellen im selben Semantik-Modell. Dimensionstabellen importiert, große Faktentabellen per DirectQuery. Aggregations-Tabellen leiten grobe Anfragen auf lokale Aggregate. Löst das Größen-Aktualität-Dilemma.
Direct Lake (Fabric)	Zugriffsweg	Fabric-spezifische Zugriffsschicht: Power BI liest OneLake-Parquet-Dateien direkt in den VertiPaq-Speicher, ohne SQL-Layer und ohne expliziten Refresh. Vereint Antwortzeit des Import Mode mit Aktualität von DirectQuery, ist aber an Fabric-Kapazitäten und Delta-Parquet-Storage gebunden.
Live Connection	Modell-Ownership	Verbindet Berichte direkt auf ein bestehendes Analysis-Services-Cube oder Power-BI-Semantik-Modell; das Modell gehört dabei der Quelle, der Bericht ergänzt keine eigenen Beziehungen oder DAX-Kennzahlen. DirectQuery hält ein eigenes Semantik-Modell; live aus der Quelle kommen nur die Zeilendaten.
Databricks SQL Warehouse	Rolle im Stack	Compute-Objekt (Classic, Pro, Serverless), das die DirectQuery-Abfragen ausführt. DirectQuery ist der Verbindungsmodus in Power BI, das SQL Warehouse die Rechenleistung, die die vom Modus erzeugten Queries beantwortet.

Am folgenreichsten ist die Trennung zwischen Modus und Compute-Objekt. „Power BI DirectQuery gegen ein Databricks SQL Warehouse" beschreibt die Beziehung sauber: der Modus definiert, dass zur Laufzeit gefragt wird; das Warehouse definiert, worauf gefragt wird und mit welcher Compute-Klasse. Modus-Entscheidungen (Import, DirectQuery, Composite) und Warehouse-Entscheidungen (Classic, Pro, Serverless) sind unabhängig und werden getrennt getroffen.

Beispiel: Operativer Umsatz-Bericht auf Databricks

Ein Handelsunternehmen führt eine Verkaufs-Faktentabelle mit 2 Milliarden Zeilen im Databricks Lakehouse. Der operative Bericht „Umsatz nach Filiale (aktuell)" soll den Datenstand bis zur letzten Kassenbuchung zeigen. Ein Import-Modell wäre nicht wirtschaftlich: 8× Refresh pro Tag wäre zu selten für „aktuell", ein permanenter Streaming-Import würde das 100-GB-Modellgrößen-Limit auf Premium-Kapazität sprengen.

Das Reporting-Team baut ein Semantik-Modell im DirectQuery-Modus gegen ein Databricks SQL Warehouse bi-powerbi-prod (Pro-Klasse, Photon aktiv, Auto-Stop nach 15 Minuten Inaktivität). Dimensionstabellen (Filiale, Artikel, Zeit) liegen als Import-Tabellen im Composite-Modell, weil sie klein sind und selten aktualisiert werden. Materialized Views in Databricks halten wiederkehrende Aggregate vor (Umsatz pro Filiale-Tag, Umsatz pro Warengruppe-Woche); das Warehouse liest im DirectQuery-Modus aus diesen Views und umgeht damit die Roh-Faktentabelle für Standard-Kacheln. Unity-Catalog-Row-Filter beschränken jede Query auf den Filial-Cluster des angemeldeten Nutzers, sodass ein Regional-Verantwortlicher nur die eigene Region sieht.

Antwortzeit eines Filter-Klicks liegt bei 1–3 Sekunden mit warmem Warehouse; DBU-Kosten skalieren mit der Nutzeraktivität, nicht mit der Faktentabelle. Der Bericht zeigt immer den aktuellen Umsatzstand, weil zwischen Nutzerinteraktion und Datenquelle kein Import-Refresh liegt. Für die parallel gebauten Management-Übersichten mit wöchentlicher Aggregation und geringem Nutzervolumen wählt dasselbe Team hingegen Import Mode, weil dort die niedrigere Antwortzeit und die entfallenden Query-Kosten den Ausschlag geben.