Almost every small business I’ve seen with a “slow” Power BI report blames the same thing: not enough licence, not enough capacity, needs an upgrade. Usually that’s wrong. In most cases the report is slow because of how it was built, not what it’s running on, and the fix costs nothing. Here’s what actually causes the delay, in roughly the order it’s worth checking, and what to leave alone.
Where the delay actually happens
A Power BI report does three things when you open it or click a filter: it loads the underlying data model into memory, it runs a query against that model for whatever you just asked for, and it renders the visuals on screen. Slowness can show up in any of the three, and each has a completely different cause. Confusing them is why so many businesses buy a bigger licence and the report is still just as slow the next day.
If the report is slow the moment you open it, that’s usually the data model — too much data, or data shaped the wrong way, being pulled into memory. If it’s slow only when you click a filter or slicer, that’s the query stage — the model is having to work harder than it should to answer a simple question. If everything loads fine but the screen takes a while to catch up and redraw, that’s the visuals themselves. Most of the “just add capacity” advice targets the second and third of these, when the first is doing most of the damage.
The data model is the one that actually matters
Microsoft’s own guidance puts data model design first among the things worth optimising, ahead of the data source, the visuals and the environment (Power BI optimisation guide). The single biggest lever inside the model is whether the tables are arranged as a star schema — a small number of clean fact tables surrounded by simple lookup tables — or whether they’re just a copy of however the source system happened to store the data, with wide tables, repeated columns and relationships going in every direction.
Small businesses almost always end up with the second version, because it’s the fastest way to get a dashboard working. You connect Power BI straight to the export from your accounting or POS system, drag every column into a table, and build visuals on top. It works, for a while. Then the table grows, someone adds a few more measures that reference other measures, and every click starts triggering a search through far more data than the answer actually needs. None of that shows up as an error. It just shows up as the spinner taking longer each month.
Too many visuals compounds whatever the model is already doing
The second most common cause is simpler: too much crammed onto one page. Every visual on a Power BI report page fires its own query. A page with twelve visuals fires twelve queries the moment it loads, and again every time a filter changes. If the underlying model is already inefficient, that inefficiency gets multiplied by however many visuals are on screen at once. A dashboard that would be tolerable with four well-chosen visuals becomes genuinely slow with fourteen, even though nothing else about the data changed.
This is also where the fix is cheapest, because it’s a design decision rather than a rebuild. Splitting one crowded page into three focused ones, each answering a specific question, usually feels faster immediately — not because the total amount of data queried dropped, but because each individual page has less to do before it can show you something.
Where refresh mode and data volume genuinely matter
Further down the list, refresh mode and raw data volume are real factors, just less common ones for a small business. Power BI reports either import a copy of the data into the model or query the source live every time, known as DirectQuery. Import mode is faster to interact with because the data is already sitting in memory; DirectQuery is more current but slower, because every click sends a fresh query back to the source system. Most small business reports don’t need live, to-the-second data — a scheduled refresh once or twice a day is usually plenty, and switching an unnecessarily live report to import mode is often the single fastest fix available.
Genuine data volume is rarer than people assume. A five-year transaction history with a few hundred thousand rows is not a lot of data by Power BI’s standards; the model handles that comfortably on the free tier. If a report is slow and the underlying table is genuinely enormous, that’s usually the point to get someone to look at how the data is structured before assuming a capacity upgrade is the answer.
What to actually do
Before you pay for more capacity, work down the list in that order. Check whether the report is slow to open (model), slow to filter (query), or slow to redraw (visuals), because that tells you which of the four causes to look at first. Count how many visuals are on the busiest page and consider splitting it. Check whether the report needs to be live at all, or whether a scheduled import would do the job just as well. Only once those are ruled out is it worth looking at whether the licence tier is actually the constraint — and for most businesses under fifty people, it won’t be.
None of this requires new software or a big project. It requires someone to open the report, watch where the delay actually shows up, and fix the specific thing causing it rather than the thing that’s easiest to buy. If you want a second set of eyes on why a report is dragging, that’s exactly the kind of thing a data health check is built to find.