Every SCADA renewal cycle produces the same question from whoever controls the budget: why are we paying for two data platforms when one might do? Ignition 8.3, from Inductive Automation, is the release that’s made that question harder to wave away. Between the rebuilt Perspective workstation experience, a more mature edge tier, and native Sparkplug B support that’s been maturing since the 8.1 line, Ignition now looks less like a SCADA/HMI tool with a historian bolted on and more like a genuine contender for consolidating your historian layer entirely.
The honest answer, after putting the pieces together against what a mid-size plant actually needs from historized data, is: sometimes, and it depends heavily on what you mean by “historian.” Let’s get into where it holds up and where it doesn’t.
What actually changed in 8.3
Ignition 8.3 is built on a modernized Perspective module — new component rendering, a cleaner session architecture, and general performance improvements to the web-based workstation that’s been Inductive Automation’s flagship UI layer since Perspective replaced the older Vision paradigm for most new projects. That’s the headline for operators and HMI designers.
For plant IT and controls engineers thinking about historians, the more consequential story is the edge and cloud licensing model. Ignition’s edge-oriented deployment (running on gateway hardware at the machine or line level) now leans more heavily on Sparkplug B as the default transport for tag data moving from edge to central gateway, using MQTT as the backbone rather than polling OPC UA servers directly across the plant network. That architecture — publish/subscribe, “report by exception,” with Sparkplug’s defined payload structure and birth/death certificates for node state — is a materially different way of moving data than the client-server historian model most plants grew up on.
The core question: is the tag historian actually a historian
Ignition has shipped a tag historian module for years, storing data in whatever SQL backend you point it at (Microsoft SQL Server, PostgreSQL, MySQL, and others). That’s always been fine for trending and basic reporting inside Ignition itself. The question mid-size plants are asking in 2026 planning cycles is whether it’s fine as the system of record that MES, quality, and corporate reporting tools all pull from — the role a dedicated historian like a PI System or Canary Labs’ platform plays today.
Scoring it against the dimensions that actually matter for that role:
Data retention and compression
Purpose-built historians use compression algorithms (swinging door, boxcar-backslash, and vendor variants) tuned specifically for time-series industrial data, achieving high compression ratios while preserving the ability to reconstruct trends accurately. Ignition’s tag historian, storing into a relational database, doesn’t do this natively in the same way — it relies more on your storage engine and retention/partitioning settings than on purpose-built time-series compression. For plants with a modest tag count and multi-year retention requirements, this is a real gap, not a cosmetic one. You can manage it with partitioning strategies and aggressive deadbanding at the tag level, but that’s you doing the historian’s job manually rather than the platform doing it for you.
Query performance at scale
For dashboards and recent-history trending, Ignition’s historian performs well — it’s built to serve Perspective and Vision clients quickly. Where dedicated historians still generally have the edge is long-range analytical queries across large tag counts and years of data, where purpose-built time-series storage and indexing outperform a general-purpose relational backend under heavy analytical load. If your use case is operational trending and recent-shift analysis, this gap barely matters. If quality or process engineering wants to query three years of data across five thousand tags for a capability study, it matters more.
Licensing cost per tag at scale
This is genuinely where Ignition changes the conversation. Inductive Automation’s unlimited-tag, unlimited-client licensing model (per-gateway, not per-tag or per-client) is structurally different from historian licensing models that scale with tag count or data volume. For a plant adding tags every year as it instruments more equipment, that’s a real, structural cost advantage worth taking seriously in a renewal decision — even without putting a number on it, since actual figures depend on your specific deployment, edition, and negotiated terms.
Where the Sparkplug B edge story genuinely helps
The edge tier paired with Sparkplug B does solve a real architectural problem: getting reliable, stateful data out of distributed or intermittently-connected equipment without babysitting individual OPC UA connections. Sparkplug’s birth/death certificate mechanism means the central system knows definitively when an edge node has gone offline versus just gone quiet — a distinction that matters enormously for data integrity in historian consolidation projects, where “was that a real zero or a dropped connection” is a recurring nightmare. For plants consolidating data from multiple sites or retrofitting older PLCs behind edge gateways, this is a legitimately strong pattern, and it’s one dedicated historians typically have to bolt on via third-party MQTT interfaces rather than getting natively.
Who this actually fits
In our assessment, Ignition 8.3’s native historian is a strong fit for plants with moderate tag counts, retention needs measured in months to a couple of years rather than a decade, and reporting needs centered on operational trending, OEE, and MES integration rather than deep long-range process analytics. It’s also a strong fit where the driver is architectural simplification — one platform, one licensing relationship, one team to train — rather than squeezing the last percentage point of compression efficiency out of the data layer.
It may not suit shops that have built serious analytical or predictive-maintenance workflows on top of a dedicated historian’s native time-series query capabilities, or that have compliance-driven retention requirements spanning many years across large tag counts where storage efficiency and query performance at that scale are non-negotiable. For those plants, a hybrid architecture — Ignition as the SCADA/MQTT backbone and edge layer, feeding a dedicated historian for long-term storage and analytics — remains the more defensible choice, even if it means keeping two license lines on the renewal.
The bottom line
Ignition 8.3 doesn’t make dedicated historians obsolete, and treating this release as a wholesale replacement decision would be premature for a lot of mid-size plants. What it does is legitimately shrink the number of situations where you need one. If your 2026-2027 SCADA renewal conversation has been “we need Ignition and a historian,” 8.3 is a good reason to actually pressure-test that assumption against your real retention, query, and analytics requirements — rather than assuming the answer hasn’t changed since your last renewal cycle.
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.
