You open the report. The wheel spins. You make coffee. The wheel is still spinning. Sound familiar? Slow BI reports are one of the most common — and most quietly damaging — problems in South African businesses today. And the frustrating part is that most decision-makers just accept it, assuming it’s a technology limitation. It usually isn’t.

After 20 years of working with data across finance, insurance, manufacturing, retail, and legal, I’ve seen the same patterns repeat themselves. Slow reports aren’t a Power BI problem or a Tableau problem. They’re a design and architecture problem — and they’re almost always fixable.

1. Your Data Model Is Doing Too Much Heavy Lifting at Runtime

The single biggest cause of slow BI reports is a poorly structured data model. When your report loads, it should be reading from clean, pre-aggregated, well-indexed data — not trying to calculate, join, and transform everything on the fly. If your queries are complex and your visuals are still hitting raw transactional tables, you’re asking your report to do in seconds what should have been done in the pipeline.

Common culprits include:

• Too many calculated columns instead of measures
• Bidirectional relationships in Power BI that create ambiguous filter paths
• Fact tables with tens of millions of rows and no aggregation layer
• Missing or incorrect use of star schema design

The fix starts before the report is even built. A proper data model — ideally a star or snowflake schema — separates your facts from your dimensions and dramatically reduces the work your BI layer needs to do at query time.

2. DAX and SQL That Nobody Has Ever Reviewed

In many businesses, BI reports are built once, deployed, and never touched again — even as data volumes grow and business logic becomes more complex. The DAX measures or SQL queries underpinning those reports were written under time pressure, often by someone who has since moved on. Nobody has reviewed them since.

Poorly written DAX is a silent performance killer. Measures that use FILTER where CALCULATE with a condition would work better, iterator functions applied to large tables, or measures that call other measures five levels deep — these compound quickly. On a small dataset, you won’t notice. On a dataset with two years of daily transaction data from a national retail chain, you absolutely will.

A code audit isn’t glamorous work. But it consistently delivers the fastest return on investment of any BI optimisation exercise I’ve run. Hours of load time have been reduced to seconds just by rewriting a handful of core measures.

3. You’re Running Live Connections When You Should Be Importing

Many teams default to DirectQuery or live connections because they want real-time data. That sounds logical — but it comes with a significant performance cost, especially when your underlying database isn’t optimised for analytical queries. Every visual on the page fires a separate query to the source system, and if that source system is also handling transactional load, you’re competing for resources.

The honest question to ask is: does this report actually need to be real-time? For most operational dashboards in South African businesses — weekly sales performance, monthly financial summaries, pipeline reports — data refreshed every hour or even once a day is perfectly sufficient. Switching to an import model with a scheduled refresh can reduce load times dramatically while also reducing pressure on your source systems.

Where real-time data is genuinely required, the solution is a properly designed aggregation table and a hybrid model — not a direct hit to your production database every time someone filters by region.

4. Report Design Is Killing Performance Just as Much as the Data

This one surprises people. The visual layer itself can be a significant source of slowness. Reports packed with too many visuals, custom visuals with heavy rendering overhead, high-cardinality slicers, or visuals with cross-filtering enabled across the entire page — all of these add up.

Best practice is to limit each report page to a focused set of visuals with a single, clear purpose. Reduce slicer options by applying filters at the model level where possible. Disable unnecessary visual interactions. And audit your use of custom visuals — some are beautiful but computationally expensive.

Performance Analyser in Power BI is a free, built-in tool that shows you exactly how long each visual takes to render and how long the DAX query behind it takes to run. Most teams have never opened it. It takes ten minutes and tells you more about your report’s problems than a week of guessing.

What to Do Next

If your reports are slow, don’t accept it as normal. Slow data erodes trust in your analytics platform and pushes decision-makers back to gut feel and spreadsheets — which defeats the entire purpose of investing in BI in the first place.

Start with a structured audit: data model design, query logic, connection mode, and visual layer. In most cases, the biggest gains come from the first two. If you don’t have the internal capacity to do that work, bring in someone who does.

At oCode360, we run BI performance audits for businesses across South Africa — identifying exactly where time is being lost and implementing targeted fixes that make your reports fast, reliable, and trustworthy. If your team is losing time waiting for dashboards to load, let’s have a conversation.

Reach us at [email protected] and let’s make your data work faster for you.

oCode360 (t/a JVW Business Solutions (Pty) Ltd) — Making data make sense.