A dashboard that has to average a year of one-second data every time someone opens it will always be slow, because it is redoing the same enormous computation on every refresh. A continuous aggregate is the standing answer to that problem: instead of recomputing a rollup from raw data at query time, the database keeps a pre-aggregated summary table permanently up to date, so a query reads a small, already-computed result. The word that matters is continuous - the summary is maintained automatically as new data arrives, not built once and left to go stale.
Continuous Aggregate in one line: A continuous aggregate is a pre-computed summary of a time-series table that the database maintains automatically and incrementally as new data arrives, so queries read a small stored result instead of scanning and aggregating raw data every time. It differs from a query-time rollup, which computes the same summary from scratch on every request, by doing the aggregation once when data lands and refreshing only the buckets that changed. This trades a little extra write-time work and storage for large, consistent speedups on the range queries that dashboards and reports run repeatedly.
A continuous aggregate is a materialized rollup, meaning its results are actually stored on disk rather than derived on demand. When you define one - say, hourly averages, minimums, and maximums of a set of tags - the database computes those hourly buckets from the raw data and writes them into an aggregate table. A query for hourly data then reads from that small table directly, touching a few rows per hour instead of the thousands or millions of raw samples that hour contained. The saving compounds with range: asking for a year of hourly averages reads a few thousand pre-computed rows rather than aggregating a year of raw high-frequency data, which is the difference between a dashboard that loads instantly and one that times out.
The continuous part is what separates it from a plain materialized view that you would have to rebuild by hand. As new raw data arrives, the database tracks which time buckets have changed and refreshes only those, incrementally, on a schedule or as part of ingestion. It does not recompute the whole history; it recomputes the recent buckets that received new points and leaves the settled past untouched. This incremental refresh is what makes the aggregate affordable to keep current even on a firehose of incoming data, because the work per refresh is proportional to what just arrived, not to the size of the entire dataset.
Because raw data can still be trickling in for recent buckets - a late sample, a backfill, an out-of-order arrival from a remote site - a well-designed continuous aggregate distinguishes the settled region, where buckets are final, from a live edge where the most recent buckets may still change. Many implementations serve the finalized buckets straight from the materialized table and compute only the still-moving edge on the fly, so a query gets fast pre-computed results for the bulk of the range and correct, current numbers for the last little bit. That hybrid is what lets the aggregate be both fast and accurate right up to the present moment.
The alternative to a continuous aggregate is to compute the rollup at query time: every request scans the raw data for the requested range and aggregates it right then. This is maximally flexible - any query, any range, any bucket size, always reflecting the very latest raw data - and for small ranges or infrequent queries it is perfectly fine. Its weakness is that it repeats the same heavy work over and over. A dashboard that a dozen people open dozens of times a day, each triggering a full aggregation of a long range, burns the same computation again and again, and the cost grows with both the data volume and the query traffic until the system cannot keep up.
A continuous aggregate inverts the trade. It pays the aggregation cost once, when data arrives, and then serves an unlimited number of reads cheaply from the stored result. The price is real but bounded: extra storage for the summary table, a modest ongoing write-time cost to keep it refreshed, and a loss of flexibility because the aggregate is defined for a particular bucket size and set of functions. Ask for a bucket size or a statistic the aggregate was not built for and you fall back to raw data. The art is choosing the bucket granularities and functions that your dashboards and reports actually use, so the common queries hit the aggregate and only the unusual ones pay the query-time price.
The two are complementary rather than mutually exclusive, and a good historian uses both. Hot, frequently viewed summaries - the hourly and daily rollups behind standard dashboards and reports - live as continuous aggregates so they are always fast. Ad-hoc investigation, unusual bucket sizes, and full-resolution drill-downs run against raw data at query time, accepting the slower response for work that is done rarely. Layering continuous aggregates on top of raw retention gives you speed where it is needed without giving up the flexibility to reach the underlying data when a question the aggregate cannot answer comes up.
In a SCADA historian, continuous aggregates are what make long-range operational dashboards usable. Operators and engineers routinely want a month of hourly averages across dozens of tags, a year of daily totals for production reporting, or a trend that spans a shift for many sites at once - all queries that would be painfully slow against raw high-frequency data but are near-instant against pre-computed rollups. Because remote field data arrives continuously and sometimes late or out of order, the incremental-refresh behavior matters a great deal: the aggregate has to fold in a backfilled hour from a wellpad that just reconnected without rebuilding a year of summaries, and it has to keep the recent edge correct as straggling samples land.
A cloud SCADA platform such as Merobix serves dashboards to many users across many remote sites, which is exactly the workload continuous aggregates are built for - lots of repeated range queries over the same rollups. Maintaining hourly and daily summaries as continuously refreshed aggregates lets a shared dashboard render a long history quickly for everyone who opens it, without each view re-aggregating the raw stream, while still allowing a drill-down to raw data when someone needs to inspect a specific event at full resolution. The finalized-versus-live-edge distinction keeps those dashboards both fast for the settled past and accurate right up to the latest telemetry.
For field operations this shows up as dashboards that stay responsive as the historian grows and as more sites come online. The cost of adding sites and years of data lands mostly on cheap incremental refreshes and storage rather than on every dashboard load, so performance does not degrade the way it would if every query recomputed its rollup from raw data. Choosing the right aggregate granularities - typically the hourly and daily buckets that production reports and trend views actually use - is what keeps a growing, multi-site operation's monitoring snappy without abandoning the ability to reach full-resolution data for troubleshooting.
A continuous aggregate is a materialized view specialized for time-series data, with automatic incremental maintenance built in. A plain materialized view stores a query's result but must be refreshed manually or fully rebuilt, which is expensive on large, constantly growing data. A continuous aggregate instead tracks which time buckets changed and refreshes only those incrementally as new data arrives, so it stays current cheaply and does not need a full recompute.
Use a continuous aggregate when the same rollup is queried repeatedly over long ranges, such as the hourly and daily summaries behind dashboards and reports, because paying the aggregation cost once and serving many cheap reads beats recomputing it on every request. Compute the rollup at query time for ad-hoc investigation, unusual bucket sizes, or full-resolution drill-downs that are run rarely, where the flexibility is worth the slower response. Most historians use both, layering continuous aggregates over raw retention.
Well-designed continuous aggregates handle this by distinguishing the settled past, where buckets are final, from a live edge where the most recent buckets may still receive late or out-of-order data. They serve finalized buckets straight from the stored table and compute only the still-moving edge on the fly, so a query gets fast pre-computed results for the bulk of a range and correct, current numbers for the latest period. This is important for field telemetry, where samples from remote sites can arrive late after a communications gap.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.