When someone tells me a Power BI report is slow, the cause is rarely the visual or the capacity. It’s usually the model underneath. These are the checks I run first, and the habits I ask teams to build in from the start.
1. Model a star schema
Separate facts (events and transactions) from dimensions (who, what, where, when), and connect them with one-to-many relationships that filter in a single direction. Wide, flat tables and snowflaked chains of lookups make models bigger, DAX harder and results easier to get wrong. A clean star schema fixes more performance problems than any DAX trick.
2. Choose the storage mode deliberately
Import is still a great default for small and medium models with scheduled refresh. Direct Lake suits large Fabric datasets that already live as Delta tables in OneLake, because it reads them without a full import refresh. DirectQuery is for when you truly need to query the source live. Whichever you choose, make it a decision rather than an accident of how the first report was built.
3. If you use Direct Lake, optimise the Delta tables
Direct Lake performance depends on the tables it reads. Build gold as physical Delta tables rather than views, keep file counts under control with regular OPTIMIZE, and consider V-Order on tables that reports hit heavily. Check the guardrails for your Fabric SKU, and know whether your model uses Direct Lake on OneLake or on the SQL analytics endpoint, because only the latter can fall back to DirectQuery.
4. Cut columns and cardinality
The VertiPaq engine compresses by column, so every unused or high-cardinality column costs memory. Remove columns nobody reports on, split datetime values into separate date and time columns, prefer integer keys, and turn off Auto date/time in favour of one proper date table.
5. Practise basic DAX hygiene
Write measures instead of calculated columns wherever you can. Use variables to avoid repeating expressions and to make code readable. Use DIVIDE for safe division. Inside CALCULATE, filter on columns rather than wrapping a whole table in FILTER. Avoid bidirectional relationships unless you understand exactly why you need one.
6. Measure before you optimise
Don’t guess. Use Performance Analyzer in Power BI Desktop to find the slow visual, then copy its query into DAX query view or DAX Studio to see where time goes. VertiPaq Analyzer in DAX Studio shows which tables and columns take the most memory. Fix the biggest problem first, then measure again.
7. Automate your standards
Save models in the Power BI Project (PBIP) format with TMDL so they live in Git and changes can be reviewed. Run the Best Practice Analyzer in Tabular Editor to catch common modelling issues before they reach production. Standards that run automatically survive staff changes; standards in a wiki page don’t.
Wrapping up
Fast reports come from a good model, a deliberate storage mode and tidy DAX, in that order. Start with the star schema, measure with the right tools, and push heavy transformation upstream into the lakehouse where it belongs.
Leave a Reply