Power BI performance optimisation — and when to rebuild instead

Slow Power BI shows up in three ways, and they usually arrive together. A page takes ten, twenty or forty seconds to render, so managers stop opening it. The overnight refresh fails twice a week, or runs for three hours and finishes after the people who needed it have started their day. And two reports that should agree do not, because each carries its own copy of the logic.

None of these is mysterious. Each has a small set of causes that can be measured, and each measurement points at a fix. This page lists what we measure, what we commonly find, how we decide whether to patch or rebuild, and what the health check delivers. It is the entry point; the fixes are quoted from what it finds.

Eight causes account for most slow reports. Each is listed with the fix, because the fix is usually smaller than the symptom suggests.

• Imported columns nobody uses. Every column in the source was loaded, including the ones no visual or measure touches, and the model is three times the size it needs to be. Fix: remove them in Power Query; the model shrinks and every page speeds up.
• No date table. Time intelligence is written against a date column in the fact table, so every year-to-date measure does more work than it should and comparable-period logic is inconsistent. Fix: a proper date table marked as such, with the fiscal year and the Ramadan and Eid periods as attributes, and the measures rewritten against it.
• Many-to-many relationships. Two tables joined on a non-unique column, usually because a bridge table was skipped, making every filter ambiguous and every total suspect. Fix: a proper dimension or bridge table and single-direction relationships.
• Calculated columns instead of measures. Row-by-row calculations stored in the model, recalculated on every refresh and taking memory on every row. Fix: convert to measures where the value is an aggregate, or move to Power Query where it is a row attribute.
• Unfolded queries against Tally or SQL exports. A filter or a merge step placed after a step the source cannot fold, so the entire table is pulled across the gateway before the filter is applied. Fix: reorder the steps or push the logic into a view, so the source does the work.
• Too many visuals on a page. Forty visuals generate forty or more queries every time a slicer changes. Fix: one question per page, fewer visuals, and drill-through for the detail instead of showing it all at once.
• Auto date/time left on. Power BI builds a hidden date hierarchy for every date column in the model, quietly multiplying its size. Fix: turn it off and use the date table.
• Row-level security applied inefficiently. Security rules written as lookups over the fact table, evaluated for every query, so a multi-entity model is slow for exactly the users it was secured for. Fix: rules on the dimension tables, with the entity key propagated through single-direction relationships.

A report that is fast but refreshes unreliably is still a report nobody trusts, so refresh is treated as its own set of findings. Four things decide it.

• Gateway placement: the gateway should sit close to the source, on a machine that is on when the refresh runs, under a service account that does not expire. A gateway on the finance manager’s laptop, or on the same machine as Tally where the ODBC driver needs Tally open, is the most common cause of a failed refresh in a UAE finance estate.
• Incremental refresh: loading only the recent partition each night instead of the entire history, so a five-year fact table refreshes in minutes. This needs a proper date column and folding queries, which is why it is a fix that follows the others.
• Source timeouts: a query that runs for longer than the source or the gateway allows, usually because it is unfolded. The fix is folding first and, where the source is simply slow, a staging step that lands the data before the model reads it.
• Alerting: a refresh failure that nobody sees until Sunday’s meeting is a process failure, not a technical one. Failure alerts go to a named owner, and under a managed service they come to us at the same time.

The health check is a fixed price of AED 4,950 for one semantic model and its reports, agreed before we open anything. That is the whole amount. Nothing is added at checkout. The fixes are then quoted from the findings list: each finding carries its own estimate, you choose which to do, and the chosen set becomes a fixed-price scope.

Where the findings point to a rebuild rather than a set of fixes, the rebuild is quoted against them as its specification and starts at AED 15,500. That is an anchor rather than a price: what a rebuild costs depends on what the health check found, which is why it is quoted after the measurement rather than before it.