The reason cold storage is so cheap is not magic; it is a deliberate trade you accept when you choose a deep-archive storage class. You give up fast access - sometimes waiting minutes or hours to get your data back - in exchange for a dramatically lower price per unit stored. For a historian holding years of rarely read telemetry that trade can be excellent, but only if you design around the retrieval delay rather than being surprised by it, because a storage class that takes an hour to serve a read cannot sit behind an interactive dashboard.
Cold Storage Class in one line: A storage class is a defined tier of object storage with a particular price and access profile, and a cold-archive storage class is the cheapest tier, trading very low storage cost for slow retrieval - often minutes to hours before archived data can be read, sometimes with a separate restore step and fee. It suits time-series history that is retained for compliance or the rare deep lookback but almost never queried. Its retrieval latency is the key design constraint: because reading cold data is slow and may cost extra, a historian only moves data there once it is confident that data will seldom be needed quickly, and it keeps anything interactive on faster tiers.
Object storage services offer several storage classes that hold the same bytes but differ sharply in cost and access speed. Standard classes keep data immediately readable at a moderate price; infrequent-access classes lower the storage price in exchange for a higher per-read charge; and deep-archive classes drop the storage price to its lowest by making retrieval slow. The bytes are identical - what you are choosing is the access contract. A cold-archive class effectively says: you may store this very cheaply on the understanding that when you want it back, you will wait, and possibly pay a retrieval fee to get it.
That wait is the defining feature. Where a hot store answers a read in milliseconds, a deep-archive class can take minutes or even hours to make data available, because the request often triggers a restore operation that stages the data from the deep tier into a readable location before you can access it. That restore is a distinct step with its own latency and sometimes its own cost, and it may offer faster or slower options at correspondingly higher or lower prices. So retrieving cold data is not just slow; it is a small operation in itself, unlike the instant reads a hot tier provides. Planning for that operation - its delay, its cost, its batch nature - is the whole art of using cold storage well.
The economics only work when the access pattern genuinely matches the class. Cold-archive storage is cheap to keep but relatively expensive and slow to read, so it pays off overwhelmingly for data that is written once and read almost never - long-term compliance records, deep historical backups, telemetry kept only for the rare investigation years later. Put frequently accessed data in a cold class and the retrieval charges and delays quickly erase the storage savings and frustrate every user who touches it. The class is a bet that the data will sit untouched, and the bet only wins if that is true.
Retrieval latency dictates what can and cannot live in a cold class, and getting that boundary right is central to historian design. Anything that must answer interactively - operator dashboards, trend views, alarm reviews, standard reports - cannot be served from a tier that takes minutes to hours to respond, so all of that has to stay on storage fast enough for a human to wait on. Cold storage is therefore reserved for data whose access is either rare or tolerant of delay: an occasional deep lookback for an engineering study, a compliance retrieval where a wait of minutes or hours is entirely acceptable, or a disaster-recovery restore that is not time-critical to the second.
This is why a historian's tiering decision is really a prediction about future access patterns. Moving data to cold storage is a commitment that says: we are confident this data will rarely be needed, and when it is, a slow retrieval is fine. If that prediction is wrong - if data thought to be dead turns out to be queried regularly - users hit repeated slow, possibly costly retrievals, and the design has failed even though nothing is technically broken. Good design leans on the value curve of time-series data, where access probability falls steeply with age, to place the transition to cold storage well past the age where interactive access still happens, so the cold tier only ever holds genuinely quiet data.
Because cold retrieval is slow and often batch-oriented, historians that use it tend to shape their cold data for how it will actually be read. Archiving in large, self-contained, well-organized chunks means that when a rare retrieval does happen, the system restores a coherent block covering the needed range in one operation rather than dozens of small scattered fetches, each incurring its own latency and cost. Keeping enough metadata outside the cold tier to know what is archived and where, without having to restore data to find out, is equally important, so a query can determine that its answer lives in cold storage and set expectations - or trigger a restore - without a slow round trip just to look.
SCADA historians are natural users of cold-archive storage classes because so much of their data is written once and then almost never read again, yet cannot be deleted. Years-old telemetry from a remote site is rarely of operational interest, but it may be retained for compliance, kept for a possible future dispute, or held for long-term engineering analysis, so it needs to exist somewhere cheap. A cold class is the ideal home for that quiet history, provided the historian understands that reading it back will be slow and designs the boundary so nothing interactive depends on it.
A cloud SCADA platform such as Merobix accumulates large volumes of history across many remote sites over long horizons, which is exactly the workload where a cold storage class turns an otherwise expensive retention burden into an affordable one. Recent and moderately aged data stays on faster storage so operators and reports get prompt answers, while the deep, rarely touched tail moves to a cold class where it costs little to keep. The platform's design has to keep the cold boundary well past the age of interactive use, organize archived data so a rare deep retrieval restores a coherent range efficiently, and keep enough catalog information hot that a query knows when it is reaching into slow storage.
For field operations the benefit is being able to retain the full history a distributed operation may someday need - for a regulator, an audit, a long-range trend study - without paying hot-storage prices to keep decades of quiet telemetry instantly available. The occasional deep lookback accepts a retrieval delay as a fair price for the massive storage saving, while everything an operator does day to day continues to come from fast storage. Designing around the retrieval-latency trade of the cold class - keeping only genuinely dormant data there and shaping it for efficient restore - is what makes indefinite retention economically sane for a growing multi-site historian.
A storage class is a defined tier for storing the same data at a particular combination of price and access speed. Standard classes keep data immediately readable at a moderate cost, infrequent-access classes lower the storage price in exchange for higher per-read charges, and deep-archive or cold classes drop the storage price to its lowest by making retrieval slow. The bytes are identical across classes; what differs is the access contract you accept, so choosing a class is choosing a cost-versus-speed trade.
Retrieval from a deep-archive storage class typically takes minutes to hours rather than the milliseconds a hot tier delivers, because the request usually triggers a restore operation that stages the data from the deep tier into a readable location first. That restore is a distinct step with its own latency, and it often offers faster or slower options at correspondingly higher or lower cost, sometimes with a separate retrieval fee. This slow, batch-like access is the trade you accept in exchange for the class's very low storage price.
Only data that is written once and read almost never, and whose rare reads can tolerate a slow retrieval - years-old telemetry kept for compliance, deep historical backups, and history retained for the occasional long-range study or dispute. Anything that must answer interactively, such as dashboards, trends, and standard reports, has to stay on faster storage, because a tier that takes minutes to hours to respond cannot sit behind a human waiting on a screen. The historian should place the transition to cold storage well past the age where interactive access still happens.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.