Every SCADA project reaches a point where someone has to decide how much server to buy. Order too little and the runtime lags, alarms queue, and clients stutter under load; order too much and money is tied up in cores that never run hot. SCADA server sizing is the discipline of turning a design's real workload - its tag count, client sessions, scan rate, alarm activity, and historian throughput - into a defensible CPU and memory specification with headroom to spare. This guide explains what drives the load, how the common rules of thumb work, and why under- and over-provisioning both carry a cost.
SCADA server sizing in one line: SCADA server sizing is the process of specifying the CPU cores, RAM, and headroom a SCADA or HMI server needs by estimating its compute and session load from the number of tags, connected clients, scan rate, and alarm and trend activity. It is about the processing and memory required to run the runtime responsively, not about how much disk the historian needs to retain data over time, which is a separate storage-sizing exercise.
The load on a SCADA server comes from several streams of work happening at once, and sizing means understanding how each one grows. The largest and most predictable driver is the tag count multiplied by how often each tag is scanned. A server polling ten thousand tags once a second is doing far more per-second work than one polling the same tags once a minute, because every scan means reading a value, checking it against alarm limits, updating internal state, and pushing changes to anyone watching. Scan rate and tag count together set a baseline of steady processing that the machine must sustain without falling behind.
Layered on top of that baseline are the more variable loads. Each connected client session consumes memory and CPU to maintain its subscriptions, redraw its screens, and receive updates, so a control room with a dozen operator stations and a web portal serving occasional viewers costs more than a single local HMI. Alarm activity is bursty and can spike hard during an upset, when hundreds of alarms may raise, annunciate, and log in a short window. Trend and historian writes add a continuous stream of work as sampled values are collected and handed off for storage. Sizing has to account not just for the calm average but for the busy moments when several of these peak together.
This is why vendors publish per-tag and per-client budgets rather than a single machine recommendation. A budget expresses roughly how much processing and memory one tag or one client consumes on their runtime, so an integrator can multiply by the project's real numbers to estimate load. These budgets let sizing scale with the design instead of relying on a one-size guess, and they make it clear that two projects with the same tag count but very different client counts or scan rates will not need the same server.
CPU sizing generally works from the sustained scan-and-process workload. The more tags scanned per second and the more alarm and calculation logic that runs against them, the more cores are needed to keep the scan cycle from slipping. A useful mental model is that the runtime must complete each scan cycle comfortably within its interval; if the work per cycle grows to fill the whole interval, the server has no slack and any burst pushes it into backlog. Adding cores lets the runtime spread parallelisable work such as multiple device drivers, client update threads, and historian collection so no single stream becomes a bottleneck.
RAM sizing is driven by how much has to be held resident: the live value and configuration of every tag, the buffers for trends and pending alarms, the state of each client session and its open displays, and the operating system and runtime themselves. Large tag databases and many concurrent clients push memory up, and running short on RAM is especially punishing because paging to disk cripples a real-time system. The guiding rule is to hold the entire working set comfortably in memory with room left over, never to size RAM so tightly that a busy period forces the machine to swap.
Headroom is the deliberate margin above the expected peak, and it is the part sizing most often gets wrong. A server sized to run at its limit under normal conditions has nothing left for an alarm flood, a maintenance client that opens every screen, or the tag growth that every live plant experiences. A common discipline is to size for the busy-hour peak and then leave a substantial buffer on top - enough that the machine still has spare CPU and memory when everything happens at once - so the system degrades gracefully instead of falling over exactly when operators need it most.
Under-provisioning and over-provisioning each have a price, and good sizing balances them. An undersized server shows up as sluggish screen updates, alarms that arrive late, scan cycles that overrun and drop data, and a system that becomes unusable precisely during the upsets it exists to manage. Those are operational failures with real safety and production consequences, and fixing them after commissioning is disruptive. An oversized server, by contrast, wastes capital and rack space and power on cores and memory that sit idle, and while that is safer than being undersized, it is money that could have gone elsewhere. The goal is enough compute for the real peak plus honest headroom, not the largest machine available.
Cloud and hosted SCADA change the shape of this problem without removing it. When the runtime lives on managed infrastructure, capacity can often be adjusted after the fact by scaling the underlying instance rather than replacing a physical server, so an early estimate that proves low is far cheaper to correct. That elasticity is valuable, but it does not excuse skipping the sizing exercise, because you still pay for whatever you provision and a badly undersized instance still lags. The discipline of estimating load from tags, clients, scan rate, and alarm activity remains the same whether the target is a rack server or a cloud instance.
A cloud SCADA platform such as Merobix is well suited to fleets of remote sites where tag counts and client patterns are known up front but grow over time, as new wellpads, tanks, or compressor stations come online. Centralising the runtime means capacity is planned and scaled in one place rather than reprovisioning a server at every site, and the same sizing thinking - how many tags, how fast they scan, how many people watch, how bursty the alarms - drives the decision. For a distributed oil and gas operation, that turns server sizing from a recurring per-site headache into a single, adjustable capacity plan.
Server sizing is about compute and memory: the CPU cores and RAM needed to scan tags, serve client sessions, and process alarms responsively at your peak load. Historian storage sizing is about disk: how many gigabytes are needed to retain sampled values for the required period. A server can have plenty of CPU and RAM but too little disk, or vice versa, so the two are estimated separately even though they run on related hardware.
Because two systems with the same tag count can have wildly different loads depending on scan rate, client count, and alarm activity, no single machine recommendation fits everyone. A per-tag or per-client budget expresses how much processing and memory one unit of work consumes on that vendor's runtime, so an integrator can multiply by the project's real numbers. This lets sizing scale with the actual design rather than relying on a generic guess.
Enough that the machine still has spare CPU and memory during its busiest moment, not just during a calm average. Alarm floods, maintenance clients opening every screen, and steady tag growth all push load above the everyday norm, so sizing to run at the limit under normal conditions leaves nothing for those events. A common approach is to size for the busy-hour peak and then add a substantial buffer on top so the system degrades gracefully rather than failing under stress.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.