Losing one means your operators go blind right now. Losing the other means you can't prove what happened six months ago. They are not the same system wearing two names.
It's a common assumption that the "historian" is just where the SCADA server logs its data — a backup copy, or the same database with a longer retention setting. In most real SCADA architectures they're separate pieces of software, often on separate servers, doing genuinely different jobs on genuinely different data models. The SCADA server owns the live, current state of every point — the value right now, whether it's in alarm right now, and the ability to send a control command right now. The historian owns time — a compressed, queryable archive of what every point did over the last five years, built for trend charts and compliance reports, not for driving a control action.
The SCADA server is built to answer "what is the value of this tag right now, and does anything need to happen because of it" — as fast as possible, for every point, continuously. That is a latency problem. The historian is built to answer "what did this tag do between March and September" across years of data without consuming unreasonable disk space — that is a compression and retrieval problem, solved with techniques like swinging-door or deadband compression that discard redundant samples while preserving the trend shape. A system tuned for latency (small, fast, current-value-only) and a system tuned for long-range compressed retrieval (large, deep, time-indexed) are different enough workloads that vendors almost always ship them as separate products, even when they run on the same physical server for a small installation.
A backup restores the same data model it saved — the historian doesn't. It stores a fundamentally different structure: compressed per-tag time series indexed for range queries, not full system-state snapshots the SCADA server could reload to resume operating. If the SCADA server's live database is lost, restoring from the historian doesn't bring back current alarm states, active control sequences, or operator session context — the historian was never built to reconstruct that. It also usually isn't "underneath" the SCADA server in an architecture diagram; it's frequently a peer system that pulls or receives a data feed from the SCADA server (often via OPC) and runs on its own server with its own retention policy, its own compression engine, and often its own separate high-availability strategy. Treating "the historian died" as a non-event because "the SCADA server still has the data" is also wrong the other way — the SCADA server typically only holds a short rolling buffer of recent values, not the multi-year record the historian exists to keep.
Explains why a process historian and a SCADA server are different systems solving different problems — the SCADA server is the real-time operational hub for current tag values, alarms, and control commands, while the historian is a compressed long-term time-series archive optimized for trend and compliance queries. Illustrated with the live data path into a SCADA server and the archival data path into a historian.
Both systems handle the same underlying tags — the same pressure transmitter, the same pump status bit — which makes it easy to assume they're the same database viewed two ways. And in small installations they sometimes do run on one physical server, reinforcing the assumption. But even co-located, they are usually separate software products (a real-time SCADA/HMI platform like a DCS or SCADA package, and a dedicated historian product like OSIsoft PI, Ignition's historian module, or an open-source time-series database) with separate data models, separate retention policies, and separate failure consequences.
The SCADA server's job is real-time state: it holds the current value of every point, evaluates alarm conditions the instant a value crosses a limit, distributes that live state to every connected HMI client, and provides the pathway for an operator's control command to reach the field device. It is optimized for low latency and immediate distribution, typically keeping only a short rolling buffer of recent history — deep archival was never its design goal.
The historian's job is compressed, queryable history: it ingests a feed of tag values (often via OPC from the SCADA server) and stores years of data per tag using compression algorithms like swinging-door or deadband compression, which discard redundant samples while preserving the underlying trend shape within a configured tolerance. It is optimized for answering range queries across long time windows — a trend chart spanning six months, a batch genealogy report, a regulatory submission — not for driving a control action in the next second.
This distinction drives real architecture decisions: how much local buffer the SCADA server needs before data must reach the historian, what happens to trending and compliance reporting during a historian outage (operations continue, but there is a data gap), what happens during a SCADA server outage (operators lose live visibility and control — a much more urgent failure), and how each system's redundancy is designed separately, often with different acceptable recovery times. Sizing a SCADA system (see the SCADA System Designer) requires specifying the historian's retention and compression separately from the SCADA server's real-time tag count and alarm load, because they are genuinely different sizing problems.
Usually a short rolling buffer — recent alarm and event logs, maybe a few hours or days of trend data for immediate operator review — but not the deep, compressed, multi-year archive that a historian maintains. The SCADA server's buffer exists for immediate operational context, not long-term analysis.
It's a common historian compression algorithm that discards data points that fall within a tolerance band of a straight line drawn between the last stored point and the current one — effectively storing only the points needed to reconstruct the trend shape within an acceptable error, rather than every raw sample. This is why a historian can affordably retain years of high-resolution data per tag, something a SCADA server's live database isn't designed to do at that scale.
No. A historian is a read-optimized archive with no operational control interface — it has no path back to an RTU or PLC to change an output. Control commands flow exclusively through the SCADA server (or DCS), which is precisely why losing the SCADA server is the more urgent operational emergency of the two.
Usually yes, at the software level — they remain separate services or products (a real-time SCADA/HMI engine and a historian database engine) even when co-located on one machine for a smaller installation. Larger installations typically split them onto dedicated servers specifically because their performance profiles and failure/redundancy requirements differ.
Regulatory frameworks that require demonstrating what a process actually did over time — EPA environmental discharge reporting, FDA 21 CFR Part 11 electronic records in pharma/food manufacturing, and utility interconnection or NERC reporting in power systems — depend on the historian's long-term, tamper-evident time-series record, not the SCADA server's current-value snapshot.
Try our SCADA Studio
More calculators, simulators, and guides for this discipline.