What Is a Power BI Push Dataset for Real-Time SCADA?

The REST Rows Endpoint and Streaming Tiles

A push dataset inverts the usual Power BI flow. Rather than Power BI reaching out to a source to pull data, the source sends data to Power BI by making HTTP POST requests to the dataset's rows endpoint, each request carrying one or more rows that match the dataset's defined schema. For SCADA, this means an edge gateway or an integration service that already sees tag changes can post those readings straight into the dataset as they happen, and the dashboard reflects them without any refresh cycle. The dataset is created with a fixed schema of columns, and the pushed rows must conform to it, so the shape of the telemetry, such as a timestamp, a tag name, and a value, is decided when the dataset is defined.

There is a meaningful distinction between a push dataset and a streaming dataset, even though both use a push endpoint. A push dataset stores the rows it receives, so it can back regular report visuals and retains data according to its policy, whereas a pure streaming dataset holds only a transient buffer for streaming tiles and does not persist rows for standard reporting. The choice depends on whether the values need only to flash live on a tile or also to be stored for a report, and a common middle option is a dataset that both streams for live tiles and stores rows so recent history is available in visuals.

Streaming tiles are the visuals built to consume this live data, and they are designed to update automatically as new rows arrive rather than on the standard visual refresh. A line tile showing a tag's value over the last few minutes advances as each new reading is pushed, giving the moving, live feel that a plant wants on an operations dashboard. Because these tiles are purpose-built for the push flow, they update far faster than a report visual waiting on a scheduled dataset refresh, which is the whole reason to use a push dataset for genuinely real-time display.

Retention Limits and Row-Rate Throttling

Push datasets are not a substitute for a historian, and their retention behavior makes that clear. A push dataset keeps rows up to a limit, and there is an option to enable a first-in-first-out retention policy so that when the dataset fills, the oldest rows are dropped as new ones arrive, keeping a rolling window of recent data rather than growing without bound. This is fine for a dashboard that shows recent values and trends, but it means the dataset is not the place to keep the permanent record. The durable long-term history has to live in a proper historian or warehouse, with the push dataset serving only the live and recent view.

Row-rate limits are the other constraint that shapes the design, because Power BI enforces limits on how many rows can be pushed in a period and how large the requests can be. A naive integration that posts a separate request for every single tag change from a busy plant can run into these limits quickly, so the sending side usually batches multiple readings into each request and throttles its send rate to stay within the allowances. Report-by-exception helps here as well: pushing a reading only when a value has meaningfully changed, rather than on every tick, cuts the row volume dramatically while still keeping the dashboard live for the values that are actually moving.

Designing around these limits mostly means being selective about what goes to the push dataset. A real-time dashboard rarely needs every tag in the plant; it needs the handful of values operators are watching right now. Sending only those tags, at a change-based cadence, batched sensibly into requests, keeps the integration well within the row-rate limits and the dataset within its retention window, while still delivering the live experience. Trying to push the entire plant's telemetry at full frequency into a push dataset is the way to hit every limit at once, so the discipline is to push what needs to be live and leave the rest to the historian.

Where Push Beats Scheduled Refresh in SCADA

The clearest case for a push dataset is a live operations view where seconds matter. A control room wall showing current flows, pressures, or run states wants the numbers to move as the plant moves, and a scheduled refresh, which reloads on a timer, always lags reality by whatever the interval is. Push datasets remove that lag for the specific values on the tile, because the data arrives the moment the source sends it. For anything meant to convey the plant's present state at a glance, this immediacy is exactly what scheduled refresh cannot provide, and it is the reason push datasets exist.

It is equally important to recognize where push is the wrong tool. Historical analysis, trend comparisons over long periods, and any reporting that needs the complete record are better served by a stored dataset over a historian or warehouse, whether in import or DirectQuery mode, because the push dataset only holds its rolling recent window. The sensible architecture uses each for what it does best: a push dataset for the live operational tiles, and a conventional dataset over durable history for the reports and analysis. Trying to make one dataset do both jobs strains it in both directions.

This is a natural fit alongside a cloud monitoring platform that is already handling live SCADA telemetry. A platform such as Merobix collects tag changes as they happen and holds the durable history, which puts it in an ideal position to push a curated set of live values into a Power BI push dataset for a real-time dashboard while retaining the full record for reporting. That split lets the live tiles stay genuinely current from the monitoring layer's stream, and the historical reports draw on the stored history, so operators get both the immediate view and the deep analysis without asking a single dataset to serve two very different needs.

Frequently Asked Questions