.png){kind=small}
Power BI Performance optimieren
Aktualisiert: 27. Aug.
Langsame Power-BI-Berichte sind selten nur ein technisches Ärgernis. Wenn Seiten lange laden, Filter träge reagieren oder Refreshes regelmäßig zu lange dauern, verliert Reporting schnell an Akzeptanz. Die Lösung ist aber nicht, wahllos DAX zu optimieren oder die Capacity hochzuskalieren. Zuerst muss klar sein, welche Art von Performance-Problem überhaupt vorliegt – und auf welcher Ebene es entsteht.
Power BI Performance ist ein End-to-End-Thema. Ein langsames Visual kann durch DAX verursacht werden. Oder durch das Datenmodell. Oder durch DirectQuery. Ein langsamer Report im Service kann dagegen mit einer überlasteten Capacity zusammenhängen, obwohl derselbe Bericht in Power BI Desktop schnell reagiert.
Deshalb gilt: Erst messen. Dann die Ebene bestimmen. Erst danach optimieren.
Zuerst das Symptom klassifizieren
„Power BI ist langsam“ ist noch keine brauchbare Fehlerbeschreibung.
Der Bericht öffnet langsam: Viele Visuals, Modellladezeit, Capacity oder Netzwerk können eine Rolle spielen.
Einzelne Visuals oder Filter reagieren langsam: Visual-DAX, Measures, Beziehungen, Datenmenge oder DirectQuery sind typische Kandidaten.
Der Bericht läuft gut, aber der Refresh dauert zu lange: Power Query, Query Folding, Datenquelle, Datenvolumen, Gateway und Partitionierung gehören auf den Prüfstand.
Nur der Power BI Service ist langsam: Dann müssen zusätzlich Capacity, Throttling, Gateway und Netzwerk geprüft werden.
Diese Unterscheidung spart häufig mehr Zeit als jede einzelne DAX-Optimierung.
Der Daten-WG Performance-Check: sechs Ebenen
Für eine systematische Analyse prüfen wir sechs Ebenen – in genau dieser Reihenfolge:
Nutzung und Berichtsziel
Visual und konkrete Query
DAX und Formula/Storage Engine
Datenmodell und VertiPaq
Datenquelle, Speichermodus und Refresh
Power BI Service, Gateway und Capacity
Nicht jede Ebene muss optimiert werden. Sie muss zunächst ausgeschlossen oder bestätigt werden.
Die Diagnosekette ist damit klar: Symptom → Ebene → Messwerkzeug → Ursache → Änderung → Retest.
1. Nutzung und Berichtsziel: Ist der Report selbst das Problem?
Bevor Tools geöffnet werden, lohnt sich eine fachliche Frage: Was soll dieser Bericht eigentlich leisten? Ein Management-Dashboard, eine operative Detailanalyse und ein Exportwerkzeug haben unterschiedliche Anforderungen.
Probleme entstehen häufig, wenn eine Seite gleichzeitig Managementübersicht, Detailanalyse, Datentabelle, Self-Service-Einstieg und Exportoberfläche sein soll. Dann entstehen viele Visuals, Slicer und Interaktionen – und entsprechend viele Queries.
Gutes Reportdesign ist deshalb auch Performance-Design.
2. Performance Analyzer: Welches Visual ist tatsächlich langsam?
Jetzt beginnt die technische Diagnose. Der Performance Analyzer zeigt für einzelne Visuals, wie lange deren Laden dauert und welcher Anteil beispielsweise auf die DAX-Abfrage entfällt.
Wichtig 2026: Performance Analyzer steht sowohl in Power BI Desktop als auch beim Bearbeiten eines Berichts im Web zur Verfügung.
Der Einstieg sollte deshalb nicht lauten „Welche Measure sieht kompliziert aus?“, sondern: Welches Visual ist tatsächlich langsam – und welcher Teil seiner Laufzeit ist dafür verantwortlich?
Von Performance Analyzer direkt zur DAX Query View
Jedes Visual erzeugt eine DAX Query gegen das semantische Modell. Performance Analyzer kann diese Query anzeigen beziehungsweise kopieren. In Power BI Desktop lässt sie sich direkt in der DAX Query View ausführen.
Welche Daten fordert das Visual tatsächlich an?
Ist das Ergebnis schon als Query langsam?
Welche Measures werden berechnet?
Ändert eine DAX-Anpassung tatsächlich die Laufzeit?
Bei DirectQuery können zusätzlich die übersetzten SQL- beziehungsweise KQL-Abfragen sichtbar werden. Damit lässt sich die Abfrage eines langsamen Visuals vom eigentlichen Report lösen.
3. DAX: messen statt Formeln nach Gefühl vereinfachen
Wenn die Query selbst langsam ist, wird DAX interessant. Typische Kandidaten sind Iteratoren über große Tabellen, unnötig komplexe FILTER-Ausdrücke, wiederholte teure Berechnungen, ungünstige Kontextübergänge oder hohe Kardinalität in Filteroperationen.
Aber komplizierter DAX ist nicht automatisch langsamer DAX – und kurzer DAX ist nicht automatisch schnell.
Für die tiefe Analyse kann die aus Performance Analyzer gewonnene Query in DAX Studio untersucht werden. Server Timings und Query Plan helfen dabei, Formula Engine und Storage Engine besser zu verstehen.
Arbeitsweise: Baseline messen → Hypothese → Änderung → erneut messen.
Visual Calculations sind kein Performance-Schalter
Visual Calculations können bestimmte Berechnungen erheblich vereinfachen. Daraus folgt aber nicht, dass sie grundsätzlich schneller sind. Je nach Szenario können bereits berechnete Resultsets wiederverwendet werden – oder zusätzlicher Aufwand entstehen.
Auch hier gilt: Nicht Technologie auswählen, weil sie neuer ist – sondern messen.
4. Datenmodell und VertiPaq: Oft liegt die Bremse darunter
Selbst perfekter DAX kann ein unnötig schweres Modell nicht vollständig kompensieren. Bei Importmodellen verarbeitet Power BI Daten über die VertiPaq Engine. Je kleiner und sauberer das Modell, desto besser sind normalerweise Speicherverbrauch, Refresh- und Query-Performance.
unnötige Spalten entfernen
unnötige Zeilen vermeiden
Daten gegebenenfalls aggregieren
Datentypen bewusst wählen
unnötige Modellkomplexität vermeiden
Kardinalität wird schnell teuer
Besonders relevant ist die Anzahl unterschiedlicher Werte einer Spalte. Eine ID-Spalte mit Millionen eindeutiger Textwerte kann erheblich mehr Speicher beanspruchen als eine niedrig kardinale Kategoriespalte.
Mit dem VertiPaq Analyzer lassen sich Kardinalität, Datenvolumen, Dictionary-Größe, Relationship-Größe und der Anteil einzelner Tabellen am Gesamtmodell analysieren.
Die bessere Frage lautet nicht „Ist unser PBIX groß?“, sondern: Welche konkrete Tabelle, Spalte oder Beziehung macht unser Modell groß?
Sternschema bleibt Performance-Grundlage
Die tiefe Modellierungslogik behandeln wir separat in Datenmodellierung in Power BI.
Für die Performance-Diagnose reicht die zentrale Aussage: Klare Fakt- und Dimensionstabellen, eindeutige Beziehungen und kontrollierte Kardinalitäten machen DAX einfacher und Performance berechenbarer.
5. Speichermodus: Import, DirectQuery und Direct Lake nicht gleich behandeln
Import: Für maximale interaktive Performance bleibt Import häufig der einfachste Ausgangspunkt. Daten liegen komprimiert im semantischen Modell und Queries müssen nicht ständig zum Quellsystem zurück.
DirectQuery: Hier verschiebt sich ein großer Teil der Performance-Verantwortung zur Quelle. Ein Power-BI-Measure lässt sich nur begrenzt retten, wenn die zugrunde liegende SQL-Abfrage bereits langsam ist. Query-Reduction-Techniken wie Apply-Buttons für Slicer und Filter können unnötige Abfragen reduzieren.
Direct Lake: In Fabric kann Direct Lake sehr hohe DAX-Performance bieten. Bei bestimmten Konstellationen kann eine Query jedoch auf DirectQuery zurückfallen. Wenn ein Direct-Lake-Bericht unerwartet langsam ist, sollte deshalb geprüft werden, ob die Query tatsächlich noch in Direct Lake läuft.
Power Query und Refresh: Query Folding ist kein Nebenthema
Ein Bericht kann beim Konsum schnell sein und trotzdem operative Probleme verursachen, weil sein Refresh zu lange dauert. Hier ist Query Folding besonders wichtig.
Das Prinzip lautet: Transformationen möglichst dort ausführen, wo die Daten liegen, statt Millionen Zeilen unnötig nach Power BI zu transportieren.
Die bessere Architekturfrage: Welche Transformation gehört in die Quelle, welche in eine zentrale Datenplattform und welche tatsächlich ins Semantic Model?
6. Service und Capacity: Ist der Bericht langsam – oder die Umgebung?
Ein häufig unterschätzter Test lautet: Ist der Bericht auch in Desktop langsam? Wenn nicht, verschiebt sich die Diagnose in Richtung Gateway, Netzwerk, Concurrent Users, Capacity-Auslastung, andere Workloads auf derselben Capacity oder Throttling.
Bei Fabric- beziehungsweise Premium-Kapazitäten ist die Fabric Capacity Metrics App das zentrale Werkzeug, um compute-intensive Items und Operationen zu identifizieren.
Mehr als 100 Prozent Capacity heißt nicht automatisch „zu klein“
Fabric verwendet Bursting und Smoothing. Kurzfristige hohe Belastung kann deshalb mehr als 100 Prozent Usage erzeugen, ohne dass Benutzer zwangsläufig schlechte Performance erleben.
Hohe Utilization allein beweist noch kein Throttling. Entscheidend sind die konkreten Delay-/Rejection-Werte und der Zeitraum.
Die richtige Reihenfolge lautet: Capacity Metrics prüfen → Throttling bestätigen → verursachendes Item beziehungsweise Operation bestimmen → erst dann skalieren.
Die Kosten- und Capacity-Perspektive vertiefen wir in Microsoft Fabric Kosten verstehen.
Wann Optimieren nicht mehr reicht
Manchmal ist ein Neuaufbau wirtschaftlicher. Typische Warnsignale sind unklare Measures, konkurrierende Kennzahldefinitionen, historisch gewachsene Faktentabellen, schwer nachvollziehbare Beziehungen oder Geschäftslogik, die ungeordnet im PBIX verteilt ist.
Dann ist schlechte Performance möglicherweise nur ein Symptom eines größeren Architekturproblems.
Performance als Teamstandard
Performance sollte nicht erst untersucht werden, wenn Nutzer sich beschweren. Ein pragmatischer Review vor Veröffentlichung sollte mindestens Report, Query, Modell, Datenzugriff und Betrieb abdecken.
Report: Anzahl und Zweck der Visuals, große Tabellen/Matrizen, Interaktionen und Slicer
Query: auffällige Performance-Analyzer-Werte und kritische DAX Queries
Modell: Tabellen-/Spaltengröße, Kardinalitäten, Beziehungen und Modellgröße
Datenzugriff: Query Folding, Storage Mode, DirectQuery-/Direct-Lake-Verhalten
Betrieb: Refresh-Zeit, Gateway, Capacity und Throttling
Damit wird Performance von einer Feuerwehrübung zu einem Qualitätsstandard.
Die kompakte Diagnosekette
Symptom reproduzieren: Was genau ist langsam?
Visual messen: Performance Analyzer.
Query isolieren: DAX Query View.
Engine analysieren: bei Bedarf DAX Studio.
Modell prüfen: VertiPaq Analyzer, Beziehungen und Kardinalitäten.
Datenpfad prüfen: Import, DirectQuery, Direct Lake, Query Folding.
Betriebsumgebung prüfen: Gateway, Netzwerk, Capacity Metrics und Throttling.
Änderung durchführen und erneut messen.
Ohne Retest gibt es keine Optimierung – nur eine Veränderung.
Fazit: Gute Power BI Performance beginnt mit der Diagnose
Power BI Performance optimieren heißt nicht, pauschal DAX umzuschreiben, Visuals zu löschen oder mehr Capacity zu kaufen. Die entscheidende Fähigkeit besteht darin, einen Engpass auf die richtige Ebene zurückzuführen.
Visual → Query → DAX → Modell → Datenquelle → Betrieb
Die wichtigste Regel lautet deshalb: Erst messen, dann optimieren – und nach jeder Änderung erneut messen.
So verbessert ihr nicht nur die Geschwindigkeit einzelner Reports, sondern gleichzeitig Datenmodelle, Entwicklungsstandards und die Wartbarkeit der gesamten Power-BI-Landschaft.
Der nächste sinnvolle Schritt
Wenn einzelne Power-BI-Berichte langsam sind, können wir im Power BI Coaching direkt an realen Modellen, Measures und Reports arbeiten – von Performance Analyzer und DAX bis hin zu Datenmodell, Power Query und Storage Mode. Power BI Coaching ist dafür der passende Einstieg.
