SCADA vs OPC vs IoT Platform vs Data Historian: The 2026 Industrial Data Stack Explained
Every industrial data project eventually hits the same wall. Someone draws a box labeled “SCADA,” another labeled “historian,” a third labeled “IoT platform,” and a fourth labeled “OPC.” Then the room argues about which one to buy. The framing is wrong, and that wrong framing wastes budgets.
The honest answer to scada vs opc vs iot platform is that these are not four products competing for one slot. They are four layers that solve four different jobs: supervisory control, interoperability, long-term data storage, and cloud enablement. Most mature plants run all four at once. The skill is knowing which job each layer owns, where they overlap, and where teams accidentally pay twice.
This guide breaks down each layer from first principles, shows how they fit together in real reference architectures, and gives you a weighted decision matrix you can take into a design review. What this covers:
Context and Background
The confusion has a clear root cause. All four technologies touch the same data, so on a whiteboard they look interchangeable. A sensor reading flows from the field, through control, into a screen an operator watches, into a database someone queries, and up to a cloud dashboard a manager opens on a phone. Each layer claims a slice of that path, and the vendors who sell them encourage you to believe their slice is the whole journey.
It helps to anchor the discussion in the Purdue Enterprise Reference Architecture, the layered model that still governs how most plants think about operational technology. Purdue stacks the plant into levels: Level 0 is the physical process, Level 1 is control (PLCs and DCS), Level 2 is supervisory (SCADA and HMIs), Level 3 is operations (MES, historians, scheduling), and Levels 4 and 5 are business IT and the enterprise. The model is a security and data-flow framework, not a shopping list, but it tells you where each technology naturally lives.
SCADA sits squarely at Level 2. A data historian sits at Level 3, close to operations. OPC and OPC UA are not a level at all; they are the connective protocol that lets devices and applications at adjacent levels talk without custom drivers. The IoT platform is the newest entrant, and it deliberately reaches across Levels 3, 4, and 5 to push operational data into the cloud.
Once you place each technology on the Purdue map, the “versus” framing collapses. You are not choosing between a screwdriver and a hammer. You are assembling a toolkit. The ISA-95 standard that formalizes these levels exists precisely because the layers are meant to interlock, not substitute. For the canonical definition of the levels, the ISA-95 / Purdue reference is the authoritative starting point.
There is also a historical reason the four blur together. They arrived in waves. SCADA matured in the 1980s and 1990s as the operator’s window. OPC appeared to stop every SCADA-to-PLC connection from being a custom driver. Historians grew up alongside, because plants discovered SCADA could not remember the past. The IoT platform is the newest layer, born of cloud computing and the desire to analyze plant data far from the plant. Each wave added a capability the previous layer lacked, rather than replacing it.
That layering is why a greenfield team and a brownfield team reach different answers from the same matrix. A new build can design the four layers together from day one. A retrofit must respect decades of installed SCADA and existing historians, and usually adds OPC UA and an IoT platform around what already runs. The technologies are the same; the sequencing differs. The remaining sections take each layer in turn, then reassemble them into architectures you can actually deploy.
The Four Layers Defined
In short: SCADA is the human-facing supervisory control and visualization layer; OPC UA is the interoperability protocol and information model that moves tags between systems; a data historian is the optimized time-series store for long-term process data; and an IoT platform is the cloud-side layer for device management, remote connectivity, and analytics. They overlap at the edges, but each owns a distinct job.
The figure above places the four layers on a single vertical stack. Read it bottom to top: field signals enter control, control feeds SCADA, SCADA writes to the historian and the IoT platform, and OPC UA threads across the middle as the common language. Keep that picture in mind as we define each layer precisely.
SCADA: Supervisory Control and Visualization
SCADA stands for Supervisory Control and Data Acquisition. Its core job is to give operators a live window into the process and a set of controls to act on it. The HMI screens, the alarm banners, the setpoint changes an operator makes at 3 a.m. — that is SCADA.
A SCADA system polls or subscribes to controllers, renders current values on graphics, raises alarms when limits are crossed, and lets operators issue commands back down to the equipment. It is built for the present moment. Its data store, historically, is shallow: enough to draw a trend on screen, not enough to answer “what did this pump do every minute for the last seven years.”
That last point is where teams get into trouble. SCADA can log data, but it is not a historian. Treating its built-in logging as your system of record leads to bloated databases and slow queries. SCADA’s strength is real-time supervision and operator action, not deep retention.
A useful mental test: if the question is “what is happening right now and what should the operator do,” that is SCADA. The system is judged on responsiveness, alarm clarity, and the discipline of its control logic. A SCADA platform that takes three seconds to refresh a critical screen has failed at its one job, no matter how much data it can store.
Modern SCADA has grown well beyond the simple screens of the 1990s. Web-based clients, redundant servers, role-based access, and tighter integration with MES are now standard. But the boundary holds: SCADA orchestrates and visualizes the live process. It is the cockpit, not the flight recorder, and confusing the two is the single most common architecture error in this whole space.
A note on terminology, since it trips people up: SCADA and DCS (Distributed Control System) are cousins, not the same thing. A DCS is tightly integrated control plus supervision for a single process unit, common in continuous industries. SCADA is traditionally more distributed and supervisory, common where assets are geographically spread. For this comparison the distinction matters less than the shared truth that both are the live, operator-facing layer — and both still need a historian and an interoperability protocol behind them.
OPC and OPC UA: The Interoperability Layer
OPC began as OLE for Process Control, a Windows-only way to let SCADA talk to controllers from different vendors without bespoke drivers. The modern successor, OPC UA (Unified Architecture), is platform-independent, secure by design, and carries a rich information model rather than just raw tags.
Crucially, OPC is a protocol and a modeling standard — not a database and not an application. An OPC UA server exposes an address space: a structured, browsable tree of nodes where each node can carry a value, metadata, and relationships to other nodes. A pump is not just “Tag_4471 = 1450”; it is an object with a speed, a status, an alarm limit, and a type definition. That information model is what makes OPC UA more than a wire protocol.
OPC UA does not store history in the long-term sense, even though it defines a Historical Access service. It moves and describes data; persistence is someone else’s job. When people say OPC “connects everything,” they mean it is the glue that lets SCADA, historians, MES, and IoT platforms read the same tags without each integration being a custom project. The OPC UA specification from the OPC Foundation is the definitive reference for the information model and security architecture.
It is worth being precise about the two generations, because the term “OPC” still gets used loosely. Classic OPC (often called OPC DA, for Data Access) depended on Microsoft DCOM, which made it fragile across firewalls and painful to secure. OPC UA replaced that foundation entirely with a modern, transport-agnostic protocol that runs natively over TCP and includes encryption, authentication, and certificate-based trust as first-class features. If a vendor today is still selling you DCOM-based OPC for a new build, treat that as a red flag.
The information model is the part teams most often underuse. Because OPC UA can express types, hierarchies, and relationships, you can model an entire asset — a compressor with its sub-components, limits, and states — once, and expose that structure consistently to every consumer. Companion specifications standardize these models for specific industries, so a robot or a pump can present itself the same way regardless of manufacturer. That semantic layer is what turns raw connectivity into genuine interoperability, and it is the reason OPC UA is the default backbone for serious industrial data architecture.
Data Historian: The Time-Series System of Record
A data historian is a purpose-built database for industrial time-series data. Products like AVEVA PI System (formerly OSIsoft PI), Aspen InfoPlus.21, and Canary exist because generic relational databases choke on the volume and shape of plant data.
The defining feature is compression. Historians use algorithms such as swinging-door compression to store only the points that actually represent a change, discarding redundant samples while preserving the signal. That is how a historian keeps decades of high-frequency data on reasonable storage and still returns a multi-year trend in seconds. The AVEVA PI System reference describes this compression-and-interpolation model in detail.
A historian’s job is long-term retention and fast retrieval, plus the metadata layer that turns tags into meaningful asset context. It is read-optimized for trends, aggregates, and comparisons across time. It is not where operators run the plant — that is SCADA — and it is not the protocol that connects everything — that is OPC. It is the memory of the plant.
Two more properties separate a real historian from a generic database. The first is interpolation. Because compression discards redundant points, a historian must reconstruct values at arbitrary timestamps on read, returning a smooth trend even though the raw stored points are uneven. That retrieval-time interpolation is invisible to users but central to how historians work. The second is the asset framework: a layer that groups thousands of flat tags into named equipment, units, and sites, so an engineer queries “Reactor 3 temperature” rather than memorizing tag IDs.
This is also where the line with modern time-series databases is blurring. Open-source engines built for high-cardinality time-series data now offer compression and fast aggregation that rival traditional historians, often at lower cost and with SQL-style access. For many new projects the choice is no longer “historian or nothing” but “proprietary historian or a purpose-built time-series database.” The job — be the trusted, queryable record of the process over years — stays the same regardless of which engine fills it.
IoT Platform: Cloud Connectivity and Analytics
An IoT platform is the cloud-oriented layer. Its job is device management at scale, secure remote connectivity, data ingestion, and the analytics, machine learning, and dashboards that sit on top. Think AWS IoT, Azure IoT, or a vendor platform layered over MQTT.
Where SCADA assumes a controlled plant network and a fixed set of HMIs, an IoT platform assumes fleets of devices across many sites, intermittent connectivity, and consumers who are data scientists and executives rather than control-room operators. It provides device identity, over-the-air updates, elastic storage, and the compute to run models against streaming data.
The overlap is real and intentional. An IoT platform can ingest and store time-series data, blurring into historian territory. It can present dashboards, blurring into SCADA territory. But it does not control the process in safety-critical real time, and most platforms lean on OPC UA or MQTT to actually reach the equipment. Its true differentiator is scale, elasticity, and the cloud analytics ecosystem — not supervisory control.
The capabilities that genuinely belong to this layer are worth naming. Device provisioning and identity at fleet scale, secure over-the-air firmware updates, elastic storage that grows without a procurement cycle, and managed services for stream processing, anomaly detection, and model training. These are things a plant-floor SCADA system was never built to do and should not be asked to do.
The honest framing is that an IoT platform extends the stack outward rather than replacing anything inside it. It takes a curated subset of plant data — you rarely send everything — and makes it useful to people and systems that live outside the control room: reliability engineers comparing assets across sites, data scientists building predictive-maintenance models, and executives watching enterprise-wide KPIs. When a vendor pitches an IoT platform as a SCADA-and-historian replacement, ask how it handles deterministic control and regulated on-prem retention; the answer usually reveals the boundary.
There is also a spectrum hiding inside the phrase “IoT platform.” At one end sit the hyperscaler building blocks — managed brokers, time-series services, and machine-learning toolkits you assemble yourself. At the other end sit packaged industrial platforms that ship with connectors, asset models, and dashboards out of the box. The build-your-own route offers maximum flexibility at the cost of integration effort; the packaged route trades flexibility for speed and a shorter path to value. Where you land on that spectrum should follow your team’s engineering depth, not a vendor’s slide deck. Either way, the platform consumes plant data — it does not originate or control it.
Where the Four Layers Overlap
Most of the confusion lives in the overlaps, so it pays to name them explicitly. SCADA and the IoT platform overlap on dashboards and visualization, which is why people ask whether one replaces the other. The distinction is intent: SCADA visualization exists to drive real-time operator action with deterministic latency, while IoT dashboards exist to inform analysis and management, where a few seconds of delay is irrelevant.
SCADA and the historian overlap on data logging. Every SCADA package can store some history, and that overlap tempts teams to skip a dedicated historian. The trap is scale and retention: SCADA logging is fine for short trends but collapses under years of high-frequency data, where a historian’s compression and retrieval are purpose-built.
The historian and the IoT platform overlap on time-series storage and analytics. A cloud IoT platform can hold and crunch time-series data, and modern time-series databases erode the historian’s old monopoly. The deciding factors are retention economics, query performance on dense industrial data, asset-context modeling, and whether the data is allowed to leave the building at all.
OPC UA overlaps with nothing on storage or visualization, which is exactly the point. It is the only one of the four that is a protocol rather than an application, so it threads through all the others without competing with any of them. When you find yourself unsure which box owns a capability, ask whether the capability is “move and describe data” (OPC UA), “supervise and act” (SCADA), “remember” (historian), or “analyze at scale and far away” (IoT platform). That four-way test resolves most arguments.
It also helps to state what each layer is explicitly not, because the negatives prevent expensive mistakes. SCADA is not a long-term database and not a fleet-management system. OPC UA is not a data store, not an application, and not a user interface. A historian is not a transactional relational database and not a control system. An IoT platform is not a real-time safety-critical controller and not, on its own, a guarantee of data sovereignty. Keep those four “is not” statements pinned to the wall during any architecture review and most of the recurring confusion simply evaporates.
One Reading Through All Four Layers
Trace a single pump-vibration reading to see the division of labor in motion. A vibration sensor on a pump produces a continuous analog signal. The PLC scans that signal every few milliseconds, applies its control logic, and exposes the value as a tag. So far, no SCADA, no historian, no cloud — just control.
The PLC publishes that tag through an OPC UA server. SCADA subscribes and draws it on the operator’s pump faceplate, raising an alarm if vibration crosses a limit so a human can intervene. That is the live, supervisory job, and it must happen in real time on the plant network.
The historian also subscribes, but with a different purpose: it compresses and stores the vibration trend for years, so a reliability engineer can later compare this pump against its own history and against sister pumps. Finally, the IoT platform pulls a downsampled version of the same tag to the cloud, where a predictive-maintenance model flags the slow upward drift that precedes a bearing failure. One reading, four jobs, four layers — and not one of them could do the others’ work well. That is the whole argument of this article in a single example.
How They Fit Together and a Decision Matrix
Now reassemble the layers. OPC UA is usually the connective tissue. The figure below shows it sitting between the control devices below and the consuming applications above, exposing one consistent information model to all of them.
In a classic plant, controllers publish their data through an OPC UA server. SCADA subscribes to that server for live supervision. The historian subscribes to the same server to persist the data long term. MES and quality systems read it for context, and the IoT platform reads it to push selected tags to the cloud. One server, many consumers, no custom drivers per integration.
Contrast that with the architecture it replaces. Without a shared interoperability layer, SCADA has its own driver to the PLC, the historian has another, MES has a third, and the IoT gateway a fourth. Each driver is a separate integration to build, test, and maintain, and changing a tag means touching all of them. This is the MES, SCADA, and historian integration sprawl that OPC UA exists to collapse. Centralizing on one server is not just tidier; it is what makes adding the fifth or sixth consumer cheap instead of another full project.
The data-flow view makes the division of labor concrete. A signal originates at a sensor, is scanned by a PLC, supervised by SCADA, persisted by the historian, and then mined by analytics and digital-twin models downstream.
That left-to-right flow is the spine of most architectures. SCADA owns the live middle, the historian owns the deep store, and analytics and machine learning feed on the historian rather than hammering the live control network. Keeping heavy queries off the SCADA layer is one of the oldest and most reliable rules in plant data design.
A Weighted Decision Matrix
Use the matrix below to map a job-to-be-done to the layer that owns it. The weight column reflects how decisive that capability usually is when teams choose where to invest. Higher weight means the requirement should pull harder on your d
Figure 4: Modern unified namespace MQTT reference architecture. Edge nodes publish report-by-exception data through an MQTT broker using Sparkplug, and SCADA, the historian, the IoT platform, and ERP all subscribe to the same single source of truth.
