Power BI Real-Time Dashboards
A factory floor monitor shows equipment status with 5-second updates. A trading desk displays live P&L as positions change. A NOC dashboard tracks server health across 200 nodes. These are real-time dashboards in Power BI - and each can use a different technical approach because "real-time" means different things in different contexts.
Power BI offers three classic paths to live data: real-time semantic models (push and streaming models fed through an API, with very low latency but limited or no modeling), DirectQuery with automatic page refresh (live queries against the source, full analytical power, higher latency), and hybrid dashboards combining both. Microsoft has announced the retirement of real-time streaming in Power BI and recommends Real-Time Intelligence in Microsoft Fabric for new work, so that is now part of the decision too. Each option makes tradeoffs between speed, analytical capability, and complexity. Picking the wrong approach leads to either a dashboard that updates too slowly or one that updates fast but cannot answer follow-up questions.
Power BI offers three classic real-time approaches: push and streaming semantic models (data pushed through an API, very low latency, little or no modeling), DirectQuery with automatic page refresh (live queries, full DAX, higher latency), and hybrid dashboards combining both. Streaming models keep data for only an hour and feed dashboard tiles; push models store data and support reports. Creation of new real-time streaming models is supported until October 31, 2027, and Microsoft points new projects to Fabric Real-Time Intelligence. The governance challenge: real-time dashboards display live data that may not match governed definitions in batch-refreshed reports.
Three Approaches to Real-Time Data
The three approaches exist because no single architecture optimizes for both speed and analytical depth. Understanding the tradeoffs is the first decision.
Streaming semantic models update dashboard tiles with very little delay, because pushed data goes into a temporary cache instead of a database. The tradeoff: no modeling, no report visuals, no filtering. Microsoft's documentation says the cache holds data for one hour, just enough to draw visuals with a short time window. Streaming models are for operational monitoring - a handful of KPI cards showing current values - not for analysis.
DirectQuery sends a query to the source system whenever a visual needs data. No data is copied into the semantic model, which means full DAX, relationships, and drill-down - the complete analytical experience. The tradeoff is latency: every slicer click generates a round-trip query. Automatic page refresh can re-query the page on a fixed interval, no more often than every 30 minutes in shared capacity but as often as every second on Fabric or Premium capacity, but this adds query load to the source database.
Hybrid dashboards combine both. Streaming tiles show live KPI values while tiles pinned from Import or DirectQuery reports provide historical context. A dashboard might show current transactions per second (streaming tile) alongside a monthly trend chart (from an Import semantic model refreshed hourly).
Creation of streaming models remains enabled until October 31, 2027. After that date, creation of new real-time semantic models will no longer be supported, including push semantic models, streaming semantic models, PubNub streaming semantic models, and streaming data tiles. Your existing streaming semantic models will be unaffected.
- Microsoft, Real-time streaming in Power BI
Streaming Semantic Model Architecture
Push and streaming semantic models accept data through a REST API endpoint. The flow is: source system (IoT sensors, app events, transactions) pushes JSON rows to the Power BI endpoint, and dashboard tiles update automatically.
Power BI supports three types of real-time semantic models:
- Push semantic models - data pushed through the API is stored in a database that Power BI creates, so you can build reports, use alerts and pin visuals that update in real time. Relationships and measures can be defined through the REST API.
- Streaming semantic models - data pushed through the API goes to a temporary cache that expires after an hour. No underlying database, no report visuals, tiles only.
- PubNub streaming semantic models - the Power BI web client reads an existing PubNub data stream directly. Power BI stores no data; tiles only.
A model can also be both push and streaming at once (the pushStreaming mode, or Historic data analysis turned on in the UI), which gives smooth streaming tiles plus stored history for reports.
History for push models depends on the retention policy. With the basicFIFO policy, which Azure Stream Analytics uses, a table stores up to 200,000 rows and drops the oldest rows first, so it is a rolling window, not an archive. Without a retention policy, a table can hold up to 5,000,000 rows. If you need to analyze last month's streaming data, land it somewhere durable as well.
API limits also matter: up to 120 POST rows requests per minute per semantic model (120 per hour once a table holds 250,000 rows or more), 10,000 rows per request and 1,000,000 rows added per hour. Streaming models have a 15 KB request-size limit. For high-frequency sources, batch multiple events into single API calls rather than sending one event per request.
DirectQuery for Live Data
DirectQuery takes the opposite approach to streaming: instead of pushing data into Power BI, Power BI pulls data from the source as visuals need it. No data is imported into the semantic model. Every slicer selection, filter change, or page load generates queries against the source database.
Supported sources include SQL Server, Azure SQL, Azure Synapse, Databricks, Snowflake, and many others. The semantic model in Power BI defines relationships, measures, and calculated columns in DAX - the full analytical toolkit. The engine translates DAX into the source's query language, such as SQL, and sends it to the source.
Automatic page refresh makes DirectQuery feel closer to real-time. It comes in two types. Fixed interval re-runs every visual's query on a set cadence: in shared capacity the minimum is 30 minutes, while on Fabric, Premium or Premium Per User capacity it can go down to one second if the capacity administrator allows it (the default capacity minimum is five minutes). Change detection, available only on dedicated capacity, polls a single measure and refreshes the visuals only when its value changes, with a default minimum execution interval of five seconds. Fixed-interval refresh is powerful but expensive: as an illustration, a report with 12 visuals refreshing every 10 seconds generates 72 queries per minute for each open copy of the page. With change detection, Microsoft notes that only one query goes to the source until a change is detected, however many users are viewing.
Composite models combine DirectQuery tables with Import tables in one semantic model. The Import tables hold slowly-changing reference data (product catalog, geography hierarchy) while DirectQuery tables provide live transactional data. This reduces the query load on the source while keeping the live connection for what matters.
Building a Streaming Dashboard
Real-time semantic models are created in the Power BI service, not in Power BI Desktop. Before you start, check the retirement timeline: Microsoft supports creating new real-time semantic models until October 31, 2027.
Step 1: Create a streaming semantic model. On a dashboard, select Edit > Add a tile > Custom Streaming Data, then add a streaming semantic model and choose API, Azure Stream or PubNub. For the API option, define the schema - column names and data types - and decide whether to turn on Historic data analysis. Power BI generates a REST API push URL. For models created in the UI, that URL contains a key that authorizes pushes without a Microsoft Entra ID token, so treat it as a secret.
Step 2: Push data via REST API. An Azure Function, Logic App, or custom application sends JSON rows to the push URL, or, for push semantic models, calls the Post Rows endpoint with a Microsoft Entra ID token:
POST https://api.powerbi.com/v1.0/myorg/datasets/{dataset-id}/tables/{table-name}/rows
{
"rows": [
{
"timestamp": "2026-10-16T10:30:00Z",
"sales_amount": 1250.50,
"product_category": "Electronics",
"region": "North America"
}
]
}
Step 3: Add streaming tiles. Add tiles to a dashboard that bind to the streaming semantic model, for example a card (single latest number), a line chart (trending value), or a gauge. These tiles update automatically as new data arrives.
Key limitation: Streaming semantic models produce dashboard tiles, not report pages. You cannot build a Power BI report on a pure streaming model. If you need filters, drill-down, or multiple pages, use a push semantic model (which stores data and supports reports) or combine streaming tiles with a DirectQuery report on the same dashboard.
Azure Stream Analytics Integration
When raw event data needs processing before visualization - aggregation, pattern detection, multi-stream joins - Azure Stream Analytics can sit between the source and Power BI. It processes streaming data using a SQL-like query language and can write results to Power BI as an output, creating a semantic model that is both push and streaming, with the basicFIFO retention policy (200,000 rows per table).
A common pattern is windowed aggregation: instead of pushing every raw transaction to Power BI (which would hit rate limits quickly), Stream Analytics aggregates events into 5-minute windows:
-- Stream Analytics: 5-minute aggregation before Power BI
SELECT
System.Timestamp AS EventTime,
ProductCategory,
Region,
COUNT(*) AS TransactionCount,
SUM(Amount) AS TotalSales,
AVG(Amount) AS AverageSale
INTO PowerBIOutput
FROM SalesInput TIMESTAMP BY EventTime
GROUP BY
ProductCategory,
Region,
TumblingWindow(minute, 5)
This reduces the data volume hitting Power BI from thousands of events per minute to one aggregated row per category-region combination every 5 minutes - well within the API limits. Microsoft also warns that very rapid output (once or twice per second) makes Stream Analytics batch rows into larger requests that can exceed the streaming tile limit; slowing the output rate is the recommended fix.
Use cases for Stream Analytics: IoT sensor data aggregated into 1-minute averages, e-commerce transaction summaries per product category, real-time anomaly counts from application logs. Whenever the dashboard needs processed summaries rather than raw events, Stream Analytics is a natural intermediate layer.
Fabric Real-Time Intelligence
For new real-time projects, Microsoft's recommended path is Real-Time Intelligence in Microsoft Fabric. It is an end-to-end stack rather than a single feature:
- Eventstreams collect, transform and route streaming data without code, from sources such as Apache Kafka clusters, Azure Event Hubs and database change data capture feeds, with filtering and windowed aggregations along the way.
- Eventhouses (containing KQL databases) store time-based event data, indexed for fast queries in KQL or T-SQL. Eventhouse data can also be made available in OneLake for other Fabric workloads.
- Real-Time Dashboards visualize Eventhouse data with KQL-driven tiles, separate from Power BI reports.
- Power BI reports can use Eventhouse data as their source, so business users keep the familiar report experience.
- Activator watches data in streams, KQL queries or Power BI reports and takes action - an alert, a pipeline run, a Power Automate flow - when a condition is met.
Unlike push and streaming semantic models, this stack keeps full history in the Eventhouse, so the live view and the historical analysis read the same store. For Power BI models in Direct Lake mode, fixed-interval automatic page refresh is also supported on dedicated capacity, down to one second.
Performance and Limitations
Real-time dashboards in Power BI have hard constraints that shape what you can build.
Push and streaming semantic model limits:
- Streaming models keep data in a cache for one hour - no historical analysis
- Push tables with the
basicFIFOpolicy keep 200,000 rows; without a retention policy, up to 5,000,000 - 120 POST rows requests per minute per semantic model, 10,000 rows per request, 1,000,000 rows per hour
- 75 columns and 75 tables per push semantic model
- No modeling, filtering or report pages on pure streaming models - dashboard tiles only
- Creation of new real-time semantic models supported only until October 31, 2027
DirectQuery limits:
- Every visual generates a query to the source - complex reports with many visuals create heavy source load
- Automatic page refresh minimum interval depends on the workspace: 30 minutes in shared capacity, down to 1 second on dedicated capacity if the administrator allows it
- Change detection is available only on dedicated capacity, with one change detection measure per semantic model
- If queries take longer than the refresh interval, Power BI waits for them to finish, so the effective refresh rate is slower than configured
Hybrid complexity:
- Two data paths to maintain - streaming tiles and Import/DirectQuery semantic models
- Users may see different numbers depending on which path they look at (see governance section below)
- More infrastructure components to monitor and troubleshoot
Decision framework: If you need near-instant updates on a few KPI cards and can live with the retirement timeline, use streaming tiles. If you need full analytical dashboards refreshed every 30 seconds, use DirectQuery with automatic page refresh on dedicated capacity. If you need both live KPIs and historical analysis on the same screen, use a hybrid dashboard, or build on Fabric Real-Time Intelligence, where live and historical data share one store.
Why Real-Time Data Needs Governance
Real-time dashboards create a governance paradox: the data is live, but the definitions may not be.
In this illustrative case, a streaming "Revenue" tile counts pending orders as they are placed. The batch-refreshed "Revenue" report excludes pending orders and only counts confirmed transactions. Both say "Revenue." The numbers differ by $600K. The CFO sees both and calls the BI team.
Without a shared business glossary that documents what each metric means at each latency tier, these contradictions erode trust. Users stop believing any of the numbers and revert to spreadsheets.
Data governance for real-time dashboards requires explicit documentation of:
- Metric scope per latency tier - what does "Revenue" include in the streaming view vs. the daily view?
- Data freshness expectation - how stale can this metric be before it is misleading?
- Source system - where does the streaming data come from, and is it the same source as the batch data?
How Dawiso Supports Real-Time Dashboards
Dawiso's business glossary can document metric definitions at different latency tiers - distinguishing "Revenue (real-time, includes pending)" from "Revenue (daily, confirmed only)." When users see different numbers on different dashboards, the glossary provides the explanation without an emergency call to the BI team.
The data catalog ingests Power BI metadata through the Power BI connector: semantic models with their columns and measures, including each measure's expression, plus reports, dashboards, dataflows, and datasources. The Microsoft Fabric connector adds Real-Time Intelligence items such as Eventstreams, Eventhouses, KQL databases, Real-Time Dashboards and Activator items. Whether a model is fed by a stream or a nightly refresh, and what freshness users can expect, is documented on those catalog objects and linked to the glossary terms they implement. Dawiso documents these assets; it does not monitor the live data or measure its freshness.
Data lineage from the Power BI connector works at object level: a report uses a semantic model, the semantic model reads from a datasource, and the datasource connects through a gateway. That chain shows which dashboards sit downstream of a given source. It does not trace individual columns, measures, or DAX expressions.
Through the Model Context Protocol (MCP), AI agents can use the Dawiso MCP server to search the catalog, read object details, including glossary terms, and follow lineage before rendering AI-powered insights on live data. An agent that finds a streaming "Revenue" documented with a different scope than the governed "Revenue" can point out the difference instead of producing a misleading comparison.
Conclusion
Power BI's real-time capabilities span a wide range - from streaming tiles to auto-refreshing DirectQuery reports - and with the retirement of real-time streaming announced, Fabric Real-Time Intelligence is becoming the default path for new work. The technology works. The harder problem is governance: when the same metric appears on a live dashboard and a batch report with different numbers, users lose trust fast. Choosing the right real-time approach is a technical decision. Ensuring that live data is governed, documented, and consistently defined is the organizational decision that determines whether anyone trusts what the dashboard shows.
Sources
- Microsoft Learn, Real-time streaming in Power BI (retirement note: creation supported until October 31, 2027).
- Microsoft Power BI Blog, Announcing the retirement of real-time streaming in Power BI.
- Microsoft Learn, Power BI REST APIs push semantic model limitations.
- Microsoft Learn, Push Datasets - Datasets PostRows.
- Microsoft Learn, Automatic page refresh in Power BI.
- Microsoft Learn, Power BI output from Azure Stream Analytics.
- Microsoft Learn, What is Real-Time Intelligence in Microsoft Fabric?
- Microsoft Learn, Direct Lake overview.
- Dawiso Help, Power BI and Microsoft Fabric connector object types.
- Dawiso Help, Dawiso Model Context Protocol (MCP).
See it in action
Data & Analytics Catalog
Create a unified view of your data assets and gain insights faster with automated data discovery.