Every historian decision used to get made once, at commissioning, and then forgotten for a decade. That’s no longer true. The reason is sitting in every MES vendor’s roadmap slide right now: copilots and agentic AI features that promise to answer questions like “why did line 3’s OEE drop this shift” in natural language. Those features are only as good as the time-series data underneath them, and a lot of plants are discovering that their historian — not their MES, not their model — is the actual bottleneck. That’s forcing a real architecture decision this year, not a someday one.
There are two broad paths. One is the turnkey vendor historian — AVEVA Historian or Emerson’s Proficy Historian (formerly GE Proficy) — bought as a product, licensed by tag count, and supported as a unit. The other is a roll-your-own edge stack: Ignition’s built-in Tag Historian writing into a purpose-built time-series database like InfluxDB or CrateDB, stitched together by your own integration team. Both approaches can feed an MES and both can, in theory, feed an AI copilot. They get there very differently, and the differences matter more now than they did five years ago.
What each approach actually is
AVEVA Historian and Proficy Historian are mature, purpose-built products descended from decades of SCADA and DCS data-collection engineering. They’re built around efficient compression of process data, native integration with their respective automation ecosystems (AVEVA System Platform, Emerson/GE control systems), and a support model where you call one vendor when something breaks. Licensing is typically tag-based, and the software ships with client tools for trending, reporting, and calculation add-ons tuned for exactly this use case.
Ignition, from Inductive Automation, takes a different posture. It’s a SCADA/HMI and application platform first, with a Tag Historian module that logs tag data into a backing store you choose — commonly a relational database for smaller deployments, but increasingly a dedicated time-series database like InfluxDB or CrateDB when volume and query performance matter. That’s the “roll-your-own” part: Ignition gives you the collection and tag infrastructure, but you’re assembling the storage and analytics layer yourself, often alongside MQTT Sparkplug B for edge-to-cloud transport and a separate BI or MES layer for context.
Where the roll-your-own stack genuinely wins
In our assessment, the Ignition-plus-time-series-DB pattern earns its popularity honestly. Ignition’s per-server licensing (rather than per-tag or per-client) makes it attractive for plants with large, growing tag counts, and pairing it with InfluxDB or CrateDB gives you a storage engine purpose-built for high-frequency writes and fast range queries — which is precisely what sub-second OEE and TEEP calculations need. If your AI copilot needs to pull a rolling window of tightly-sampled sensor data across many assets, a modern time-series database with proper downsampling and retention policies will often outperform a general-purpose historian tuned for slower process trending.
This path also gives you architectural flexibility that a closed historian doesn’t: you can run the time-series DB at the edge and replicate selectively to the cloud, you can front it with Grafana or a custom API for the copilot instead of being locked to one vendor’s client tools, and you can scale storage and compute independently. For plants already standardized on Ignition for SCADA/HMI, extending it into historian duties avoids adding a second vendor relationship entirely.
Where it gets expensive in ways that don’t show up on the quote
The catch is integration burden, and it’s real. A turnkey historian’s compression, tag configuration, redundancy/failover, and calculation engines are already built and tested as one system. With Ignition plus a time-series DB, your team owns the schema design, retention and downsampling policy, backup and failover strategy, and the glue code connecting historian data to your MES and copilot. None of that is insurmountable — plenty of plants run this stack successfully — but it’s a paid-services or in-house-engineering investment that a lot of buyers underestimate when they compare list prices. “Cheaper software” and “cheaper deployment” are not the same claim, and conflating them is the single most common mistake in this comparison.
There’s also an operational-ownership question. AVEVA Historian and Proficy Historian come with vendor support contracts and a known upgrade path; the DIY stack’s long-term maintenance depends entirely on your team’s bench strength and documentation discipline. If the engineer who built the InfluxDB retention scheme leaves, that knowledge needs to be somewhere other than their head.
A decision matrix that actually matters
Tag volume and sample rate are the first filter. Plants logging a few thousand tags at multi-second intervals rarely need a dedicated time-series DB — either architecture will work, and vendor support may be worth more than the flexibility. Once you’re pushing tens of thousands of tags at sub-second resolution — the regime AI copilots and real-time TEEP calculations actually live in — a purpose-built time-series database starts to pull ahead on raw query latency and storage efficiency, provided someone competent designs the retention and downsampling strategy.
Retention requirements are the second filter. If compliance or long-horizon SPC analysis demands years of raw, uncompressed history, check how each option handles long-term storage costs and query performance against old data — this is a genuine weak point for naive time-series DB deployments that weren’t designed with tiered retention from day one.
Query latency for the consuming application is the third and most 2026-specific filter. An MES copilot answering shift-level questions in near-real-time needs an API layer that can serve fast aggregate queries without hammering raw storage — which either architecture can provide, but only the roll-your-own path lets you choose exactly how that layer is built.
Who fits where
Plants already standardized on AVEVA’s or Emerson’s ecosystem, with existing engineering skill in those tools and a preference for a single support relationship, are usually better served staying with the turnkey historian — ripping it out to chase a trendier stack rarely pays for itself. Plants building greenfield, Ignition-centric architectures, with in-house or contracted integration talent and genuinely high-volume, high-frequency data needs, are the natural fit for the Ignition-plus-time-series-DB pattern. The worst outcome we see conceptually is a plant with modest tag volumes and no dedicated integration capacity trying to assemble a DIY stack because it looked cheaper on paper — that’s where “roll your own” quietly becomes “roll your own outage.”
The honest bottom line: neither architecture is inherently right. The AI copilot didn’t create a new problem — it just made an old, half-ignored one impossible to keep ignoring. Pick based on your actual tag volume, retention needs, and integration bench strength, not on which stack sounds more modern in a vendor pitch.
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.
