Self-Service Real-Time Analytics in Power BI - When It Is Worth the Cost

A warehouse supervisor asks for a dashboard that shows open picks, updating as orders come in. An analyst builds it in an afternoon, publishes it, and it looks brilliant on the first day. Three weeks later the database team is asking why the reporting server is pegged every weekday from 8am to 5pm, and nobody can quite say which report is responsible.

That story is close to what we see when real-time reporting goes wrong. The Power BI side is not hard. The hard part is that "real-time" sounds like a free upgrade, and it is not. Every refresh is a query, and every query lands on something that somebody has to pay for and keep running.

Here is how the self-service approach works in Power BI, what it costs in practice, and when we tell clients to skip it.

What "real-time" means here

Microsoft's own guidance is careful about this, and it is worth copying the careful version. In the documentation the term real-time actually means near real-time. There is always some latency between a change in the source system and the number on the screen, because of processing and network time. The data is always current in the sense that the report keeps asking for it, but it is never instantaneous.

Real-time reports also do not need anyone to click anything. The visuals refresh on their own, which is the whole point for a wall-mounted dashboard or a supervisor's second monitor. Analysts sometimes describe this as a streaming dashboard, but the mechanics are closer to a page that re-asks the database every few minutes.

The moving parts

For self-service real-time analytics, the business analyst does three things. They create or connect to a DirectQuery semantic model, build a report on top of it, and turn on automatic page refresh for the pages that need to update. When the report is published, the workspace holds the report and the semantic model, and refresh happens without any further action.

DirectQuery is the important piece. A DirectQuery model does not import data. It holds the structure of the model, and each time a visual is drawn, Power BI sends a native query to the underlying source. That is why the freshness is good, and it is also why the load lands on the source.

Relational databases are the usual candidates. Azure SQL, SQL Server, and similar sources support DirectQuery, and the full list is in Microsoft's data source documentation. Some sources that do not support DirectQuery can still feed a real-time report through a live connection to a tabular model hosted in Analysis Services, or through a semantic model that includes DirectQuery tables.

There is one useful shortcut that many people miss. You can take an import model and add a DirectQuery partition for the most recent data, using incremental refresh with the option to get the latest data in real time. That gives you the speed of an import model for history and the freshness of DirectQuery for today. It is only supported in Premium workspaces, so check that before you design around it.

What the automatic page refresh feature actually asks for

Automatic page refresh is set per report page. You choose an interval, and at each interval Power BI refreshes every visual on that page. There are two types.

The fixed interval type is the simple one. Every visual refreshes on the schedule you set, which can run from every second to every few days. It is the easiest to reason about, and it is also the most expensive, because it does not care whether anything changed.

The change detection type is smarter. You create a special measure, sometimes called a change detection measure, that returns a value that changes when the source changes. A common example is the maximum order number. At each interval, Power BI runs that query, compares the result to the last one, and only refreshes the page if the value has moved. This can cut a lot of unnecessary load. It is only supported for Premium workspaces and for models hosted in Power BI, not for remote models in Analysis Services. A model can only have one change detection measure, and there is a tenant-wide limit of ten.

The arithmetic nobody does

This is the part we push clients to work through before anyone publishes anything. Take a single report page refreshing every five minutes with two visuals. That is at least 24 queries an hour against the source, from one viewer, with the page open. Now imagine ten people open that page at the same time. That is 240 queries an hour, all hitting the same database.

Scale that up to a page with eight visuals, refreshing every minute, with a team of thirty watching. You are now asking the source for thousands of queries an hour, for a report that most people are only glancing at. Multiply that by two or three real-time pages in the same workspace and you have a load problem that has nothing to do with the quality of the report.

We have seen two responses from data source owners. The good one is to ask what the refresh interval is actually for, and to tune the indexes and materialised views so that each visual query is cheap. The bad one is to block the project entirely because nobody asked them early enough. Talk to the database team before you publish, not after the first complaint.

Capacity administrators also have a role here. They can switch automatic page refresh on or off for a capacity, and they can set a minimum refresh interval and a minimum execution interval. The defaults for both are five minutes. If a page asks for a shorter interval than the capacity minimum, Power BI uses the minimum instead. Those settings do not apply to reports open in Power BI Desktop, which is a point people trip over when the Desktop experience looks fast but the published one does not.

The licensing reality

Automatic page refresh on personal or Pro workspaces has a minimum interval of 30 minutes, even if the report creator sets a lower value. That is a major constraint. A Pro workspace will not give you a near real-time dashboard, whatever the page settings say. For sub-minute refresh or change detection you need Premium or Fabric capacity.

The Premium per-capacity SKUs are being retired, and Microsoft is steering new and existing customers towards Fabric capacity subscriptions. So if you are costing a real-time project in Australia right now, cost it against Fabric F SKUs, not the older P SKUs. Check current pricing with your licensing partner, because the numbers move.

Gateways are another cost to plan for. Any data source inside a private network or a virtual network needs a data gateway for the DirectQuery operations, both visual queries and change detection queries. That is infrastructure someone has to own and patch.

A story from a client engagement

We worked with a regional services business that wanted live job status on a screen in the dispatch office. The source was an Azure SQL database that also handled the booking system's transactions. The first version used a fixed interval of one minute with nine visuals on one page. It worked beautifully for a week.

The problem came when the operations team started opening the same page on tablets in the vans. Within two weeks, the booking system was timing out during peak hours, and the dispatch team was blaming the new system for the slowdown. We rebuilt the page in three parts, moved the wall-screen visuals to a change detection measure on a single job-count value, and added an index that the visual queries were hitting badly. The page still updated within a minute of a status change, but the database load dropped to a fraction of what it had been. The lesson was that the refresh interval was not the main cost. The visual queries were, and the change detection measure was the cheapest fix available.

When we say no

We do not recommend self-service real-time analytics for every reporting need. There are a few clear cases where we advise against it.

If the decision the report supports is made once a day, a daily import refresh is cheaper, faster to query, and easier to govern. Most management reporting falls into this category, even when the stakeholder asks for "live" data.

If the source system cannot take the extra load and the database team cannot tune it, the project will fail in production. Do not start a build you cannot support.

If the business process does not act on the update, a live dashboard becomes wallpaper. We have seen a leadership dashboard refreshing every five minutes that nobody looked at more than twice a week. The refresh was costing real money in capacity and gave nothing back.

And if the data needs to be governed carefully, think twice. DirectQuery means every viewer's query hits the source, so your row-level security and access rules need to be right at the source level, not just in the model.

Our advice in short

Use self-service real-time analytics when a specific operational decision depends on the number being current within minutes, when the source can handle the query load, and when the capacity and licensing are in place. Start with one page, one team, and a fixed interval. Measure what it does to the source before you roll it out. Use change detection where you can, because it is usually the cheapest way to stay current.

If you are sizing a real-time reporting project, our Power BI consultants can help with the model design and the refresh settings. For the wider Fabric side, including capacity planning and the data platform, our Microsoft Fabric consultants are the right team to talk to. And if the reporting project is part of a broader push to get more value from operational data, our AI for business intelligence page sets out how we approach it.

Reference: Power BI usage scenarios - Self-service real-time analytics (Microsoft Learn)