Power BI Performance Optimization: 10 Ways to Speed Up Reports

Why does Power BI performance get worse over time?

Most slow reports don’t start out slow.

A team builds a report with a few pages, a manageable dataset, and some straightforward measures. Then the report gets useful. More people start using it. New business requirements come in. A few more tables get added. Then a few more calculated columns, some extra slicers, a couple of DAX measures that seemed harmless at the time.

Six months later, a page that used to open in two seconds takes 15.

That gradual slowdown is common because Power BI environments tend to grow faster than anyone expects.

For businesses already relying on Power BI, the problem can spread beyond one slow dashboard:

• users stop opening reports and go back to Excel
• scheduled refreshes start taking longer
• development teams spend more time troubleshooting
• people begin questioning the data when the dashboard itself feels unreliable

The first step isn’t rebuilding the report. Find out where the extra work is coming from.

Microsoft’s guidance points to the semantic model, data reduction, relationships, DAX, and query behavior as key parts of Power BI performance. (Microsoft)

How do you improve Power BI performance by fixing the data model?

Start with the model.

When the semantic model is messy, every visual has to work around that mess. Cleaning up one DAX expression won’t solve much if the underlying structure is still doing unnecessary work.

A star schema is usually a solid starting point. You have a central fact table for transactions or events, surrounded by dimensions such as Date, Product, Customer, or Region. Microsoft recommends this approach for Power BI semantic models because it supports efficient filtering and aggregation. (Microsoft)

A sales model might look like this:

Compare that with a model where 20 or 30 tables are linked through a web of relationships. You can make that work, but troubleshooting becomes much harder.

What should you check in the model?

Look for:

1. Fact tables representing clear business processes
2. Dimensions used for filtering and grouping
3. Unnecessary fact-to-fact relationships
4. Many-to-many relationships that don’t have a clear reason to exist
5. Duplicate or redundant tables
6. Bidirectional relationships that aren’t actually needed

A good test is simple: can someone new to the project understand the model in a few minutes?

If the answer is no, performance may not be your only problem.

How do unused columns and high cardinality affect Power BI performance?

Every column you bring into an Import model has a cost.

That doesn’t mean every extra column will noticeably slow a report. But once a model gets large, unnecessary fields start adding up. Microsoft recommends removing columns and rows that aren’t needed for analysis because doing so can reduce model size and processing requirements. (Microsoft)

High-cardinality columns deserve special attention.

Think about a few examples:

• transaction IDs
• URLs
• timestamps
• long product descriptions
• unique text identifiers

A Region column might contain 10 values. A transaction ID column could contain millions.

Those two fields don’t have the same storage profile.

What should you remove?

Review columns that are:

• not used in visuals
• not part of a relationship
• not referenced by measures
• leftovers from old report versions
• full timestamps when the report only needs dates
• long descriptive text that users never analyse

Don’t delete fields just because they’re invisible on a report page. Check dependencies first.

Can numeric keys help?

They can, particularly when replacing high-cardinality text keys in an Import model. Microsoft notes that numeric data can be more storage-efficient than text in relevant scenarios. (Microsoft)

Still, don’t convert every identifier to a number just because you can. A code like 00124 may need to stay text for business reasons.

When should you use measures instead of calculated columns?

This is one of those Power BI decisions that gets oversimplified.

Calculated columns and measures aren’t interchangeable.

A calculated column is evaluated when the model is refreshed, and the result is stored. A measure is calculated when a report query needs it and responds to the current filter context. (Microsoft)

Suppose your sales table has five million rows and you create a calculated column just to produce a value that could be calculated from existing fields.

You may be storing millions of values that don’t need to exist physically in the model.

A measure could be enough:

Total Sales = SUM(FactSales[SalesAmount])

The calculation happens when it’s needed.

That doesn’t make calculated columns bad. They make sense when you need row-level values for categories, filters, relationships, or other model logic.

A useful rule is:

If the calculation needs to exist for every row, a calculated column may make sense. If it needs to respond to user filters, a measure is often the better fit.

