SCADA Historian Storage Calculator

This free SCADA historian storage calculator estimates how much disk your process historian will consume, and the practical SSD size to buy for it. Enter the tags you historize, your sample interval, and the average percentage of tags that change at each sample; the calculator turns those into recorded tag changes per second, multiplies by 100 bytes per recorded change, totals the volume over your retention days, then adds your storage headroom and an operating system and application reserve. It's for controls and SCADA engineers sizing a new historian server or industrial PC, checking whether an existing drive survives a retention or interval change, or challenging a vendor's storage quote. No account, no spreadsheet — the formula and assumptions are shown below so you can reproduce the result by hand.

▦

Estimate SCADA historian data volume and a practical SSD size.

Planning estimate uses 100 bytes per recorded tag change, then adds your selected headroom plus OS/application reserve. Real storage varies with historian schema, compression, deadband, indexing, and database overhead.

The formula

A historian that samples on an interval and stores the values that changed grows at a rate set by one product: how many tag changes it records per second, times how many bytes each recorded change costs. The change rate itself comes from three inputs — the tags you historize, the share of them that change at each sample, and how often you sample. Everything after that is retention and margin.

Recorded change rate
  R = N × (p / 100) ÷ I

Data volume
  S_day       = R × 100 bytes × 86,400 sec/day
  S_retention = S_day × T            (decimal GB: bytes ÷ 1,000,000,000)

Total disk required
  S_total = S_retention × (1 + h / 100) + S_reserve

Recommended SSD = the first size in [128, 256, 512, 1024, 2048, 4096] GB
                  at or above S_total (above 4096 GB, the next whole
                  multiple of 1024 GB); shown as TB at 1024 GB and up

Variable	Meaning	Where it comes from
N	Historized tags — the tags actually logged to the historian, not every tag configured in the SCADA system	The "Historized tags" field; your historian configuration / tag export
I	Sample (storage/scan) interval, in seconds — how often the historian samples the tags	The "Sample interval (sec)" field; your historian's scan/storage configuration
p	Average percentage of tags that record a changed value at each sample, after deadband and exception reporting	The "Average tags changing (%)" field; estimated per the glossary, or measured from an existing historian (see below)
R	Total recorded tag changes per second across the whole historian	Calculated: N × (p/100) ÷ I, and shown on the result as "estimated tag changes / sec." This is the core sizing metric vendor sizing guides use as well — Inductive Automation's historian guidance, for example, is built around estimating tag changes per second
b	Bytes per recorded tag change	Fixed at 100 bytes in this calculator's model — a stated constant, not an input
T	Retention period, in days	The "Retention (days)" field; your reporting, troubleshooting, and compliance requirements
h	Storage headroom, in percent	The "Storage headroom (%)" field; your allowance for tag growth, index/database overhead, and estimate error
S_reserve	Operating system + historian application reserve, in GB	The "OS/app reserve (GB)" field; the space the drive needs before it stores a single value: OS, historian software, logs, and working room

Measuring p and I as a pair: if you already run a historian, its own statistics give you both. Changes per second R is often displayed or computable (total recorded changes ÷ elapsed seconds), and p then follows from p = R × I ÷ N × 100. Estimate the two as a pair, never independently — at a longer interval, a larger share of tags will have changed by the next sample, so a % measured at a 1-second interval does not transfer to a 60-second one.

Why 100 bytes: a stored change carries more than the measurement — a timestamp, quality, and the database's per-record and indexing overhead. Real historians vary widely around it: compression and swinging-door algorithms can push the effective cost well below 100 bytes per change, while verbose schemas and heavy indexing push it above. 100 bytes is a planning figure, deliberately on the uncompressed side, so the estimate errs toward a drive that is big enough. All sizes in this page are decimal GB (1 GB = 1,000,000,000 bytes), the units SSDs are sold in; your operating system will report the same drive in GiB, which is why a 1 TB drive appears as about 931 GiB.

What each input means

Field names below are the calculator's own labels.

