For about two decades, the historian question answered itself. You bought PI System, or you bought AVEVA Historian if you were already an AVEVA/Wonderware shop, or you bought Canary if you wanted something leaner and file-based. The decision was mostly about which incumbent vendor you already had licenses with. Nobody seriously asked whether they needed a historian at all.
That’s no longer true. Unified Namespace architectures built on MQTT and Sparkplug B have moved from conference-keynote novelty to standard reference design, and a UNS needs somewhere to put time-series data once it’s flowing through the broker. A lot of plant IT teams are looking at that requirement and asking a genuinely reasonable question: why not just point the broker at InfluxDB or TimescaleDB and skip the historian license entirely?
It’s a fair question. It does not have a one-size-fits-all answer, and anyone telling you it does is selling something.
What a certified historian actually is
Purpose-built historians — PI System from AVEVA (following AVEVA’s acquisition of OSIsoft), Canary Labs’ historian, and AVEVA Historian (formerly Wonderware Historian) — were designed from the ground up for one job: ingesting extremely high-frequency, extremely long-duration process data reliably, compressing it intelligently, and giving engineers trustworthy tools to get it back out years later.
That design intent shows up in specific technical features that a generic database doesn’t give you out of the box:
- Swinging door / boxcar compression tuned per tag, so you keep the shape of a trend without storing every raw sample, and you can prove to an auditor how the compression was configured.
- Interpolation methods that match physical reality — step, linear, or state-based interpolation chosen per tag type, so a discrete valve state isn’t smeared into a fictional intermediate value the way a naive linear interpolation would render it.
- Built-in contextualization — asset frameworks, unit-of-measure handling, batch and event frames that tie a time range to a work order, lot, or campaign, not just a bare tag and timestamp.
- Calculation engines that run natively against the store (PI AF analytics, Canary’s calculation engine) so derived tags — OEE components, energy intensity, SPC limits — are computed consistently and don’t require a separate compute layer.
- Audit trails and data integrity guarantees that regulated industries actually need: who changed a value, when, and why, with the kind of change history that supports FDA 21 CFR Part 11 or similar validation regimes.
- Decades of interface development — thousands of pre-built connectors to DCS, PLC, and legacy protocols that a plant with a long installed base still depends on.
None of that is marketing fluff. It’s the accumulated result of these products being built specifically for continuous process and batch manufacturing, in industries where “the trend looks about right” isn’t good enough.
What a UNS-plus-TSDB approach gets you instead
InfluxDB and TimescaleDB (Postgres with a time-series extension) are general-purpose databases that happen to be very good at storing timestamped data cheaply and querying it fast. Paired with an MQTT broker publishing Sparkplug B payloads, they form a genuinely credible architecture for a huge share of shop-floor data: machine states, cycle counts, sensor telemetry, energy meter reads, anything that’s going into a dashboard, an alert, or a machine learning pipeline.
The appeal is real and it’s not just cost. It’s architectural flexibility. You get open schemas, SQL or Flux query languages your data engineers already know, containerized deployment that fits a modern DevOps pipeline, and no dependency on a single vendor’s licensing model or roadmap. If your organization is trying to build a plant-agnostic data platform that a cloud analytics team can plug into without learning a proprietary API, that matters.
What you give up is everything in the list above, unless you build it yourself. Interpolation and compression become application logic you write and maintain. Contextualization becomes a modeling exercise in your UNS namespace design and whatever metadata discipline your team actually sustains under deadline pressure — which, in practice, tends to erode. Audit trails, if you need them for a regulated process, become a custom build against a database that wasn’t designed for that use case.
The workload-by-workload test
The most useful way to make this decision isn’t “historian vs. TSDB” as a philosophy. It’s asking, tag group by tag group, whether the workload needs historian-grade guarantees.
- Statistical process control — needs historian-grade fidelity. SPC charts live and die on whether the underlying data was compressed and interpolated in a way that reflects the actual process, not an artifact of storage. Get this wrong and you get false out-of-control signals or worse, false confidence.
- Batch genealogy and regulated audit trails — needs historian-grade guarantees, full stop, if you’re in pharma, food safety, or any process subject to formal validation. This is the workload where “we could build that” is the wrong answer; you want a product with an established validation story.
- Energy reporting — genuinely workload-dependent. If it’s feeding a regulatory disclosure or a contractual demand-response commitment, lean historian. If it’s an internal sustainability dashboard, a well-modeled TSDB is fine.
- ML feature stores and predictive maintenance pipelines — usually fine on a commodity TSDB, and arguably better suited to one, since data scientists want raw, unaggregated series with flexible query access rather than a historian’s engineering-oriented tooling.
- Long-horizon trending for process engineers — leans historian, mostly because the interpolation and compression fidelity compounds over years of storage in ways that are hard to notice until you’re troubleshooting a five-year-old excursion.
Who each approach actually fits
In our assessment, a purpose-built historian is still the right default for continuous process industries, regulated manufacturing, and any plant with a large legacy DCS or PLC estate where the connector library alone justifies the license. If your MES/SCADA refresh touches a validated process, don’t let the UNS conversation talk you out of a historian for that data — it’s the wrong place to save money.
A UNS-plus-TSDB architecture fits best in discrete manufacturing environments building greenfield data platforms, in organizations with real data engineering capability (not just controls engineers moonlighting), and in plants where the primary consumers are dashboards, cloud analytics, and ML rather than process engineers doing forensic trend analysis. It may not suit shops that lack the in-house discipline to maintain a UNS namespace and metadata model over time — a TSDB is only as good as the contextualization someone actually builds and keeps current.
The hybrid pattern is winning for a reason
The architecture we’d point most plants toward isn’t either/or. It’s a UNS as the real-time integration and contextualization layer, with the historian subscribing to it as one more consumer — feeding validated, high-fidelity tags into PI, Canary, or AVEVA Historian for the workloads that need it, while everything else lands in a TSDB for cheap long-term storage and analytics access. This keeps the historian license scoped to the tags that actually justify it instead of every PLC register on the floor, which is often where historian costs get out of hand in the first place.
The mistake to avoid is treating this as a one-time architectural decision made in a MES refresh kickoff meeting. Revisit it workload by workload, because the honest answer for a batch reactor’s critical process parameters and a conveyor’s vibration sensor is rarely the same answer.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
