Data Historians vs. Time-Series Databases: Which One Does Your Plant Actually Need?

Every PLC, drive, and sensor on a production line throws off a stream of time-stamped values - cycle counts, temperatures, torque readings, fault codes - often dozens of times a second. Somewhere, that stream has to land. For thirty years the answer was a data historian: AVEVA PI System, Honeywell Uniformance, Siemens SIMATIC Historian, GE Proficy Historian. Over the last decade, a second answer showed up on architecture diagrams: the time-series database (TSDB) - InfluxDB, TimescaleDB, QuestDB, AWS Timestream.

Teams increasingly treat this as an either/or decision, and that's the wrong framing. CrateDB's Stephane Castellani put it plainly in an industry panel covered by MarketScale: deciding "historian versus time series database" is how teams end up solving the wrong problem. The more useful question is what each one is actually for, and where the boundary between them sits in your plant.

What a Historian Is Built For

A historian's job is narrow and specific: capture SCADA and PLC data at an established scan rate, store it with compression that preserves process fidelity, and keep it trustworthy enough for a compliance auditor or an insurance investigator to accept years later. That's why historians speak OPC UA and Modbus natively, integrate tightly with the control system they sit beside, and are the tool plant engineers already trust.

The compression is the historian's core trick. AVEVA runs entire technical conference sessions on "exception and compression" filtering in PI System - the swinging-door algorithm that discards readings a sensor would have produced anyway (within a configured deadband) and only stores the points that represent a real change. The result is a dramatically smaller archive than storing every raw scan, without losing the shape of the signal.

What a historian is not built for is joining its own tags against an ERP record, running a Python model over eighteen months of vibration data, or answering "what was average OEE across all twelve plants last quarter" without someone building a separate reporting layer on top. That's a different workload, and it's where the second tool comes in.

What a Time-Series Database Adds

A TSDB is a general-purpose database tuned for one shape of data: a timestamp, a value, and some tags - and built for horizontal scale and open access. InfluxData, which makes one, frames the decision in exactly these workload terms rather than a protocol fight: the question is whether you need SQL, Python, and ML tooling to query the data directly, and whether you need it to scale across sites rather than one line.

That openness is the point. A data scientist can run a notebook straight against a TSDB. A TSDB can ingest from MQTT, Sparkplug B, or OPC UA just as easily as a historian can - protocol support stopped being the dividing line years ago. What it usually lacks, out of the box, is the OT-native trust, asset modeling, and audit controls that make a historian the system of record on the plant floor.

A Worked Example: Feeding an OEE Dashboard

Take a stamping line with three presses. Each PLC exposes cycle count, downtime reason code, and reject count as OPC UA tags, scanned once per second.

1. At the edge, a historian subscribes to those OPC UA tags directly from the PLCs. It applies exception/compression filtering, stores the raw history, and becomes the plant's system of record - the tags an auditor or a maintenance engineer trusts six months from now.
2. In parallel, the same tags are republished over MQTT/Sparkplug B into a plant's unified namespace, where a TSDB subscribes and stores the stream in a schema built for cross-line queries.
3. Downstream, a reporting layer queries the TSDB - not the historian - to compute Availability × Performance × Quality across all three presses and roll it up against the other six lines in the plant. (If you haven't worked through the mechanics of that calculation, our guide to OEE and the OEE calculator walk through it with real numbers.)
4. The historian never has to answer a cross-line query, and the TSDB never has to be the compliance record. Each does the job it's actually good at.

This is also the pattern behind most of the industrial AI pilots that stall on data problems rather than model problems - a model trained against raw historian exports, with no normalized tag schema or cross-line context, tends to disappoint, however good the algorithm is.

Where Plants Actually Land: a Hybrid

In practice, the dominant pattern for plants with real scale isn't "replace the historian" - it's add a TSDB alongside it, fed by the same source tags, for the workloads the historian was never meant to carry. The historian stays the OT system of record close to the control system; the TSDB becomes the open layer that IT, data science, and cross-plant reporting tools query. This mirrors the broader IT/OT convergence pattern showing up across manufacturing: keep the trusted OT path intact, and add an IT-native layer beside it rather than on top of it.

The market pressure behind this is real, even if the exact figures vary by analyst. Precedence Research sized the global industrial IoT market at roughly $602.87 billion in 2026, projecting it to reach $2.43 trillion by 2035 - a 16.8% compound annual growth rate. That volume of new sensor and machine data is exactly what's pushing plants that have run a single historian for a decade to add a second data layer rather than swap one out.

How to Decide What You Actually Need

Before buying or building either layer, work through these questions:

• Do you need an audit-grade, OT-native record today? If a historian is already running and trusted by your controls team, don't rip it out - extend it.
• Does anyone need to query across lines, plants, or against ERP/MES data with SQL or Python? That's a TSDB (or a lakehouse) workload, not a historian one.
• What's your actual data volume and retention need? A single line's tag count rarely justifies a new platform; a multi-plant rollout usually does. Our ROI calculator is a reasonable starting point for weighing a new data-layer project against the manual reporting it replaces.
• Who owns each layer? Controls engineering should keep the historian close to the machines; IT/data teams should own the TSDB and what's built on top of it. Blurring that boundary is a common reason these projects stall.

If any of this terminology is unfamiliar, the glossary has entries for OPC UA, MQTT, Sparkplug B, and unified namespace, and our courses cover the IT/OT architecture this pipeline sits inside in more depth.

The historian isn't going away, and the time-series database isn't a replacement for it. They solve different problems that happen to look similar on a timestamp axis. Most plants that get this right end up running both - deliberately, not by accident.

Sources: AVEVA ("Exception, Compression, and their Impacts on AVEVA PI System Performance," conference session); InfluxData, "How Do You Choose Between a Data Historian and a Time Series Database?"; MarketScale/CrateDB (Stephane Castellani); Precedence Research, industrial IoT market sizing (2026).