Input	Unit	Typical value	What breaks if you get it wrong
Historized tags	tags	500–5,000 for a machine or line historian; 10,000–100,000 plant-wide. The calculator opens at 2,000	Counting every configured SCADA tag instead of the tags actually historized overstates the size; counting only today's tags understates it once the next project adds logging
Sample interval	seconds	1–10 s for most process values; 10–60 s for slow trends (temperatures, tank levels). The calculator opens at 10 s	The interval is a divisor, so it is the strongest lever in the model: halving it doubles the recorded change rate and the data. Shortening an interval later without re-sizing is the classic way historian drives fill years early
Average tags changing	% (1–100)	Around 20% per sample for a mixed plant at a 10 s interval (the calculator's opening value); steady processes lower, noisy or batch processes higher	Entering 100% assumes every tag changes at every sample and can inflate the estimate roughly five-fold over a typical mixed plant. Entering a % measured at one interval together with a different interval understates or overstates it, because p rises as the interval lengthens
Retention	days	30–90 days for operations troubleshooting; 365+ days where reporting, batch records, or compliance drive the requirement. The calculator opens at 30 days	Retention multiplies everything else. Extending it later is the most common reason historian drives fill up years before planned
Storage headroom	% (0–300)	20–30% selected for most projects; the calculator opens at 30%	Zero headroom = a drive sized exactly to an estimate. Tag additions, a retention extension, or database maintenance (compaction, rebuilds) that needs working space will fill it early
OS/app reserve	GB	64 GB as the calculator opens; 50–100 GB is typical for the OS, historian software, application logs, and update working space	Forgetting it puts the database on a drive that is already partly full on day one. On small systems the reserve can exceed the raw data itself — at the calculator's opening values the raw historian data is about 10 GB against a 64 GB reserve — so skipping it doesn't just trim the margin, it can halve the drive's useful historian capacity

Not an input: bytes per recorded change. The model prices every recorded change at a fixed 100 bytes. You cannot lower it to "make the drive fit" — the real per-record cost is set by your historian's schema, compression, and indexing, not by the person doing the sizing.

Worked example

Scenario: a mid-size plant historian on its own industrial PC. 5,000 tags are historized at a 10-second sample interval, and the plant's experience is that about a fifth of tags record a changed value at each sample after deadband. Operations wants 90 days online. Headroom is left at a middle-of-the-road 25%, and the reserve is the calculator's own default of 64 GB.

Inputs:

Historized tags: 5,000
Sample interval: 10 sec
Average tags changing: 20%
Retention: 90 days
Storage headroom: 25%
OS/app reserve: 64 GB (the calculator's default)

Step by step:

Recorded change rate = 5,000 × (20 ÷ 100) ÷ 10 = 100 changes/sec
Data rate = 100 × 100 bytes = 10,000 bytes/sec
Per day = 10,000 × 86,400 = 864,000,000 bytes = 0.864 GB/day (≈ 0.80 GiB/day)
Raw historian data over retention = 0.864 × 90 = 77.76 GB
Add headroom = 77.76 × 1.25 = 97.2 GB
Add reserve = 97.2 + 64 = 161.2 GB total required (≈ 150 GiB, as an operating system would report it)
Recommendation: the ladder's first size at or above 161.2 GB — a 128 GB SSD is too small, so the calculator recommends a 256 GB SSD, leaving roughly 95 GB of nominal spare capacity for growth, maintenance working space, and the inevitable retention request.

What the example shows — the interval is the dominant lever. The other inputs scale the result; the interval divides the change rate, so it multiplies everything downstream. Take the same plant and sample every second instead of every ten:

Change rate = 5,000 × 0.20 ÷ 1 = 1,000 changes/sec (10× the data rate)
Per day = 8.64 GB; raw over 90 days = 777.6 GB
With 25% headroom = 972.0 GB; plus the same 64 GB reserve = 1,036 GB total required
Recommendation steps past the 1024 GB rung: a 2 TB SSD (2048 GB)

Note the total didn't simply grow tenfold — 161.2 GB × 10 would be 1,612 GB — because the reserve stays at 64 GB; only the data portion scales. Two smaller levers, for scale: doubling Average tags changing to 40% doubles the data side (155.52 GB raw, 258.4 GB required) and just pushes the recommendation from 256 GB to 512 GB; and holding the base example for a full year instead of 90 days gives 315.36 GB raw, 458.2 GB required — a 512 GB SSD.

Endurance: this example writes 0.864 GB/day, about 0.32 TB per year — at that scale, capacity, not SSD write endurance, is the binding constraint. Even the 1-second variant writes only ~3.2 TB/year. Still, on any high-rate system, divide the drive's rated TBW by your yearly write volume and confirm the endurance outlasts the hardware's planned life.

What the result tells you

The calculator shows four figures, labelled as follows:

Estimated tag changes / sec — the recorded change rate R your three rate inputs produce. This is the core sizing metric and the quickest sanity check there is: if it surprises you, one of tags / interval / % changing is off — most often the % changing was estimated at a different interval than the one entered.
Raw historian data (GB) — the recorded data alone over your retention, before margins: R × 100 bytes × 86,400 × days, in decimal GB. Divide it by retention to get the daily growth rate, the number to check against reality in the first weeks of operation.
Estimated total required (GB) — raw data with your headroom applied, plus the OS/app reserve. This is the number the drive has to beat, not the raw data figure.
Recommended SSD capacity — the first size in the ladder [128, 256, 512, 1024, 2048, 4096] GB at or above the total required (above 4096 GB, the next whole multiple of 1024 GB), displayed as GB under 1024 and as TB at or above it (1024 GB shows as 1.0 TB). The recommendation is always at or above the requirement, never the closest size below it — a drive that starts life at 95% of the requirement has no room for the estimate to be slightly wrong.
Which term dominates — at fixed retention, storage is proportional to recorded changes per second, and the interval divides that rate. Deadband tuning that cuts the % changing on a handful of noisy tags, or a longer interval where the process allows it, saves more disk than deleting hundreds of quiet tags from logging.

Common mistakes

Assuming every tag changes at every sample. Entering 100% for Average tags changing prices in a change for every tag at every sample. With deadband applied, a mixed plant typically records a fraction of that per sample — entering 100% against this page's example inputs would give 500 changes/sec — five times the change rate, and five times the recorded data.
Pairing a % changing with the wrong interval. The two inputs describe the same sampling process: lengthen the interval and more tags will have changed by the next sample, so the % rises. A % observed at a 1-second scan does not belong in a 60-second-interval estimate, in either direction.
Shortening the sample interval without re-sizing. Going from 10 s to 1 s multiplies recorded data by ten (see the worked example: the same historian jumps from a 256 GB to a 2 TB recommendation). Interval changes made for better trend resolution are storage decisions too.
Sizing to the raw data volume alone. The recorded data is not the whole drive: headroom absorbs tag growth and estimate error, and the OS/app reserve is occupied before the first value is stored — at the calculator's opening values the 64 GB reserve is several times the raw data. Skipping either means the drive fills at a fraction of the planned retention.
Counting configured tags instead of historized tags. A SCADA system can carry 20,000 tags while the historian logs 4,000 of them. Only the historized set consumes historian disk — but use next year's historized set, not today's, if a project is already adding tags.
Mixing up GB and GiB. The calculator works in decimal GB, the units drives are sold in; operating systems report binary GiB. A 1 TB drive is 1,000 GB but only about 931 GiB on screen — a phantom ~7% that has "missing drive" investigations written all over it if the estimate and the OS reading use different units.

FAQ

How do I calculate historian storage size?

Work out the recorded tag changes per second first: historized tags × (average % changing ÷ 100) ÷ sample interval in seconds. Multiply that by 100 bytes per recorded change and by 86,400 for a per-day volume, multiply by your retention days, add headroom for growth and database overhead, and add an operating system and application reserve. Buy the next standard SSD size above that total. Example: 5,000 tags × 20% ÷ 10 s = 100 changes/sec → 0.864 GB/day → 77.76 GB over 90 days → 161.2 GB once 25% headroom and a 64 GB reserve are added — a 256 GB SSD.

Why does the calculator use 100 bytes per tag change?

A recorded change stores more than the value: a timestamp, a quality flag, and the database's per-record and indexing overhead. Effective cost varies with historian schema, compression, deadband, and indexing, so 100 bytes is a fixed planning constant in this calculator's model — chosen on the uncompressed side so the estimate errs toward a drive that is big enough rather than one that fills early. It is not an adjustable input; if your historian vendor publishes measured bytes-per-value figures for your configuration, those refine the estimate outside the calculator.

What sample interval and percent changing should I enter?

Use the interval your historian actually stores at — commonly 1–10 seconds for process values, longer for slow trends — and the average percentage of tags that record a changed value at each sample, after deadband and exception reporting. For a mixed plant at a 10-second interval, around 20% is a reasonable planning figure; steady temperatures and levels change on a smaller share of samples, noisy analogs on a larger share. The two are a pair: at a longer interval, a larger share of tags will have changed, so don't combine a long interval with a percentage measured at a short one. With an existing historian, measure them together from its recorded-change statistics.

Why is the recommended SSD larger than my calculated data volume?

Three reasons stack up. Headroom covers tag growth, estimate error, and database working space. The OS and application reserve (64 GB at the calculator's default) occupies part of the drive before any data is stored. And the recommendation steps up a fixed ladder — 128, 256, 512, 1024, 2048, 4096 GB — so a 161.2 GB requirement cannot go on a 128 GB drive and lands on a 256 GB one.

Will compression and deadband make my real historian smaller than this estimate?

Often, yes. This is a planning estimate priced at 100 bytes per recorded change without compression credit; a historian using deadband — which is already reflected in the % changing you enter — and a compression algorithm (for example swinging-door trending) on well-behaved signals can store the same history in noticeably less space. Treat any saving as safety margin, not as a reason to buy a smaller drive: compression performance depends on signal behaviour, and the least-compressible period is the one that determines whether you run out of disk.

Does this estimate guarantee I won't run out of disk?

No. It is a planning estimate from historized tags, sample interval, % changing, retention, and the margins you select. Real consumption varies with historian schema, compression, deadband settings, indexing, and database overhead, and it changes the moment tags are added, retention is extended, or an interval is shortened. Size with headroom, then check actual disk growth against the estimate in the first weeks of operation and adjust retention or capacity while it is still cheap to do.