Before a historian stores its first sample, someone usually has to answer how much storage it will need, and the honest answer comes from a calculation rather than a guess. The estimate builds from four numbers, how many tags, how often they sample, how big each stored value is, and how long the data is kept, then gets adjusted for the compression and deadband that real historians apply. This guide walks through that calculation, works an example, explains why change-driven storage behaves differently from fixed-interval, and notes how cloud SCADA reframes sizing from up-front provisioning to consumption planning.
Historian Storage Sizing in one line: Historian storage sizing estimates the disk a historian needs by multiplying the number of tags by the sample rate, the bytes stored per value, and the retention period, giving a raw volume that is then reduced by the compression or deadband the historian achieves. It turns a set of assumptions about tag count, logging frequency, and how long data is kept into a concrete storage figure for capacity planning.
The backbone of a storage estimate is a product of four quantities. Start with the tag count, the number of points the historian records. Multiply by the sample rate, how many values each tag produces per unit of time. Multiply by the bytes stored per value, which covers the reading itself plus any timestamp and quality information the historian keeps with each sample. Finally, multiply by the retention period, the length of time data is kept. The result is a raw, uncompressed estimate of how much data the historian would hold if it stored every sample verbatim.
Each factor has to be chosen with care because errors multiply. The bytes-per-value figure is easy to underestimate, since a stored sample is rarely just the number; it usually carries a timestamp and a quality flag, so the per-sample footprint is larger than the raw value's width alone. The sample rate must reflect how the tag is actually logged, which may differ from how fast the underlying device is scanned. Getting these inputs realistic matters more than arithmetic precision, because the calculation faithfully amplifies whatever assumptions go into it.
The raw product is deliberately pessimistic, and the next step is to temper it. Real historians rarely store every sample at full size, so the raw figure is scaled down by an expected compression or deadband ratio, which represents how much the historian's exception-based logging and compression reduce the volume in practice. That adjustment can be substantial, but it is an estimate layered on estimates, so it is wise to treat the compressed figure as a planning target rather than a guarantee, and to keep the uncompressed number in view as a worst case.
To see the method in motion, walk through it with round assumptions. Take a system of a few thousand tags, each logging on a regular interval, with each stored sample occupying a modest number of bytes once the reading, timestamp, and quality are counted, held for a retention period of a couple of years. Multiplying tags by samples per year by bytes per sample gives an annual raw volume, and multiplying by the retention in years gives the total. That total is the uncompressed estimate, the amount before any compression is credited, and it is the figure you would then scale down by the expected compression ratio to reach a planning number.
The calculation as described assumes fixed-interval logging, where every tag writes a sample on a steady clock whether or not the value changed. Many historians instead log by exception, storing a sample only when a value changes by more than a configured deadband. Under change-driven storage, a steady tag that barely moves may write very few samples, while a noisy or fast-moving tag writes many, so the real volume depends heavily on how the process actually behaves rather than purely on the clock. This is why a fixed-interval estimate is a useful upper bound but often overstates what a deadband-based historian will really use.
The consequence is that two systems with identical tag counts and nominal rates can have very different footprints depending on process dynamics and deadband settings. A plant with mostly stable readings and sensible deadbands stores a fraction of what the fixed-interval math predicts; a plant full of noisy or rapidly changing signals may approach or exceed the naive estimate if deadbands are tight. Good sizing therefore accounts for the logging model in use and, where possible, calibrates the compression assumption against the actual behavior of similar tags rather than trusting a generic ratio.
Historically, storage sizing served up-front provisioning: you estimated the total, bought disks to cover it plus headroom, and hoped the estimate held, because adding capacity later meant procuring and installing hardware. That model puts pressure on getting the estimate right in advance and penalizes both overshooting, which wastes purchased capacity, and undershooting, which risks running out. The whole exercise is oriented around committing to a fixed amount of storage before the data exists.
A cloud historian shifts the nature of the question. In a platform like Merobix, storage scales with what is actually stored rather than requiring hardware bought ahead of need, so sizing becomes less about provisioning a fixed disk and more about planning and understanding consumption. The estimate still matters, because it forecasts how data volume and its associated cost will grow as tags and sites are added, but it drives budgeting and retention decisions rather than a one-time hardware purchase. Running out of a disk stops being the failure mode you plan against.
This reframing changes what the calculation is for. Instead of a single sizing done once at project start, it becomes an ongoing forecast that informs choices about retention windows, tiering, and how aggressively to compress or downsample as an operation grows. The same four factors, tags, rate, bytes per value, and retention, still drive the numbers, but the output is a growth curve and a cost trajectory rather than a fixed capacity to buy. Consumption planning asks not how much disk to acquire but how the data footprint and its cost will evolve, and how retention and tiering policies keep that trajectory sustainable.
Multiply the number of tags by the sample rate, the bytes stored per value, and the retention period to get a raw uncompressed volume, then reduce it by the compression or deadband ratio the historian is expected to achieve. Be sure the bytes-per-value figure includes the timestamp and quality stored with each sample, not just the reading. Treat the compressed figure as a planning target and keep the uncompressed number as a worst case.
Fixed-interval logging writes a sample for every tag on a steady clock regardless of whether the value changed, whereas change-driven logging stores a sample only when a value moves by more than a deadband. A stable tag that barely changes then writes very few samples, so real usage depends on how the process behaves. This makes a fixed-interval estimate a useful upper bound that often overstates what a deadband-based historian actually stores.
In a cloud historian, storage scales with what is actually stored rather than requiring disks bought ahead of need, so sizing becomes consumption planning rather than up-front provisioning. The same calculation still forecasts how data volume and cost grow as tags and sites are added, but it informs budgeting and retention choices instead of a one-time hardware purchase. Running out of a fixed disk stops being the main risk you plan against.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.