When you build a dashboard on SCADA or historian data in a tool like Power BI, one of the first choices is how the data connects to the model: DirectQuery or import mode. It sounds technical, but it decides whether your dashboard shows the latest reading or a snapshot, whether it responds instantly or after a pause, and whether it can even hold the volume of time-series data you are dealing with. Import caches the data inside the model for speed; DirectQuery leaves it in the source and queries it live for freshness. For SCADA data, where volumes can be enormous, the choice is often forced by the data itself. This guide compares the two and gives a rule for choosing.
DirectQuery vs Import Mode in one line: DirectQuery and import mode are the two ways a BI tool such as Power BI connects to a data source. In import mode the data is copied into the model and cached, so queries run against that fast in-memory copy but the data is only as current as the last refresh, and the model is bounded by a dataset size limit. In DirectQuery the data stays in the source and the tool sends a live query on every interaction, so the dashboard always shows current data and there is no need to fit everything in the model, but each interaction depends on the source's speed and load. For high-volume SCADA time-series data, the sheer size usually forces DirectQuery or pre-aggregation because the raw data will not fit in an imported model.
Import mode brings the data into the model. When the dataset refreshes, the tool pulls a copy of the source data and stores it in a compressed, in-memory structure inside the model, and from then on every query the dashboard makes runs against that local copy rather than touching the source. The upside is speed: an in-memory columnar store answers filters, aggregations, and drill-downs very fast, so imported dashboards feel snappy. The downsides are that the data is frozen at the last refresh until the next one runs, and that the whole dataset has to fit within the model's size limit, which caps how much data you can import.
DirectQuery leaves the data in the source. Nothing is copied into the model; instead, every time the dashboard needs data - on load, on each filter, on each drill-down - the tool generates a query and sends it to the source, then displays the result. The upside is freshness and scale: because the tool queries the live source, the dashboard reflects the current state of the data, and because nothing is imported, there is no dataset-size ceiling to worry about, so a source holding billions of rows can back a dashboard that only ever asks for the slice it needs. The downside is that every interaction is a round trip to the source, so responsiveness depends on how fast the source answers and how much load it can bear.
The essential trade is therefore speed and self-containment versus freshness and scale. Import gives fast, consistent performance from a cached copy but at the cost of staleness between refreshes and a size limit. DirectQuery gives current data and no size limit but ties every dashboard interaction to the source's performance. There is no universally correct answer; the right mode depends on how fresh the data must be, how large it is, and how much query load the source can absorb, which is why the choice deserves deliberate thought rather than defaulting to whichever mode the tool suggests first.
SCADA and historian data has a property that dominates this decision: volume. Thousands of tags sampled every few seconds over months and years accumulate into a history of billions of samples, and that is far more than an imported model is designed to hold. Trying to import the raw high-frequency history runs straight into the dataset-size limit, and even where it technically fits, the refresh becomes enormously long and the model unwieldy. So the very characteristic that defines SCADA data - high-frequency, high-cardinality, long-running time series - is exactly what makes naive import impractical.
This leaves two workable paths. One is DirectQuery, where the raw data stays in the historian and the dashboard queries only the specific tags and time ranges it displays, so the enormous total never has to fit in a model. This preserves access to full-resolution data on demand, but it depends on the historian being able to answer those queries quickly, and high-cardinality time-series queries can be slow, so DirectQuery only works well if the source is genuinely fast at the queries the dashboard makes. The other path is pre-aggregation, where the high-frequency data is rolled up into coarser summaries - hourly or daily averages, minimums, maximums, and totals - that are small enough to import comfortably, giving fast dashboards at the cost of the finest granularity.
In practice many SCADA dashboards combine the two. The routine trends and KPIs are served from imported pre-aggregated data for speed, while a live or detailed view uses DirectQuery to reach into the raw historian when full resolution is genuinely needed. This hybrid gives the responsiveness of import for the common case and the freshness and depth of DirectQuery for the exceptions, without trying to import the unimportable raw history. The unifying point is that the raw volume cannot simply be imported wholesale, so every good SCADA dashboard design has to decide, per view, whether it is querying live or reading a pre-aggregated cache.
A practical selection rule falls out of the trade-offs. Choose import mode when the data is small enough to fit comfortably in the model and a periodic refresh is fresh enough, which is the case for pre-aggregated trends, KPIs, and management reports that do not need second-by-second currency. Choose DirectQuery when the data must be current to the moment, when the volume is too large to import, or when you need to reach full-resolution detail on demand, accepting that responsiveness will depend on the source. When neither fits cleanly - the classic SCADA situation of huge data that also needs some freshness - pre-aggregate for the imported common case and reserve DirectQuery for the live or detailed views.
For operational dashboards specifically, the currency requirement is worth being honest about. A true operational display that drives decisions minute to minute wants live data and leans toward DirectQuery or a fast live source, whereas a shift or daily operational summary is perfectly well served by imported pre-aggregated data refreshed on a schedule. Deciding how fresh each dashboard genuinely needs to be, rather than assuming everything must be live, avoids putting unnecessary continuous query load on the historian, because DirectQuery everywhere can hammer a source that would have been fine serving periodic refreshes. Matching the mode to the real freshness need is the crux of designing operational dashboards that are both current enough and performant.
A cloud SCADA platform such as Merobix eases this choice by serving the queries a dashboard needs efficiently, whichever mode is used. Because the platform can expose pre-aggregated rollups as well as raw detail, a dashboard can import the aggregates for its fast routine views and use DirectQuery against the platform's endpoint for the live or high-resolution views, without a team having to build the aggregation and query layers themselves. For field operations, that means their dashboards can be both responsive and fresh - reading cached summaries where a snapshot is fine and querying live where the moment matters - with the volume problem handled by the platform rather than forced onto the BI model.
Import mode copies the data into the model and caches it, so queries run fast against that local copy but the data is only as current as the last refresh and must fit within a dataset-size limit. DirectQuery leaves the data in the source and sends a live query on every interaction, so the dashboard always shows current data and there is no size limit, but each interaction depends on the source's speed and load. Import trades freshness and scale for speed; DirectQuery trades speed for freshness and scale.
Because the raw volume is too large to import. Thousands of tags sampled every few seconds over years become billions of samples, which exceeds what an imported model can hold and makes refreshes impractically long. The workable options are DirectQuery, where the raw data stays in the historian and the dashboard queries only the slice it shows, or pre-aggregation, where the high-frequency data is rolled up into hourly or daily summaries small enough to import. Many dashboards use both, importing aggregates for speed and using DirectQuery for full-resolution detail on demand.
It depends on how current the dashboard genuinely needs to be. A true operational display that drives minute-to-minute decisions wants live data and leans toward DirectQuery or a fast live source, while a shift or daily summary is well served by imported pre-aggregated data on a scheduled refresh. Being honest about the real freshness requirement matters, because using DirectQuery everywhere puts continuous query load on the historian that periodic imports would have avoided, so the mode should match the actual currency each view needs.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.