Eine Aussage höre und lese ich immer wieder in Fabric-Projekten:
„Unser DirectLake-Modell war am Anfang extrem schnell. Jetzt werden einige Berichte plötzlich langsam.“
Die Ursache liegt häufig weder im Bericht selbst noch zwingend in der Datenmenge. Oft steckt etwas dahinter, das viele Entwickler zunächst gar nicht auf dem Schirm haben:
Der Wechsel von DirectLake auf DirectQuery
Das Missverständnis
Viele betrachten DirectLake als einen Betriebsmodus, der dauerhaft verwendet wird.
Tatsächlich versucht das Semantic Model zunächst, Abfragen direkt über DirectLake auszuführen. Unter bestimmten Bedingungen kann jedoch ein Fallback auf DirectQuery erfolgen.
Genau in diesem Moment ändern sich die Performance-Eigenschaften schlagartig.
Woran erkennt man das?
Typische Symptome sind:
- Einzelne Berichte werden plötzlich langsamer
- Manche Visuals reagieren deutlich träger als andere
- Die Performance schwankt stark
- Einfache Berichte bleiben schnell, komplexere Seiten werden langsam
Oft werden dann DAX, das Datenmodell oder sogar Microsoft Fabric selbst als Ursache vermutet.
Dabei liegt das eigentliche Problem häufig im verwendeten Ausführungsmodus.
Warum passiert ein Fallback?
Ein häufiger Grund sind Sicherheits- und Berechtigungskonzepte, beispielsweise:
- Row-Level Security (RLS)
- Object-Level Security (OLS)
- Bestimmte Modellkonfigurationen
Je nach Szenario können Abfragen nicht mehr vollständig über DirectLake verarbeitet werden. In diesen Fällen greift Fabric auf DirectQuery zurück.
Die eigentliche Gefahr
Viele Teams optimieren ihre Modelle ausschließlich für DirectLake.
Sobald jedoch DirectQuery verwendet wird, gewinnen bekannte Performance-Themen wieder erheblich an Bedeutung:
- Komplexe DAX-Logik
- Hohe Kardinalitäten
- Schlechte Modellierung
- Unnötige Joins
- Ineffiziente Filterpfade
Abfragen, die im DirectLake-Modus problemlos liefen, können dadurch plötzlich deutlich langsamer werden.
Was hilft wirklich?
Die wichtigsten Optimierungshebel sind:
✅ Sauberes Sternschema
✅ Reduzierung unnötiger Spalten
✅ Optimierte Delta Tables
✅ Voraggregationen für große Faktentabellen
✅ Effiziente DAX-Logik
✅ Bewusster Umgang mit Sicherheitskonzepten
Vor allem sollte man verstehen, wann und warum ein Fallback überhaupt auftritt. Nur dann lässt sich die Ursache gezielt analysieren und beheben.
Der häufigste Fehler
Viele Projekte konzentrieren sich ausschließlich auf die Optimierung des Berichts.
Dabei liegt das eigentliche Problem häufig eine Ebene tiefer:
- Datenmodell
- Lakehouse-Struktur
- Sicherheitskonzept
- Ausführungsmodus
Ohne Transparenz über diese Bereiche wird Performance-Tuning schnell zum Blindflug.
Mein Fazit
DirectLake gehört zu den spannendsten Technologien in Microsoft Fabric.
Dabei sollte jedoch eines klar sein:
DirectLake bedeutet nicht automatisch, dass jede Abfrage dauerhaft im DirectLake-Modus ausgeführt wird.
Wer große Enterprise-Modelle betreibt, sollte deshalb nicht nur sein Datenmodell kennen, sondern auch verstehen:
- Wann Fabric auf DirectQuery zurückfällt
- Warum dieser Wechsel erfolgt
- Welche Auswirkungen das auf die Performance hat
Denn in vielen Fällen ist nicht die Datenmenge das Problem – sondern ein unbemerkter Wechsel des Ausführungsmodus.
