Dedicated Historian Box vs a Shared VM
A historian is a disk-hungry, always-writing workload that behaves nothing like the rest of a SCADA system. Deciding whether it gets its own dedicated resources or shares a virtual machine with other services determines whether your trends stay responsive as data piles up. This page compares the two placements for the historian specifically, so the decision is made on the workload's real appetite rather than on convenience.
Dedicated historian box vs shared VM in one line: A dedicated historian gets its own CPU, memory, and above all its own disk, so continuous writes and heavy trend queries never fight another workload, which matters because a historian is I/O-bound. A shared VM co-locates the historian with other services to save hardware, fine for light data rates but prone to disk contention as tag counts and retention grow. Give the historian a dedicated disk tier whenever its write rate or retention is significant.
Recognize the Historian as an I/O Workload
The historian is unlike the rest of the SCADA stack because it writes constantly and stores forever. Every scanned tag change is a write, and every trend query is a burst of reads across a large archive, so the binding constraint is almost always disk throughput rather than CPU. Understanding historian IOPS and disk sizing is the starting point, because a historian sized on CPU alone will still stall if its disk cannot keep up with the write stream plus query load.
This is why sharing matters more for the historian than for other components. When the historian shares a disk with other virtual machines, its steady write stream and occasional heavy queries compete with everything else for the same I/O budget, and the symptom is trends that render slowly exactly when an operator is trying to investigate an event. A supervisory server can often share a host comfortably; a busy historian on a shared disk is the classic cause of a SCADA system that feels fast until someone opens a long trend.
Compare Dedicated Against Shared Placement
The table focuses on the factors that actually decide historian placement, which are dominated by storage rather than compute.
| Factor | Dedicated historian | Shared VM |
|---|---|---|
| Disk I/O contention | None - owns its storage | Competes with co-located services |
| Trend query responsiveness | Consistent under load | Degrades as neighbors get busy |
| Handling retention growth | Scale its own storage tier | Growth pressures the shared host |
| Hardware cost | Higher - its own resources | Lower - shares a host |
| Blast radius of a fault | Isolated to the historian | A neighbor's spike hits the historian |
| Right when | High tag count, long retention, heavy queries | Low data rate, short retention, light use |
Retention growth is the factor projects underestimate most. A historian that fits comfortably on a shared VM at commissioning grows relentlessly as retention accumulates, and storage sizing and capacity planning is what tells you whether today's shared placement survives three years of accumulation. A design that ignores growth is really just deferring the migration to a dedicated tier to a more painful moment.
Tiered retention changes the arithmetic in the historian's favor either way. Moving older data to cheaper, slower storage through tiered hot-warm-cold retention keeps the fast, expensive tier small and the hot working set responsive, which can make a shared placement viable longer or a dedicated tier cheaper. Whichever placement you choose, tiering is how you stop the disk bill and the query latency from growing without bound.
When Each Placement Wins
A shared VM wins when the historian's appetite is genuinely small. A site with a modest tag count, short retention, and users who rarely pull long trends imposes a write and query load that a shared host absorbs without anyone noticing. For these systems, dedicating hardware to the historian is spending against a contention problem the workload will never create.
A dedicated historian wins as soon as any of three pressures appears: a high tag count driving a heavy continuous write stream, long retention accumulating a large archive, or users who routinely run wide, deep trend queries. Any one of these makes disk contention on a shared host a live risk, and giving the historian its own storage tier keeps both the writes and the queries responsive regardless of what else the infrastructure is doing.
The pragmatic default for anything beyond a small site is a dedicated disk tier even if the historian shares a host for CPU. Because the binding constraint is I/O, isolating storage delivers most of the benefit of full dedication at lower cost. You let the historian share compute where compute is not the bottleneck, and you give it uncontended disk where the bottleneck actually lives.
Pitfalls in Historian Placement
The signature pitfall is sizing the historian on CPU and forgetting the disk, then being surprised when a lightly loaded processor sits idle while trends crawl. The historian is I/O-bound; specify its storage throughput first and treat CPU as secondary. A related trap is benchmarking at commissioning tag counts and retention, when the archive is small and everything is fast, and never re-checking as the data grows into the design you actually have to live with.
A second pitfall is co-locating the historian with a bursty neighbor, such as a reporting or analytics job that periodically hammers the disk, so the historian's queries stall whenever the neighbor runs. If you must share, share with quiet workloads and watch the disk metrics. The final trap is ignoring retention tiering entirely, letting all data sit on the fastest storage forever, which makes both a dedicated box and a shared VM more expensive and slower than they need to be as the archive grows.
Frequently Asked Questions
Does the SCADA historian need its own server?
It needs its own disk far more than its own CPU, because a historian is an I/O-bound workload that writes continuously and reads heavily during trend queries. A small site with low tag counts and short retention can share a VM comfortably. Once tag count, retention, or query load grows, give the historian a dedicated storage tier so its writes and queries never contend with other services on the same disk.
Why does a shared historian make trends slow?
Because the historian's steady write stream and heavy trend reads compete with co-located workloads for the same disk I/O budget. When a neighbor gets busy, the historian's queries wait, and the symptom is a long trend that renders slowly at exactly the moment an operator is investigating an event. Isolating the historian's storage removes that contention and keeps trend responsiveness consistent regardless of what else the infrastructure is doing.
How does tiered retention affect the decision?
It shrinks the fast, expensive working set by moving older data to cheaper, slower storage, which keeps the hot tier small and responsive. That can make a shared placement viable for longer and a dedicated tier cheaper to run. Whichever placement you choose, tiering stops both the storage cost and the query latency from growing without bound as the archive accumulates over years of operation.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.