When someone builds a Power BI report over SCADA data, the first real decision is whether to copy the data into Power BI or leave it in the source and query it live, and that choice has bigger consequences than it looks. Import mode is fast and self-contained but works on a snapshot, while DirectQuery keeps the data where it lives and asks the source every time. For SCADA history, which can be huge and constantly growing, this trade-off is sharp. This page explains how DirectQuery works against a historian, what query folding and aggregation pushdown do for performance, and how to avoid a report that hammers the source on every visual.
Power BI DirectQuery for SCADA in one line: A Power BI DirectQuery SCADA connection is a report model that queries the SCADA data source live at query time rather than importing a copy of the data into Power BI. Each visual generates a query that is sent to the historian or database backing the SCADA system, so the report always reflects current data but depends entirely on how fast the source can answer. Its performance rests on query folding, where Power BI pushes filtering and aggregation down to the source, so the report retrieves summarized results instead of scanning raw tag history on every interaction.
Import mode loads a copy of the data into Power BI's in-memory engine, and once loaded, every visual and interaction runs against that local copy at high speed. The catch is that the copy is a snapshot as of the last refresh, so the report is only as current as its schedule, and the whole dataset has to fit in memory and be refreshed periodically. For SCADA history that spans years and grows continuously, importing everything is often impractical, because the volume is too large to hold in memory and refreshing it repeatedly is slow and heavy. Import shines for bounded, moderately sized datasets that do not need to be up to the minute.
DirectQuery takes the opposite approach: it stores no data locally and instead translates each visual into a query against the source when the visual renders. The upside is that the report reflects the source as it stands right now, with no import and no refresh cycle to wait for, and there is no requirement to fit the data in memory because it stays in the historian. This is what makes DirectQuery attractive for large, current SCADA data, since the report can sit over years of tag history without copying any of it, showing whatever the source currently holds.
The cost of that live behavior is that the report's speed becomes the source's speed, and every interaction turns into work for the historian. Where an import report answers instantly from memory, a DirectQuery report waits for the source to run and return each query, so a slow source or an inefficient query makes the whole report sluggish. The practical decision is often a hybrid: import summarized or recent data for the fast, interactive parts of a report, and use DirectQuery for the detailed or current slices where live source data is genuinely needed, rather than treating it as an all-or-nothing choice.
The single most important concept for making DirectQuery perform is query folding, which is Power BI's ability to translate the operations in a visual, the filters, groupings, and aggregations, into a single query that the source executes. When folding works, a visual showing the daily average of a tag over the last month sends the source a query that filters to that month, groups by day, and computes the average, so the source returns a few dozen summarized rows. The heavy lifting happens in the historian, close to the data, and Power BI receives a small result. Aggregation pushdown is this same idea applied to the aggregate: the sum, average, or count is computed by the source rather than by pulling raw rows into Power BI to aggregate there.
When folding breaks, the consequences are severe. If a transformation or a measure cannot be expressed as a query the source understands, Power BI may fall back to retrieving a large volume of detailed rows and doing the work itself, which for a table holding raw tag history at high frequency can mean dragging enormous amounts of data across the connection for a single visual. This is the difference between a report that returns a summarized answer in a moment and one that tries to scan the source's raw history every time a user clicks. Keeping the model and measures foldable, so operations stay expressible as source queries, is what keeps DirectQuery viable.
This is where the source's own capabilities matter, and time-series and historian back-ends vary in how well they support the kinds of grouped, time-bucketed queries reports generate. A source that can efficiently answer a query for the hourly average of a tag over a range lets DirectQuery push that work down cleanly, while a source that cannot forces Power BI to do more locally. Building the report against summarized or pre-aggregated structures where possible, and against a source that folds time-bucketed aggregations well, keeps the queries pushed down and the raw history from being scanned on every visual.
DirectQuery changes what refresh means, and understanding this is key to setting expectations. In import mode, refresh is a scheduled event that reloads the data, and between refreshes the report is a fixed snapshot. In DirectQuery, there is no dataset refresh in that sense, because each visual queries the source when it renders, so the data is as current as the source is at the moment of the query. Visuals still re-query on interaction and on a page refresh interval if one is set, but the freshness comes from the live query rather than from a scheduled reload. This is exactly why DirectQuery is chosen when currency matters, and exactly why it puts continuous load on the source.
That continuous load is the risk to manage, because a busy report can turn into a stream of queries hitting the historian, and a historian that is also serving the live SCADA system has real work to do beyond feeding dashboards. A report page dense with visuals fires many queries at once when it opens, and many users opening such pages multiplies that. Left unchecked, an analytics report can compete with the operational system for the source's resources, which is the outcome nobody wants. Limiting the number of visuals per page, filtering aggressively so queries stay bounded and foldable, and avoiding visuals that force unfoldable scans all reduce the pressure a report puts on the source.
A common and safer pattern is to point Power BI at a copy of the SCADA data rather than at the live operational system, so that reporting load never touches the historian that keeps the plant running. Where a monitoring platform already collects and stores SCADA tags, that stored history can serve as the reporting source, and a platform such as Merobix keeps a queryable record of tag values over time that a DirectQuery model can sit over without adding load to the operational SCADA system. That separation lets analysts build live, interactive reports while the historian stays dedicated to running the plant, which is the balance a production environment needs.
Use DirectQuery when the data is too large to hold in memory or must reflect the source as it stands right now, since it queries the source live with no import and no refresh cycle. Use Import when the dataset is bounded and moderately sized and does not need to be up to the minute, because it answers instantly from an in-memory copy. Many reports use a hybrid, importing summarized or recent data for speed and using DirectQuery only for the detailed or current slices that need live source data.
Query folding is Power BI translating a visual's filters, groupings, and aggregations into a single query the source executes, so the historian does the heavy work and returns a small summarized result. When folding works, a daily-average visual sends one grouped query and gets back a few rows. When it breaks, Power BI may pull large volumes of raw tag history across the connection to aggregate locally, which for high-frequency data can be catastrophically slow, so keeping measures foldable is essential.
Limit the number of visuals per page so a page opening does not fire a swarm of queries, filter aggressively so queries stay bounded and foldable, and avoid visuals that force unfoldable raw scans. Better still, point Power BI at a copy of the SCADA data rather than the live operational historian, so reporting load never competes with the system running the plant. Using stored tag history from a monitoring layer as the reporting source keeps the operational historian dedicated to operations.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.