Microsoft also recommends considering Power Query or the source system for transformations that don’t need to be DAX calculations. (Microsoft)

How can better DAX improve Power BI report performance?

DAX can produce the right number and still be doing far more work than necessary.

One common issue is repeating the same expression multiple times. Variables can help.

For example:

Sales Growth % =

VAR PriorYearSales =

    CALCULATE(

        [Sales],

        PARALLELPERIOD(‘Date'[Date], -12, MONTH)

    )

RETURN

    DIVIDE(

        [Sales] – PriorYearSales,

        PriorYearSales

    )

The variable gives the expression a name and lets you reuse the result. Microsoft also recommends variables because they can improve DAX performance and make measures easier to maintain. (Microsoft)

Be careful with FILTER

If you can express a filter directly, that’s usually cleaner than filtering an entire table with FILTER.

For example:

CALCULATE(

    [Sales],

    Product[Category] = “Electronics”

)

Microsoft recommends Boolean filter expressions as filter arguments when they can do the job, while FILTER is better suited to cases that genuinely require a more complex table expression. (Microsoft)

What about SUMX and other iterator functions?

Don’t treat SUMX or FILTER as bad functions. They’re useful.

The problem is using row-by-row iteration over a huge table when a simple aggregation would produce the same result.

If this:

SUM(FactSales[SalesAmount])

does the job, there’s little reason to make the engine iterate through the table unnecessarily.

How does Power Query query folding affect refresh performance?

Power Query and DAX have different jobs.

Power Query handles data preparation. DAX handles calculations in the model and report.

One of the most useful Power Query concepts for performance is query folding. When a transformation can be pushed back to the source, the source system performs that work instead of Power BI pulling all the raw data and processing it locally. (Microsoft)

Consider a SQL table with hundreds of millions of transaction rows.

If Power Query can send a filter back to SQL Server, the database might return only the records needed for the model. That’s very different from loading the whole table first and filtering afterward.

What should you check?

Review the transformation steps in Power Query and see whether folding is being preserved.

This matters particularly for large relational sources. Microsoft recommends keeping query folding where possible, especially for large models and DirectQuery scenarios. (Microsoft)

For some workloads, the right answer may be a SQL view or a source-side transformation rather than another Power Query step.

Don’t move everything upstream just for the sake of performance, though. Someone still has to maintain it.

How do relationships affect Power BI performance?

Relationships decide how filters move through the model. Get them wrong and the effects can show up in places you weren’t expecting.

A common example is widespread use of bidirectional relationships.

They’re useful in some models, but if every table is filtering every other table, the model becomes harder to reason about and query behavior can become more expensive. Microsoft recommends minimizing unnecessary bidirectional relationships. (Microsoft)

Watch for these patterns

Too many bidirectional relationships

Sometimes a single model-wide setting creates more problems than it solves.

Fact-to-fact relationships

Joining two large transactional tables directly often leads to awkward filter paths.

Unclear many-to-many designs

Many-to-many relationships are valid when the business problem calls for them. They shouldn’t become the default solution whenever two tables won’t join cleanly.

Poor key choices

Where appropriate, stable integer keys can be more efficient than large text keys, especially in high-volume models.

The aim isn’t to have as few relationships as possible. It’s to make the relationships predictable.

How many visuals should a Power BI report page have?

There’s no magic rule saying every page must have exactly 8 or 10 visuals.

What matters is how much work those visuals create.

Every visual sends a query to the semantic model, so a page packed with charts, cards, tables, slicers, and custom visuals can generate a surprisingly large workload. Microsoft recommends limiting unnecessary visuals and keeping report pages focused. (Microsoft)

A few practical changes can help:

• combine related KPIs where one visual can replace several
• move detailed analysis to drill-through pages
• use report tooltips for information that doesn’t need to stay visible
• remove duplicate charts
• review unnecessary visual interactions
• keep large detail tables off the main summary page

A page with six complicated visuals can easily be slower than one with twelve simple ones.

So don’t optimize by counting boxes. Open Performance Analyzer and see what’s actually happening.

Which is faster for Power BI: Import, DirectQuery, or Composite?

It depends on what the report needs.

Import stores data in Power BI’s in-memory engine. DirectQuery leaves data in the source and sends queries back to it. Composite models combine storage modes where the architecture calls for it. (Microsoft)

Should you always use Import?

Not necessarily.

If the business needs near-real-time data, DirectQuery may be appropriate. If the source database is already under heavy load, though, putting more interactive queries against it may make things worse.

That’s why storage mode is an architecture decision, not simply a speed setting.

When DirectQuery is involved, source-side indexing, SQL design, concurrency, and capacity all become part of the performance picture.

When should you use Power BI incremental refresh?

Incremental refresh is useful when a large table keeps growing but old records rarely change.

Without it, a refresh may repeatedly process years of historical data just to pick up a small amount of new information.

With incremental refresh, Power BI can partition the table and refresh only the periods you’ve configured. Microsoft documents this as a way to reduce refresh work and manage large, growing datasets more efficiently. (Microsoft)

Imagine a sales table covering five years.

If only the last few weeks can change, there’s little value in treating all five years as equally active data.

The right refresh window depends on the business rules. If orders can be corrected for 90 days, refreshing only the last seven days won’t protect you from stale historical changes.

So the refresh policy should follow the data process.

How do you diagnose a Power BI slow report before changing anything?

This is where a lot of teams waste time.

Someone notices a report is slow, rewrites a few measures, removes a chart, changes a relationship, and waits to see what happens. If the page is still slow, they do it again.

A better approach is to measure first.

1. Start with Performance Analyzer

Power BI’s Performance Analyzer shows how long visuals take to load and helps identify which part of the page is consuming time. (Microsoft)

2. Find the expensive visual or interaction

A page might have ten visuals, but one matrix could be responsible for most of the delay.

3. Check the underlying DAX

If one measure is expensive, inspect the logic rather than tweaking unrelated visuals.

4. Review the model

Look for excessive columns, high-cardinality fields, unnecessary relationships, and oversized tables.

5. Separate report speed from refresh speed

A report can open quickly and still have a terrible refresh process. Those are two different bottlenecks.

6. Check the Power BI Service

In production, also look at refresh history, capacity behavior, concurrency, and other service-level factors.

Tools such as DAX Studio can help when you need deeper analysis of DAX query behavior.

The point is simple: don’t optimise the thing that’s easiest to change. Optimise the thing that’s actually slow.

What is the best order for Power BI performance optimization?

When several things could be wrong, the order matters.

A practical sequence looks like this:

There’s a reason the model is near the top of the list.

If you’ve got millions of unnecessary rows and a complicated relationship structure, spending an afternoon rewriting one measure probably won’t move the needle much.

What should you look for when choosing a Power BI performance consulting partner?

Not every slow report needs outside help. But once the environment includes multiple datasets, shared semantic models, complex DAX, several source systems, or capacity issues, a second set of experienced eyes can save a lot of time.

When comparing consulting partners, look at:

Perceptive Analytics provides Power BI consulting services across areas including data modeling, DAX optimization, dashboard development, governance, and performance tuning.

For a broader view of what an engagement can involve, see What Does Power BI Consulting Actually Include?.

You can also review the Power BI consulting firm selection guide for governance and data-quality considerations.

What are the 10 most practical ways to improve Power BI performance?

Here’s the checklist I’d use when reviewing a report that’s starting to drag:

Not every report needs all ten fixes.

Sometimes the culprit is one badly designed table. Sometimes it’s a single measure. Sometimes the source database is the real bottleneck.

That distinction matters.

Key Takeaways

When a Power BI report slows down, resist the urge to start deleting charts.

Start with the model. Check the data volume. Look at DAX. Review relationships and query folding. Then examine the report page and storage mode. Use Performance Analyzer to see where time is actually going.

For established Power BI environments, that approach can often turn a vague “the dashboard is slow” complaint into a very specific engineering problem.

Perceptive Analytics works with organizations on Power BI consulting, including performance tuning, data modeling, DAX optimization, governance, and enterprise reporting.