"We already have a historian, let's put the monitoring data in there." If your monitoring program lives inside a company that runs AVEVA PI, Canary, or their kin, you've heard that suggestion, probably from someone sensible. It's half right. And the half that's wrong isn't a knock on the historian at all.
The short version: a historian is built for the plant floor, and it is excellent there. The watershed is a different place with different rules.
Respect where it's due, and it's due
Let me start by crediting the historian properly, because these systems earn it. A data historian captures high-frequency process data, pressures, temperatures, flows, valve states, etc. from OPC and SCADA sources (the control-system plumbing a plant runs on), at rates and reliability that most software never has to achieve. The compression is genuinely clever. The uptime expectations are brutal, and they're met. Control rooms make second-by-second operational decisions on this data, and have for decades. When I say a historian is world-class at real-time industrial capture, it's true, and it's the reason the complement framing at the end of this post exists.
The distinction I want to draw is about aim, not quality. A control room has one room, one owner, one network, and one question: what is the process doing right now? A watershed or an air monitoring network, or a well field spread across three counties has many owners, scattered sites, borrowed networks, and a different question entirely: can we defend this measurement to someone outside the building, months from now?
What the plant floor never needed
Because historians grew up answering the control room's question, the monitoring job's core needs simply never made it into the architecture. Four gaps matter most.
Gap-preserving harmonization. A historian's storage machinery is built to reconstruct a continuous process signal efficiently: compression keeps the points that matter, and reads interpolate between them. It's the right call when a pipeline's pressure genuinely did exist between samples. And to be fair, historians can mark a true outage rather than paper over it; PI's system digital states and their equivalents exist for exactly that. But marking an outage is a configuration decision, made tag by tag, by whoever administers the archive. Sensor data needs the opposite posture: gap handling as a structural default on every series, set by the person who understands the sensor. In Datasparks, raw data keeps an untouched observed series, and every harmonized view carries an explicit gap tolerance as part of its identity. Past the tolerance, the record stays empty, by default, for everyone. Gaps are data; the practical difference is whether preserving them is the default or a favor you ask of the admin.
Quality rules with provenance. Plant data quality is largely a sensor-health problem, handled operationally. Environmental quality control is an evidentiary problem: named rules, applied consistently, with a permanent record of which rules ran on which data, because "how was this number derived?" arrives from a regulator, not an operator. Datasparks writes that execution record once per pipeline run, immutably. On a historian you'd build this yourself, by hand, on top.
Curated data products. A historian's consumers sit inside the fence: control rooms, engineers, plant dashboards. An environmental program's consumers are mostly outside it. The clients, agencies, communities, and research partners need a governed, versioned dataset with freshness tracking, not a tag browser and a login. Sharing outward is where historian deployments go to die in committee.
Self-serve. This is the quiet one. Standing up a historian is integrator work; extending one is IT/OT work; even reading one usually means asking someone. That's an acceptable cost where the historian is core plant infrastructure. It's a disqualifying cost for a program run by engineers who need to forecast machine replacement timelines themselves, on a Tuesday, without a ticket. Our whole ingestion path, from upload, scheduled fetch, or device push, with column mapping done in a wizard, exists so that the person who understands the data is the person who connects it.
The economics follow the same shape. In our TCO model for a mid-size monitoring network, the historian path runs around $1,100 a month in tooling for a monitoring-scale deployment. Third-party pricing surveys show full historian licensing scaling from roughly ten thousand to well over a hundred thousand dollars a year with tag count, before services, plus roughly $2,500 a month of specialist time in our modeled scenario, landing near $3,600 all-in. For a plant, that's a rounding error on core infrastructure. For a monitoring program, it's the budget.
Complement, not replacement
Here's the boundary, and for once it's not a footnote, it's the actual recommendation. If your organization already runs PI or Canary for operations, keep running it. Ripping out a working historian to replace it with anything is a multi-year regret, and real-time industrial capture is a job we don't do: we ingest files, scheduled API pulls, and webhook push; we are not an OPC endpoint, and nobody should make control-room decisions from us.
The pattern that actually works is layering. The historian keeps doing what it does best in capturing the plant's real-time signals. The research program pulls the relevant slices out, historian exports travel just fine as files and APIs, and does the science downstream: harmonizing historian data with the field loggers or lab results the historian never sees, applying quality rules with provenance, and publishing curated data products to the people outside the fence. Capture stays on the plant floor. Defense of the number happens in the analysis layer. Each system does the job it was built for.
Notice what that harmonizing step actually contains, because it's the part the "just use the historian" suggestion misses. An emissions or groundwater program's evidence is never only process tags: it's the plant's signals plus the fence-line loggers on cellular modems, the quarterly lab results arriving as spreadsheets, the consultant's field readings, all sources that will never speak OPC and were never going to live in the historian. The environmental question is almost always a join across those worlds, on mismatched clocks and vocabularies. That join is the actual work, and it's the work the analysis layer exists to do.
When is the historian alone the right answer? At large industrial scale with a purely internal audience running thousands of high-frequency tags, an OT team, consumers who all have logins. The historian's throughput and maturity are real advantages, and what we add matters less there. If that's your whole problem, you may not need us at all. For most readers of this blog, though, that isn't the whole problem, it's the upstream half of it.
One question to sort it
If you're weighing this, ask one question of your program: who consumes this data, and can they all badge into the building? If yes, then the historian you have is probably enough. If no, if the number has to travel to a client, an agency, a community meeting, then the historian is your capture layer, not your delivery layer, and the gap between the two is exactly the job our 12-point rubric will help you scope. Run it against us and against the historian; the answers will disagree in instructive places.
