Time-series data never stops arriving, so without a rule to remove old data a historian would grow forever until it filled its storage and stopped accepting writes. A retention policy is that rule: it sets a maximum age for data and automatically expires anything older, so the database self-trims instead of growing without bound. This page is about the expiration mechanism itself - how a retention duration is set, how the database enforces it, and where it collides with the obligation to keep certain data - not about which data to keep or where to move it, which are separate decisions.
Retention Policy in one line: A retention policy is a configured rule that automatically expires and deletes time-series data once it passes a set age, usually expressed as a time-to-live or retention duration. The database enforces it in the background, dropping data older than the limit - often by deleting whole storage segments rather than individual points - so storage stays bounded without manual cleanup. The main trade-off is that automatic deletion can conflict with compliance or legal-hold obligations to preserve data, so retention durations must be set with those requirements in mind and holds must be able to override the purge.
At its core a retention policy is a single decision - how old is too old - turned into an automatic action. You configure a retention duration, sometimes called a time-to-live or TTL, that says data older than, for example, ninety days should not be kept. The database then enforces that continuously in the background: as time moves forward, data crosses the age threshold and becomes eligible for removal, and a housekeeping process deletes it. Nobody has to run a cleanup job or remember to prune; the policy is a standing instruction that the database applies on its own, which is what keeps storage from growing without limit as new data arrives day after day.
The enforcement is usually efficient because of how time-series databases store data. Rather than hunting through the dataset for individual expired points, which would be slow, most systems organize data into time-based chunks or partitions - a chunk per day, per week, or per some interval - and expire data by dropping whole chunks once every point in them has aged past the limit. Dropping an entire chunk is a cheap metadata operation compared to deleting rows one by one, so retention enforcement stays lightweight even on a firehose of incoming data. This chunk-based expiry is why retention durations often align naturally with the chunking interval.
Retention is frequently configured per measurement or per table rather than globally, because different data has different useful lifespans. High-frequency raw samples that are only interesting for recent troubleshooting might be kept for a short window, while a summarized or lower-frequency table warrants a longer one. The retention mechanism itself does not care what the data means - it only enforces the age limit it is given - so the intelligence lives in choosing the right duration for each kind of data. That choice of what to keep and for how long is a policy question layered on top of the expiration mechanism this page describes.
Choosing a retention duration is a balance between cost and need. Longer retention means more stored data, more storage to pay for, and larger structures to query through, while shorter retention keeps the database lean but throws away history that might later be wanted. The temptation is to keep everything forever to be safe, but that surrenders the whole benefit of retention and eventually reintroduces the unbounded-growth problem the policy was meant to solve. The disciplined approach is to set durations from actual requirements - how far back operators, engineers, and reports genuinely reach - rather than from a vague reluctance to delete.
The sharpest tension is with compliance and legal obligations to preserve data. Many industries and jurisdictions require certain records to be kept for specific periods, and some situations - litigation, an investigation, an audit - impose a legal hold that forbids deleting relevant data until the hold is lifted, regardless of any age-based policy. An automatic purge that blindly deletes data past its retention age can destroy records that were legally required to survive, which is a serious failure. So retention configuration must account for the longest applicable preservation requirement, and the system must provide a way to suspend or override expiration for data under hold.
This is why retention is not purely a storage-management setting; it is also a governance control. A safe design separates the routine age-based expiration from the exceptional hold: normal data expires on schedule, but data flagged for preservation is exempted from the purge until the flag is cleared. It also keeps retention durations documented and auditable, so an organization can show what it keeps and for how long. Treating retention as both a cost lever and a compliance boundary - and never letting the automatic purge win against a legal hold - is what keeps it from quietly deleting something that mattered.
SCADA historians accumulate data relentlessly - many tags, many sites, high scan rates - so an automatic retention mechanism is essential simply to keep the store from filling up. But industrial data also carries preservation obligations that make retention a careful exercise rather than a blunt purge. Production and custody-measurement data may need to be kept for years to satisfy regulatory and contractual requirements, environmental and emissions records have their own retention rules, and an incident or dispute can freeze a slice of history under a hold. The historian therefore has to expire routine data on schedule while never dropping the records the operator is required to keep.
A cloud SCADA platform such as Merobix applies retention across data flowing in from many remote sites, which makes the mechanism valuable and the compliance dimension unavoidable. The practical shape is age-based expiration configured to match how the data is used and what it must satisfy - shorter windows for high-frequency raw telemetry that is mostly of recent interest, longer windows for the production and measurement data that reporting and compliance depend on - with the ability to exempt data under a legal or regulatory hold from the automatic purge. That keeps storage bounded and predictable without ever letting the cleanup process delete a record an audit might later demand.
For field operations the benefit is a historian that stays performant and manageable as sites and years pile up, without anyone having to manually prune old data or worry that routine cleanup will erase something important. Operators keep fast access to the recent history they use daily, longer-lived measurement data remains available for the reports and reconciliations that need it, and preserved records survive the purge. Getting the retention durations right per kind of data - and wiring holds to override expiration - is what lets a growing multi-site operation control storage cost while staying on the right side of its recordkeeping obligations.
They describe the same idea from slightly different angles. A time-to-live, or TTL, is the age limit assigned to data - how long it lives before it expires - while a retention policy is the configured rule that applies that limit and drives the automatic deletion. In practice the retention policy sets the TTL and the database enforces it in the background, so the terms are often used interchangeably; the retention policy is the rule, the TTL is the duration it enforces.
Most time-series databases organize data into time-based chunks or partitions and expire it by dropping whole chunks once every point in them has aged past the retention limit, rather than deleting individual points. Dropping an entire chunk is a cheap metadata operation compared to row-by-row deletion, so retention enforcement stays lightweight even under heavy ingestion. This is why retention durations often align with the chunking interval, since a chunk can only be dropped when all of its data has expired.
It can if it is configured without regard to preservation requirements, which is why retention durations must account for the longest applicable legal or regulatory retention period, and the system must be able to exempt data under a legal hold from the automatic purge. A safe design separates routine age-based expiration from held data, so normal data expires on schedule while flagged records are preserved until the hold is lifted. Retention should be treated as a compliance boundary, not just a storage setting, so the purge never wins against an obligation to keep data.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.