A historian may hold thousands of raw samples for a single tag over a day, far more than anyone wants to read one by one. Time-bucket aggregation is the query technique that folds those raw samples into a handful of interval summaries - hourly averages, daily maximums, per-shift totals - so a question can be answered at the resolution it actually needs. This guide explains how a historian query groups samples into fixed time buckets, why bucket alignment and boundary handling matter, and how this query-side step differs from the compression that happens when data is first stored.
Time-Bucket Aggregation (Historian Query) in one line: Time-bucket aggregation is a historian query operation that divides a time range into fixed intervals - such as every hour or every day - and collapses all the raw samples in each interval into a single summary value using an aggregate function like minimum, maximum, average, or sum. It lets a query return a manageable, evenly spaced series at the resolution a report or trend requires, regardless of how densely the raw data was stored. It happens at query time, computed on demand from the stored samples, which distinguishes it from the compression and decimation applied when data is written.
Time-bucket aggregation answers a request like show me the hourly average of this tag for the past week. The query engine takes the requested range, divides it into buckets of the requested width - one per hour, in this case - and assigns each stored sample to the bucket its timestamp falls in. Then it applies an aggregate function within each bucket to reduce however many raw samples landed there into one representative number. The output is a regular series: one value per bucket, evenly spaced, ready to plot or tabulate, even though the underlying raw samples were irregularly timed and far more numerous.
The choice of aggregate function is not incidental - it changes what the summarized series means. An average smooths a bucket down to its central tendency, which suits a trend of a continuous variable. A maximum or minimum preserves the extreme within each bucket, which is what you want when a brief peak matters more than the typical value, such as the highest pressure reached in each hour. A sum accumulates a rate or a count into a total per bucket, appropriate for flows or event counts. Some queries return several of these at once so a single bucketed series carries its average alongside its high and low, giving a fuller picture than any one function would. Picking the function that matches the physical meaning of the tag is what keeps the aggregation faithful rather than misleading.
Two subtle details decide whether bucketed results are correct and comparable: where the buckets start and how their edges are handled. Alignment is the question of what timestamp a bucket begins on. Hourly buckets aligned to the top of the hour give clean, conventional intervals, but the same query aligned to an arbitrary offset, or to a different time zone, shifts every boundary and produces different numbers even from identical raw data. Two reports that both claim hourly averages can disagree simply because their buckets are anchored differently, which is why consistent, well-defined alignment is essential when results are meant to be compared or reconciled.
Boundary handling is the equally important question of which bucket a sample sitting exactly on an edge belongs to, and how each bucket is labelled - by its start, its end, or its center. A sample whose timestamp is precisely on an hour boundary must belong to one bucket and not both, or it will be double-counted, which quietly corrupts a sum. The convention of whether a bucket includes its start instant and excludes its end, or the reverse, has to be consistent so totals reconcile across adjacent intervals. These edge rules rarely change an average noticeably, but for a sum - a total volume or an event count - getting them wrong shifts real quantities, so a careful historian query defines its interval boundaries explicitly rather than leaving them to chance.
It is important not to confuse time-bucket aggregation with the compression a historian applies when it stores data, because they happen at opposite ends of the pipeline and serve different goals. Storage-time compression and decimation decide which raw samples are kept on write - discarding points that add no information so the archive stays compact - and once a sample is dropped there it is gone. That is a one-time, irreversible decision made to save space, baked into what the historian physically holds.
Time-bucket aggregation, by contrast, is computed on demand from whatever raw samples were kept, and it changes nothing in storage. The same underlying data can be queried as hourly averages for one report and daily maximums for another, or re-queried at a finer bucket later, because the aggregation is a view generated at read time rather than a change to the archive. In a cloud SCADA such as Merobix, tags gathered from the field over Modbus, DNP3, OPC UA, and MQTT are stored once, and a dashboard or report then requests exactly the buckets and functions it needs - hourly for an operator's trend, daily for a management roll-up - all derived on the fly from the same stored series. Understanding that the storage decision and the query decision are separate is what lets an operator trust that a bucketed number reflects a deliberate query choice, not a hidden loss of data at write time.
The common ones are minimum, maximum, average, and sum, and many queries also return a count or the first and last value in each bucket. The right choice depends on the tag's meaning: average suits a continuous variable, minimum or maximum preserves an extreme within each interval, and sum totals a rate or event count. Some queries return several functions together so one bucketed series carries its average alongside its high and low.
Usually because their buckets are aligned differently - anchored to a different start offset or time zone - so each report groups the raw samples into different intervals even though the underlying data is identical. Boundary handling can also differ, deciding which bucket an edge sample falls into. Consistent, explicitly defined alignment and boundary rules are what make bucketed results comparable and reconcilable across reports.
Downsampling, compression, and decimation happen when data is written and permanently decide which raw samples the historian keeps, to save space. Time-bucket aggregation happens at query time and computes interval summaries on demand from whatever samples were kept, changing nothing in storage. Because it is a read-time view, the same stored data can be aggregated many different ways, whereas a sample discarded at storage time is gone for good.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.