Why Your Power BI Report Is Slow — and How to Actually Fix It

Before buying Premium capacity to make a report faster, it's worth knowing that more capacity applied to a bad model buys a slightly faster bad model. Here are the six causes, ordered by how often they turn out to be the real one.

1. One flat table instead of a star schema

Importing a denormalized extract feels efficient — everything in one place. But Power BI's VertiPaq engine is built for star schemas: narrow fact tables surrounded by small dimension tables. Given one wide table, compression collapses and every filter scans the whole thing. Rebuilding as facts and dimensions routinely cuts model size by 70–90%, and speed follows.

2. High-cardinality columns you don't need

VertiPaq compresses by finding repetition. A column of unique values — transaction GUIDs, full timestamps, free-text notes — compresses to nearly nothing and inflates the model. Splitting datetime into a date column plus a separate time column often cuts model size dramatically on its own, because dates repeat and precise timestamps never do.

3. DAX measures that iterate row by row

Measures using FILTER over a whole table, or nested iterators like SUMX over unfiltered facts, force row-by-row evaluation instead of the engine's fast scan path. Filtering on a column rather than a table, and letting simple aggregations stay simple, usually removes the bottleneck without changing a single number on screen.

4. Bidirectional relationships and too many joins

Bidirectional cross-filtering is convenient and expensive; it makes the engine resolve ambiguous filter paths on every query. Set relationships to single direction by default and solve the rare exceptions with explicit DAX instead.

5. Doing transformation work at refresh time

Heavy merges, joins and custom columns in Power Query run on every refresh. That work belongs upstream — in SQL, in a view, or in the warehouse — where it runs once and stays queryable. This is the difference between a report that refreshes in ninety seconds and one that times out at 3 a.m. and greets you with stale data.

6. Visual sprawl on a single page

Every visual issues its own query. Twenty-five visuals on one page means twenty-five concurrent queries competing for the same capacity. Reports that feel sluggish despite a clean model are often just overcrowded — and splitting one page into three fixes it in an afternoon.

The order to work in

1. Open Performance Analyzer in Power BI Desktop and record the slow page. It tells you whether time goes to the DAX query, the visual rendering, or something else — and stops you optimizing the wrong thing.
2. Check the model size and column cardinality (DAX Studio, VertiPaq Analyzer). Remove what nothing uses.
3. Fix the schema before touching DAX. A star schema makes many "slow measure" problems disappear.
4. Push transformation upstream of Power Query.
5. Only then consider capacity.

The uncomfortable pattern: in most rescues, the slow report is a symptom and the actual problem is that nobody owns the model. Fixing one report buys you a month. Fixing the model ends the category of complaint.