Home › Slow Power BI report
Why is my Power BI report so slow, and what fixes it?
Almost never the row count, almost always the model. A flattened table instead of a star schema, measures iterating over millions of rows, bidirectional relationships and calculated columns that belong in the source. Buying more memory will not help. Remodelling and rewriting the measures will: in a recent engagement the heaviest visual went from over 24 seconds to 1.3 seconds.
Measure first, then touch anything
The most common mistake with a slow report is optimising before you know where the time goes. We measure three things first:
- Server Timings in DAX Studio: how much time goes to the formula engine, how much to the storage engine
- VertiPaq Analyzer: which columns cost the most memory, and which you can simply drop
- Query analysis per visual: which visual is the culprit, because it is usually just one
The four causes we see most
1. No star schema
One wide table with everything in it feels tidy and is the worst case for the engine. Separating facts from dimensions usually gives the largest single jump.
2. Measures that count row by row
Iterator functions over millions of rows, nested FILTER calls, and logic that belonged in the source or in a calculated table.
3. Bidirectional relationships
Convenient while building, expensive at runtime, and they make the result unpredictable. That last part is worse than being slow.
4. Too many high-cardinality columns
Timestamps down to the second, technical keys and free-text fields nobody uses. They eat memory and slow every query.
What that delivered
| Situation | Before | After |
|---|---|---|
| Heaviest visual, project controlling | over 24 seconds | 1.3 seconds |
| Most visuals | — | under 300 milliseconds |
| Report landscape at a water authority | 200+ Oracle reports | 75 dashboards |
In 2024, Sonny assisted us in a business transformation program by providing hands-on support for the development of several PowerBI solutions, specifically he focussed on the optimization and efficiency improvements of an existing data model.
Half an hour is enough to know whether we fit
No slide deck and no quote at the end. We walk through your sources, your definitions and your biggest frustration.
Book half an hourFrequently asked questions
Why is my Power BI report slow?
Almost never because of row count, almost always because of the model. A flattened table instead of a star schema, measures iterating over millions of rows, bidirectional relationships, and calculated columns that belong in the source. Buying more memory does not fix any of those. Remodelling does.
How do you find out where the time goes?
With DAX Studio and Server Timings you see, per visual, how much time goes to the formula engine and how much to the storage engine. VertiPaq Analyzer shows which columns cost the most memory. Without that measurement you are guessing, and guessing usually optimises the wrong thing.
How fast should a report be?
For a dashboard people open daily, under 2 seconds is a fair norm and under 700 milliseconds per visual is comfortable. In a recent engagement the heaviest visual went from over 24 seconds to 1.3 seconds, with most visuals under 300 milliseconds.
Do we have to rebuild everything?
Usually not. The report pages tend to survive; the model underneath is what gets rebuilt and the measures get rewritten. Users see the same screen, only fast.
Can you do an analysis first?
Yes. A short, paid review of your model and your heaviest report at a fixed price. It tells you where the time goes, what the expected gain is and what it costs to get it. Then you decide whether to continue.