What a Data Historian Actually Is: The Complete Guide for OT Leaders (2026)

Ask a plant whether it has a data historian and the answer is usually yes. Ask what it is, and the answer is usually the SCADA, logging tag values into whatever database came with it, configured once at startup and left alone. That is not the same thing. A data historian is a specific set of jobs: collecting from the plant, surviving outages, compressing without losing the signal, keeping a quality flag on every value, and answering questions across years. Most of the plants we see do not have one.

That gap stays invisible until someone asks a question the logging was never built to answer. What happened on Line 3 at 2 a.m. during the network outage? Why do two reports show different averages for the same tag? Why does a one-year trend take so long to load that people stop asking for it? Each of those is a job a historian does and a default database does not.

This guide is for the engineering manager or director who keeps hearing “historian”, “time-series database”, “unified namespace” and “we already log to SQL” used as if they meant the same thing. It covers:

• the seven jobs a historian does, and why storage is the smallest of them
• what is not a historian: SQL, time-series databases, MQTT and UNS brokers, Kafka and SCADA logging, and what each actually guarantees
• why most plants run without one, and when a standard database is the right call
• architecture from the edge to the cloud, and where the historian sits next to ISA-95 and a UNS
• who owns which historian in 2026, how they differ, and how AVEVA PI System and Ignition approach the problem
• how to decide whether your plant needs one, and what to ask any vendor

What is a data historian?

A data historian is software that collects time-stamped values from plant systems and stores each one as a tag, a timestamp, a value and a quality. It survives network outages, keeps years of data at useful resolution, and serves it back to engineers in the shape they ask for. Storage is the smallest of its jobs.

Each stored sample has four parts. The tag names the signal: a filler’s outfeed rate, a tank level, a pump’s running state. The timestamp says when the value was true. The value is the number or the state. The quality says whether the value can be trusted. OPC UA, the standard most modern plant connectivity is built on, carries the same structure: every value travels with a status code that states whether it is good, uncertain or bad (OPC UA Part 4, StatusCode).

The category grew up in the process industries in the 1980s, where a continuous process needed a continuous record. You will hear it called a process historian, an operational historian, a plant historian or an industrial historian. They name the same thing.

A historian sits between the controls layer and everyone who asks questions of it. It reads from PLCs, DCSs and SCADA. It is read by process engineers, quality, maintenance, reports, the MES and analytics tools. That position is why the choice matters more than its price suggests: every system above it inherits what it kept and what it threw away. For how we approach that layer on real projects, see how we approach the SCADA and historian layer.

What people say	What they usually mean	What it should mean
“We have a historian”	The SCADA logs some tags to a database	A system that does the seven jobs below, managed as one
“Process historian”	PI or a control-system vendor’s historian	The same category as any data historian
“The database”	A SQL Server or MySQL instance next to the HMI	A store. It may host a historian layer; it is not one on its own
“The UNS”	An MQTT broker with a topic tree	Current state, organised. Not history

What does a data historian actually do? Seven jobs beyond storage

A historian does seven jobs. It collects from the plant, buffers through outages, filters and compresses without losing the shape of the signal, keeps a quality flag on every value, answers queries in several retrieval modes, organises tags into assets, and gives operators and engineers tools they will actually open. A general database does one of these: it stores.

1. Collection and connectivity

A historian ships the drivers that read from the plant: native protocols for PLCs and DCSs, OPC UA, and the older OPC HDA. It decides whether to poll or subscribe, and at what rate.

Polling reads a value at a fixed interval whether or not it changed. Subscription asks the source to report when the value changes. Either way, the collection rate sets the floor on what the record can ever show: an event shorter than the poll interval may never reach the historian at all. That is a controls question as much as a historian question, and we covered it in why a one-second poll misses fast PLC events.

Reading history back has its own standard. OPC UA Part 11, Historical Access, defines how a client reads raw and processed history from a server, and succeeds the older OPC Classic HDA specification. Aggregates such as minimum, maximum and average are defined in Part 13. A historian that speaks Part 11 can be read by tools its vendor never wrote.

2. Store-and-forward

Store-and-forward means the collector keeps writing to a local buffer when it cannot reach the historian, then sends the backlog in order when the link returns. Without it, every network blip or server restart becomes a permanent gap in the record.

The major historians document it. Canary, Proficy, Timebase and Inductive Automation all describe store-and-forward in their own documentation, and AVEVA PI System buffers on the collecting node through the PI Buffer Subsystem. The details differ, and they matter:

• Where the buffer lives. Memory, disk, or memory then disk. A buffer held only in memory is lost if the collector itself restarts.
• How big it is. Hours or weeks. That decides whether a long outage is survivable.
• What happens when it fills. Oldest data dropped, newest data dropped, or collection stopped.

Its absence is the most common silent gap we find. The trend has a hole that lines up with a network event, and six months later nobody can explain it.

3. Exception, deadband and compression

Most historians filter twice. Exception reporting at the collector drops values that have not moved more than a set deviation. Compression at the archive then drops points that lie on a straight line between the points it keeps. Together they cut storage by keeping the shape of the signal, not every sample.

AVEVA’s own explanation of PI System is the clearest public example. Exception is a “simple deadband to filter noise”, performed by the interface that collects the data, which reduces the events sent to the archive and saves network bandwidth. Compression then uses the swinging door algorithm “to eliminate data that can safely be recreated with interpolation”, with the stated goal to “filter out instrument and process noise and still record significant process changes” (AVEVA, Exception, Compression, and their Impacts on PI System Performance, 2023).

Swinging door compression keeps a point only when the signal leaves a corridor drawn from the last stored point. While new values fit inside the corridor they are discarded, because a straight line between stored points reproduces them within the deviation you set. When one falls outside, the last point inside is stored and a new corridor starts. A flat signal costs almost nothing to store. A spike is always kept.

The method is older than most of the software that uses it. Edgar H. Bristol patented it for The Foxboro Company: US Patent 4,669,097, filed on 21 October 1985 and granted on 26 May 1987.

The trade-off fits in one line: compression keeps the shape and drops the points on the line, and bad settings drop the shape. Some data is not compressed at all; AVEVA notes, for example, that out-of-order data bypasses compression in PI. Tuning values belong to a separate guide. The rule for this one is that settings are chosen per signal, by someone who has looked at the real signal.

From a project. On a pneumatic conveying system, the weight signal was noisy enough that a naive integration of weight deltas turned noise into phantom consumption. The deadbands and filtering were set during commissioning against how the real signal behaved, because a report built on the noise is the report the plant stops trusting.

4. Quality codes

Every value a historian stores carries a quality: Good, Uncertain or Bad, with a sub-code for the reason. That is what lets a report tell a failed transmitter from a true zero.

OPC UA defines the three severities and a sub-code that explains them, such as a sensor failure or a lost connection. Without quality, a level transmitter that failed at zero and a tank that is genuinely empty look identical in the record. In aggregates, bad data should dominate: an average over a period that includes bad values should say so, not quietly average them in. A historian that drops quality on the way in cannot put it back.

5. Retrieval and interpolation modes

A historian answers the same question several ways: the values it actually recorded, values interpolated at the timestamps you ask for, or a reduced set drawn for a trend. Two tools can report different averages for one tag because they asked in different modes.

PI calls these recorded, interpolated and plot values. Proficy calls them sampling modes. Ignition’s query functions list both a time-weighted “Average” and a “SimpleAverage” among their aggregates. The difference is not academic. A time-weighted average weights each value by how long it held. A simple average of stored samples counts each stored point once, and because compression keeps more points where the signal moved, a simple average leans toward the busy periods. Same tag, same hour, two numbers. The fix is to name the retrieval mode in every report specification.

6. Asset model and context

An asset model groups raw tags into equipment, with templates so that ten identical fillers are described once. Without it, the historian is a long list of tag names that only the person who configured it can read.

PI Asset Framework is the best-known example. It organises tags into elements and attributes, uses templates for identical equipment, and records events such as a batch or a downtime period as event frames. Other historians do the same job with asset views, UDTs or a namespace. Context is where most historian projects stall: the data is collected, and nobody outside the original team can find it. A shared naming standard is what fixes it; see our work on tag standards and contextualisation.

7. Client tools people actually open

A historian comes with the tools that put the data in front of people: trend viewers, an Excel add-in, displays and an API. If no operator or engineer opens them, the historian is a cost, not an asset.

In many plants the most-used historian client is still a spreadsheet add-in, because that is where the daily report lives. Trend tools serve operators and process engineers. APIs serve analytics, MES and anything new. Adoption is the test: a historian nobody queries is storage with a licence fee.

What is not a historian: SQL, time-series databases, MQTT and UNS brokers, Kafka and SCADA logging

Each of these stores or moves time-stamped data, and each guarantees something real. None of them, on its own, does the historian’s seven jobs. A broker holds the current value. Kafka holds a replayable stream for a set retention period. A database holds rows. SCADA logging holds what the SCADA happened to poll.

	Data historian	Relational (SQL) database	Time-series database	MQTT broker / UNS	Kafka / event log	SCADA built-in logging
Built to answer	What did this process do, at what quality, over years	Business records, transactions and joins	Fast writes and queries on time-stamped series	What is the state right now	What happened, in order, replayable for a set period	What the SCADA saw at its poll rate
Plant connectivity included	Yes: drivers, OPC UA, OPC HDA	No	No; collectors are separate products	No; clients publish to it, it does not poll	No; connectors are separate	Yes, to its own tags
Store-and-forward	Yes, at the collector	No	Depends on the collector you add	Session queueing for clients, not a history buffer	Producers retry; the cluster is durable	Varies by product; often not configured
History retained	Years, by design	Whatever you build and maintain	Yes, by retention policy	One retained message per topic	For the topic’s configured retention period	Whatever the database holds, often unmanaged
Exception and compression	Yes: deadband plus swinging door or similar	No, unless a historian layer adds it	Downsampling and retention, not process compression	No	No	A basic deadband, if set
Quality per value	Yes: Good, Uncertain, Bad	Only if you model it	Only if you model it	Only inside the payload, for example Sparkplug	Only inside the payload	Varies
Interpolation and retrieval modes	Yes	You write them	Some functions	No	No	Limited
Asset model and context	Usually: asset templates, event frames	Your schema	Tags or labels	Topic hierarchy, current state only	Topic names	Tag folders
Tools operators open	Trends, Excel add-in, displays	Reports you build	Dashboards you build	None	None	Its own trend screens
Is it a historian?	Yes	No; it can host one	No; it can sit inside one	No; it feeds one	No; it can feed one	Sometimes enough; rarely managed as one

Relational (SQL) database

A relational database is excellent at transactions and joins. It has no plant collection, buffering, exception or compression behaviour of its own. A historian layer can run on top of one, and some do; the distinction is the layer, not the engine.

Inductive Automation’s SQL Historian is a clear example of that layer. IA says it “automatically supports compression, partitioning, interpolation, and aggregation for any SQL database” (Ignition historian modules). Those four words are the jobs a bare database does not do. Without a layer like that, every one of them is code someone in the plant wrote, and the next section covers when that is fine and when it breaks.

Time-series database

A time-series database (InfluxDB, TimescaleDB, QuestDB and others) is a storage and query engine tuned for time-stamped data. It is fast. Plant connectivity, store-and-forward, OPC quality handling, an asset model and operator tools come from other products you add around it.

These engines are moving quickly. InfluxDB 3 Core and Enterprise became generally available on 15 April 2025, and Timescale renamed itself Tiger Data on 17 June 2025, keeping TimescaleDB as the name of its PostgreSQL extension. None of them ships the seven jobs as one product, which is why the right mental model is a time-series database inside a historian, not instead of one. Ignition 8.3’s Core Historian is exactly that: a historian built on QuestDB.

MQTT broker and unified namespace

An MQTT broker keeps the latest value: at most one retained message per topic, replaced on the next publish. A unified namespace is an architecture for sharing current state across the plant. Neither one keeps history. Something has to subscribe and record it.

The MQTT 5.0 specification is explicit: a new retained message on a topic replaces the one before it (MQTT 5.0, section 3.3.1.3). That is the right behaviour for current state and the wrong one for history. A unified namespace organises that current state by a shared hierarchy, and pushing bulk history back through the broker is a poor fit. As Vlad put it at Automate 2026, a historian and a UNS are “very different in nature.” For the broker’s side of the story, see what a UNS broker is built to do.

Message queue and Kafka

Kafka keeps events after they are consumed, for a retention period set per topic, so a consumer can replay them. That makes it a durable, replayable log. It is not a historian: no interpolation, no quality semantics, no asset model and no trend an operator opens.

Apache’s own description is the useful one: events are not deleted when they are read, and each topic keeps them for a configured period before discarding them (Apache Kafka introduction). That makes Kafka a good way to feed a historian or a data platform, and a poor substitute for either. The two tools are often confused with MQTT as well; Kafka and MQTT solve different problems.

SCADA built-in logging

SCADA logging records the tags the SCADA polls, at the SCADA’s rate, usually into a relational database that nobody manages as a historian. For one line, a few hundred tags and a short memory it can be enough. It stops being enough when questions cross lines, years or outages.

This is the “default database” most plants are actually running. It was switched on during commissioning, it works, and nobody owns it. The signs it has run out are predictable: gaps after outages, slow long-range trends, and nobody who can say how long data is kept or who changes the schema. Historian versus MES, which covers genealogy, orders and work, is a different question for a different guide.

Why most plants do not have a historian, and when a database is the right call

On the projects we see, a dedicated historian is the exception. Most plants log to the database their SCADA or HMI vendor shipped, configured once at startup. That works for a while. It stops working at larger sites and longer horizons, where custom storage and retrieval logic becomes the bottleneck and long trends load slowly.

Here is the pattern from the plants I see. Among plants that deployed Ignition, roughly two in ten went on to deploy a proper historian. The other eight kept their tag history in a general-purpose relational database, usually the one that was already on the server. That is my observation from the Ignition sites I have worked on or assessed as a consultant, mostly in food, beverage and consumer goods. It is not a survey, and the plants that call a consultant are not a random sample. But the direction is consistent enough that I would not expect a plant to have a historian unless someone can show me one.

I understand why. Before founding Joltek, I did a lot of data work at Kraft Heinz and Post Holdings, deploying data solutions from the PLCs on the plant floor all the way up to MES: structuring the data, funnelling it through concentrators, and standing up the databases, servers and historians behind it, mainly on the Rockwell side. Most of that work ran on databases. A database is familiar, IT already knows how to back it up, and it is usually already licensed.

There is nothing inherently wrong with using a standard database for plant data. The catch is that the database does not know what plant data is. You have to write your own logic for how data is stored and how it is retrieved: which values get written and when, how a gap is marked, how a long trend gets thinned out before it reaches a screen, how an average is calculated. Done well, that works. Done casually, it creates bottlenecks, especially at larger sites, and the symptom everyone sees is a trend or a report that takes far too long to load, because the data was not stored or processed in a way that suits the question. Historians are built for exactly that case: fast queries over a lot of data, with the storage and retrieval logic already written, tested and supported.

When a standard database is the right call. It is a reasonable choice when:

• the scope is small: a line or two, a modest tag count, and questions that look back weeks rather than years
• the SCADA puts a historian layer on top of the database, so compression, partitioning and retrieval are handled by the product rather than by plant code (Ignition’s SQL Historian is an example)
• the data is mostly transactional (counts, batch records, downtime reasons) and belongs in tables anyway
• someone owns it: the schema, the retention, the indexes and the backups have a named person

When it stops being enough. Three symptoms a manager can check this week:

1. Gaps after every network blip. Nothing buffered while the link was down, so the record has holes nobody can explain later.
2. Nobody can say what “the average” means. Two reports disagree about the same tag because each one calculates it differently.
3. Long trends that crawl, and tags nobody can find. A one-year trend of a single tag loads so slowly that people stop asking for it, and the tag list is a flat export that only its author can read.

If two of those are true, the question is no longer whether a historian adds value. It is how much the workaround is costing. My advice is the same in either case: research what a historian would add before deciding you do not need one. Most plants that skip it never made that decision. It was made for them by whatever came on the SCADA server.

Data historian architecture: edge, site, enterprise and cloud

Most plants need one site historian fed by collectors with store-and-forward. An edge historian buffers at the machine when the link is unreliable or a skid must keep its own record. An enterprise or cloud tier replicates sites for cross-plant questions. The tiers describe where data lives and who reads it, not different kinds of product.

Tier	What it is for	What it guarantees	Typical failure
Edge	A machine, skid or remote asset that must keep its own record	Local history through a link outage, forwarded later	Buffer too small, or nobody checks that it forwarded
Site	The plant’s system of record for process data	Collection, compression, quality and retrieval for the site	Configured once, never maintained
DMZ replica	Read access for business users without reaching into the OT network	A read-only copy	Becomes the place people write to
Enterprise or cloud	Cross-plant comparison and analytics	Replicated full data or summaries	Each site’s tags mean something different

The site historian is the system of record. It collects from the plant’s controllers through collectors that buffer, applies compression and quality, and serves the site’s engineers and reports. For most single-site manufacturers this is the whole architecture, and getting it right matters more than any tier above it.

The edge exists for links you cannot trust. A skid, a remote pump station or a machine on a wireless link keeps its own history and forwards it when the connection returns.

From a project. On a pasteurisation skid, the specification held at least 30 days of local history on the edge PC, at one-second resolution for critical process variables and five seconds for the other analog values, and synchronised that history upstream with no change to the PLC program. The skid keeps its own record through an outage, and the site gets the full record when the link returns.

The enterprise tier replicates, it does not replace. AVEVA describes the classic pattern for AVEVA Historian: site, or tier-1, historians send full data or summaries to a central tier-2 historian. Canary traces the labels “site”, “enterprise” and “cloud” historian to when each became common rather than to different technology, and says it uses the same technology at every tier (Canary, 2021). That is a fair warning when a proposal prices the tiers as different products. Business users are usually served from a read-only copy on the boundary between the plant and enterprise networks; we cover that boundary in the plant-to-enterprise boundary and its DMZ.

Cloud options exist and keep changing. AWS IoT SiteWise Edge became generally available in July 2021. Microsoft retired Azure Time Series Insights on 7 July 2024 and points customers to Fabric Real-Time Intelligence or Azure Data Explorer. Several historian vendors now offer a cloud edition alongside the on-premises one, including AVEVA (CONNECT data services) and Velotic (Proficy Historian Hyperscale).

Multi-site is a naming problem before it is a technology problem. The pattern we see every time a food company grows by acquisition: each plant arrives with its own controls, its own historian and its own definition of what a case is. The cost shows up the first time corporate wants one number across all of them. Replication does not fix that. A shared naming standard and asset model do.

Where does the historian sit in ISA-95 and a unified namespace?

In ISA-95 terms the historian usually spans Level 2, where it collects, and Level 3, where site operations read it. In a unified namespace it is a subscriber: the broker carries current state, and the historian records it with quality and context so the plant can ask about last March. One does not replace the other.

The historian’s place in ISA-95 is genuinely in between. Its collectors sit with supervisory control at Level 2, close to the controllers they read. Its archive and clients serve Level 3, manufacturing operations: production reporting, quality, maintenance and the MES. In the network model, the business copy usually sits in the DMZ. For what the standard assigns to each level, see what ISA-95 actually assigns to Levels 2 and 3.

In a unified namespace architecture, the pattern is simple and often drawn wrong:

1. Machines and systems publish current state to the broker, organised by the namespace’s hierarchy.
2. The historian subscribes to the topics it needs and records every change, with timestamp, quality and context.
3. Anyone who wants history queries the historian. Nobody replays history through the broker.

The link between the two is naming. The same ISA-95 equipment hierarchy should name the UNS topics and the historian’s asset model, so that a tag means the same thing in both and nobody maintains a mapping table between them.

The data itself: tags, resolution, retention and compression trade-offs

Decide the questions first, then the tags, sample rates and retention that answer them. Resolution should follow the signal, not a plant-wide default. Compression trades points for storage while keeping shape. Retention is set by whoever owns the business and regulatory need for the data, not by the size of the disk.

The most common mistake is a single rule for every tag: everything at one second, everything compressed the same way, everything kept until the disk fills. Signals behave differently, and so do the questions asked of them.

Tag class	What to collect	Resolution principle	Compression stance	Who owns retention
Fast analog (pressure, flow)	The variable that explains the process	Fast enough to see the event you care about	Compress; check against a raw sample	Process engineering
Slow analog (tank level, temperature)	Values that drive quality or planning	Slower; follows how fast the process actually moves	Compress harder	Process engineering
State or discrete (running, faulted)	Every change	Every transition, timestamped	Never compress state changes away	Operations
Counter or totaliser	The raw count and its resets	Every change, or at the count’s own rate	Light; resets must survive	Operations and finance
Setpoint and mode	Every change, with who changed it if available	Every change	Do not compress	Quality
Quality-critical (critical control points, release parameters)	Exactly what the quality system requires	As specified by quality	As specified by quality, and documented	Quality and regulatory

Three principles sit under that table. Never compress away the reason a value changed: a state, a setpoint or a mode change is the explanation for the analog trend next to it. Do not trust “typical” tag counts or sample rates from anyone, including us; there is no reliable public source for them, and the right number comes from the questions. And let the quality and regulatory owner set retention for regulated records; the historian team implements it, it does not decide it.

Not all plant data is numeric. Images, waveforms and documents belong in a store built for them, linked to the historian by time and asset.

From a project. At one consumer-goods plant, vision-system images were kept only on the camera. Trend analysis across shifts was close to impossible, because every question meant pulling files off a device one at a time. The value was never in an individual image. It was in the trend across thousands of them.

Data historian software in 2026: who owns what, and how they differ

The main historians in 2026 are AVEVA PI System and AVEVA Historian (Schneider Electric), Proficy Historian (Velotic, owned by TPG), AspenTech InfoPlus.21 (Emerson), Honeywell Uniformance PHD, Siemens SIMATIC Process Historian, Yokogawa Exaquantum and ABB Ability History, alongside Ignition, Canary, dataPARC, Timebase and Factry. Several brands share an engine, which matters more than the logo.

What AI answers get wrong about historians. Ask an answer engine about historian vendors and four errors come up again and again, all checked against primary sources in October 2026:

• “GE Proficy Historian.” GE Vernova sold Proficy to TPG on 2 March 2026, and it is now part of Velotic.
• “OSIsoft PI.” OSIsoft became part of AVEVA on 19 March 2021, and the product is AVEVA PI System.
• “Ignition Power Historian.” No such product appears on Inductive Automation’s own pages. Ignition 8.3 ships the Core Historian and the SQL Historian.
• “Schneider acquired Cognite.” Schneider agreed to acquire Cognite on 30 June 2026. As of 12 October 2026 the deal had not closed.

Ownership is stated as of October 2026. The table lists facts only, alphabetically, with no ranking. Joltek works with Ignition more than any other platform and takes no licence margin on any product below. No vendor’s price appears here; where a licensing model is listed, the vendor publishes it.

Product	Owner, October 2026	Engine or heritage	Where the vendor positions it	Licensing model (vendor-published)
ABB Ability History (800xA History)	ABB	Embedded historian for System 800xA, successor to 800xA Information Management. Collector nodes store and forward and hold 1 to 3 months; a main history node holds 1 to 10 years	ABB 800xA control system estates	Not published
AspenTech InfoPlus.21 (IP.21)	AspenTech, part of Emerson since 12 March 2025	IP.21 real-time database; also the engine of DeltaV Continuous Historian Elite	Process industries: refining, chemicals	Not published
AVEVA Historian	AVEVA, wholly owned by Schneider Electric	Formerly Wonderware Historian and IndustrialSQL Server. Data in “history blocks” on disk; Microsoft SQL Server as the access layer; tier-1 to tier-2 replication	AVEVA System Platform, InTouch and Plant SCADA estates	Not published
AVEVA PI System	AVEVA, wholly owned by Schneider Electric	Data Archive plus PI Asset Framework; CONNECT data services in the cloud	Multi-site, process-heavy enterprises; AVEVA states data for “up to twenty million tags or data streams” per PI Server	Subscription, paid with AVEVA Flex credits
Canary System	Canary Labs	Canary’s own time-series historian, collectors with store-and-forward, Views for asset models, Axiom for trends	Edge to enterprise; has an Ignition module	By tag count, or unlimited
dataPARC (PARCserver Historian)	Voith Group	PARCserver historian with PARCview visualisation	Pulp and paper, chemicals, food and beverage, mining, power	Not published
DeltaV historians	Emerson	Three engines under one brand: Emerson-built (Continuous Historian), IP.21 (Continuous Historian Elite) and PI Server (Advanced Continuous Historian and the integrated and embedded enterprise historians)	Emerson DeltaV control system estates	Not published
Factry Historian	Factry	Not named on Factry’s site; InfluxData’s partner page says it stores data in InfluxDB	Food and beverage, specialty chemicals, energy	One flat fee per production site, no tag charges
FactoryTalk Historian SE	Rockwell Automation	AVEVA PI Data Archive, per Rockwell’s own security advisories	Rockwell Logix and FactoryTalk plants	Not published
Ignition Core and SQL Historian	Inductive Automation	Core Historian on QuestDB; SQL Historian on any JDBC relational database	Plants running Ignition for SCADA, HMI or MES	Per server; historian modules sold as a suite with list prices on IA’s site
Kepware Local Historian	Velotic, owned by TPG	A plug-in to the Kepware server that stores history in a local datastore at the connectivity layer and serves it over OPC HDA	Local history next to the data source	Not published
Proficy Historian	Velotic, owned by TPG (sale from GE Vernova closed 2 March 2026)	Data archiver with compression; collectors with store-and-forward; a SaaS edition, Proficy Historian Hyperscale	From single machines to multi-site enterprises; discrete, process and hybrid	Not published
SIMATIC Process Historian	Siemens	Long-term archive built on Microsoft SQL Server, installed with Information Server	Siemens WinCC, PCS 7 and PCS neo estates; purchased separately	Not published
Timebase Historian	Flow Software	Timebase’s own historian; every collector has store-and-forward; OPC UA, MQTT Sparkplug B	From a single line upward; has an Ignition module	Free, per the vendor: “will remain free indefinitely”
Uniformance PHD	Honeywell	Distributed process history database with collection fail-over and automatic history recovery	Honeywell process estates, from a single unit to multi-site	Not published
Yokogawa Exaquantum	Yokogawa	Plant information management system on Windows; OPC and OPC UA; release R3.60 (May 2025) added AWS and Azure IaaS support	Yokogawa CENTUM estates; oil, chemicals, power, food, pharma	Not published

The engine matters more than the logo

Buyers compare brands. The engine underneath often decides more. FactoryTalk Historian SE runs on the AVEVA PI Data Archive: Rockwell’s own security advisories for it, SD1669 in May 2024 and SD1773 in June 2026, cite AVEVA PI vulnerabilities (Rockwell SD1773). Emerson sells PI-based and IP.21-based historians under the DeltaV name, alongside its own (Emerson DeltaV historians). Ignition’s Core Historian runs on QuestDB, and the Enterprise Historian Module Inductive Automation previewed in September 2026 runs on TimescaleDB.

Why it matters to a manager:

• Security advisories follow the engine. A PI vulnerability is a FactoryTalk Historian vulnerability.
• The people who can tune and recover it are the people who know the engine, whatever the badge says.
• Migration is easier between brands that share an engine, and harder than it looks between brands that do not.

Short notes, by owner

Schneider Electric (AVEVA). Schneider owns two separate historians through AVEVA. PI System came with OSIsoft, whose acquisition by AVEVA completed on 19 March 2021; Schneider has wholly owned AVEVA since 18 January 2023. PI Server is the Data Archive plus Asset Framework, now sold within AVEVA PI Data Infrastructure and paid for with AVEVA Flex credits (AVEVA PI Server). CONNECT data services, formerly AVEVA Data Hub, is the cloud layer, and a PI to CONNECT agent ships with PI Server. AVEVA Historian is the former Wonderware Historian, aligned to System Platform and InTouch. On 30 June 2026 Schneider agreed to acquire Cognite for $3,100,000,000, to be integrated with AVEVA once it completes; as of 12 October 2026 the deal was still awaiting regulatory approval (Schneider Electric).

Rockwell Automation. FactoryTalk Historian comes in a Site Edition, currently version 12, and a Machine Edition. SE is built on PI. Rockwell’s FactoryTalk DataMosaix is a separate product built on Cognite Data Fusion, and it is not a historian. For when the Rockwell option fits, see when FactoryTalk Historian is the right answer.

Emerson. Emerson has owned AspenTech outright since 12 March 2025, which brings InfoPlus.21, a long-standing process-industry historian. Its DeltaV control system offers three historian engines under one brand; Emerson’s own page still describes the PI-based ones as using “OSIsoft PI Server technology”.

TPG (Velotic). TPG closed its purchase of GE Vernova’s Proficy business on 2 March 2026 for $600,000,000, and its purchase of PTC’s Kepware and ThingWorx businesses in March 2026. TPG says those closings coincided with the launch of Velotic, which combines the three: “a new independent industrial software company formed from the combination of Proficy from GE Vernova and ThingWorx and Kepware from PTC” (Velotic; TPG). The product names stay: Proficy Historian is still Proficy Historian, and its cloud edition is now Proficy Historian Hyperscale. Only the MES was renamed, to Velotic. Kepware’s Local Historian plug-in keeps history at the connectivity layer and serves it over OPC HDA. One owner now sells both an OPC connectivity server many plants already run and a full historian, which is worth knowing when either one comes up for renewal.

Control system vendors. Honeywell (Uniformance PHD), Yokogawa (Exaquantum), ABB (Ability History, which replaces 800xA Information Management) and Siemens (SIMATIC Process Historian, above WinCC Unified’s own logging to SQLite or SQL Server) each sell a historian aligned to their own control system. The fit is strongest where that vendor’s DCS or SCADA already runs the plant, and each also collects from other systems over OPC. Honeywell’s remaining company has operated as Honeywell Technologies since the Aerospace spin-off on 29 June 2026.

Independents. Inductive Automation’s Ignition carries its historian inside the SCADA platform (see the next section). Canary Labs, founded in 1985, sells a dedicated historian licensed by tag count or unlimited, with an Ignition module (Canary licensing). dataPARC, founded as Capstone Technology in 1997, has belonged to the Voith Group since 2019. Timebase, from Flow Software in Austin, says its historian “will remain free indefinitely”. Factry, in Belgium, charges one flat fee per production site. Other SCADA vendors ship historians too, among them Mitsubishi Electric Iconics Digital Solutions (Hyper Historian) and COPA-DATA (zenon Historian 360).

Time-series databases used as historians

Four open-source engines appear in historian conversations. They are storage engines, not historians on their own:

• InfluxDB 3. Core and Enterprise generally available on 15 April 2025; Core is MIT or Apache 2 licensed.
• TimescaleDB. A PostgreSQL extension. Its company renamed itself Tiger Data on 17 June 2025 and offers an Apache 2 edition and a community edition under the Tiger Data License.
• QuestDB. Apache 2 licensed; the engine inside Ignition 8.3’s Core Historian.
• TDengine. AGPL licensed, and the one vendor in this group that markets itself directly as a historian replacement.

Adjacent tools that are not historians

These come up in the same meetings and solve different problems:

• Seeq and TrendMiner analyse data that historians already hold. TrendMiner has been owned by Proemion since 2024.
• HighByte Intelligence Hub and Litmus Edge model, condition and route data. Each buffers when a target is down, which is not the same as keeping history.
• Cognite Data Fusion builds a contextualised knowledge graph over industrial data in the cloud.
• AWS IoT SiteWise and Microsoft Fabric Real-Time Intelligence are cloud services that store and model industrial time series.

AVEVA PI System vs Ignition: how the two approaches differ

AVEVA PI System is a dedicated historian and data infrastructure, bought separately from the control system and built to collect from many sources across many sites. Ignition is a SCADA platform with historian modules inside it, licensed per server. Both collect, buffer, compress and serve history. They differ in where the historian sits and what the plant runs around it.

Disclosure. Joltek works with Ignition more than any other platform, and we take no licence margin on either product. This section describes how the two differ. It does not pick one, because the right answer depends on the plant.

	AVEVA PI System	Ignition (8.3)
What it is	A dedicated historian with an asset framework: PI Server is the Data Archive plus PI Asset Framework, with PI Vision for displays	A SCADA, HMI and MES platform whose historian is a set of modules on the same gateway
Owner	AVEVA, a wholly owned Schneider Electric company	Inductive Automation
Storage	The PI Data Archive	Core Historian (built on QuestDB), SQL Historian (your relational database), or a third-party historian through a module
Filtering and compression	Exception at the interface, then swinging door compression at the archive	Per-tag sample mode and deadband; the analog deadband style uses slope-based compression
Buffering	The PI Buffer Subsystem on the collecting node	Store-and-forward for SQL and legacy providers; the Core Historian writes directly to disk through a write-ahead log; Edge holds up to 35 days locally
Context	PI Asset Framework: elements, templates, event frames	Tag folders and UDTs (user-defined types), usually named to a UNS or ISA-95 hierarchy
Scale, as each vendor states it	AVEVA: data for “up to twenty million tags or data streams” per PI Server	IA: one server licence covers an “unlimited number of clients, tags, connections, and designers”. This is a licensing statement, not a historian capacity figure
Licensing model	Subscription: AVEVA sells PI Server within AVEVA PI Data Infrastructure, paid for with AVEVA Flex credits. No public prices	Per server. The historian modules are sold as IA’s Industrial Historian Suite, with list prices on IA’s site
Where it is usually found	Process industries and enterprise standards; also inside other brands (FactoryTalk Historian, DeltaV)	Plants that want SCADA and history on one platform, from a single line to multi-site

Separate system or one platform. PI is a historian that many systems write to. Ignition’s historian lives on the same gateway as the screens. That changes who owns it, how it is upgraded and what an outage takes down with it. Neither is wrong; they are different operating models, and a plant should pick the one its people can run.

One engine or a choice of engines. PI has one archive. Ignition 8.3 offers several storage options behind one tag history interface. That is flexible, and it also means the plant has to choose deliberately, which is where the default-database problem from earlier in this guide begins.

Context. PI Asset Framework is a mature, separate modelling layer with templates and event frames. In Ignition, context usually comes from the tag structure itself, through folders and UDTs named to the plant’s hierarchy.

The question that decides it is not which is better. It is which jobs the plant needs done, at what scale, and who will own the system for the next ten years.

Historian options inside Ignition

Ignition 8.3, released on 16 September 2025, gives a plant several places to keep tag history. The Core Historian is built in and runs on QuestDB. The SQL Historian writes to a relational database the plant already runs. Edge gateways keep a short local history and sync it upstream, and third-party historians plug in as modules.

• Core Historian. Part of the Historian Core Module. In IA’s words: “Backed by QuestDB, this no-maintenance historian offers native data aggregation and stores and queries data up to 10 times faster than Ignition’s previous internal tag history provider” (Ignition historian modules). It supports partitioning, deduplication, archiving and native aggregation, with retention modes of none, prune or archive. It writes directly to disk through a write-ahead log and does not use store-and-forward.
• SQL Historian. Writes to Microsoft SQL Server, Oracle, MySQL, MariaDB, PostgreSQL or any database with a JDBC driver, adding compression, partitioning, interpolation and aggregation. It routes data through Ignition’s store-and-forward system: a memory buffer, then a local disk cache, then the database, with failed writes held locally and quarantined after repeated errors (IA store-and-forward docs).
• Internal Historian (Legacy). The SQLite-based provider from earlier versions, still shipped in 8.3. Edge gateways use it.
• Ignition Edge. IA states that “up to 35 days or 10 million data points of history can be stored locally”, pruned automatically (Ignition Edge docs). Sync Services forward tag history, alarm journal and audit records to a central gateway over the Gateway Network or MQTT.
• Remote Historian and Historian Splitter. The first reads from or writes to another gateway’s history provider over the Gateway Network. The second writes the same tag history to two providers at once, which is useful during a migration.
• Third-party historians. The Historian API, new in 8.3, lets module developers implement their own historians. Canary’s module logs Ignition data into Canary and buffers with store-and-forward; Canary states that it requires a licensed Ignition Tag Historian Module. Timebase’s module, for Ignition 8.3.3 or later, makes Timebase a tag history provider. An OPC HDA provider can read from an existing HDA historian, read only, on Windows.
• How history is configured. Per tag: sample mode (on change, periodic or tag group), deadband style (analog or discrete), and minimum and maximum time between samples. Queries offer aggregates including the time-weighted and simple averages discussed in the retrieval section above.
• What is coming. At its ICC conference in September 2026, Inductive Automation previewed TimescaleDB for Ignition and a new Enterprise Historian Module, built with Tiger Data, for high availability at industrial scale, as part of Ignition 2027. No availability date was given. IA is also moving to an annual release model, beginning with Ignition 2027 in February (IA, ICC 2026).

This is the context for the two-in-ten observation earlier. Because history is a checkbox on a tag, Ignition makes it easy to start logging and easy never to design the historian. The options above are exactly why the design decision is worth making on purpose: which provider, which retention, which deadbands, who owns it.

How to choose a data historian, and does your plant need one?

You need a historian when you must answer questions across time, lines or outages that your SCADA’s logging cannot answer reliably. Choose on the seven jobs, not the storage engine: connectivity to your controllers, store-and-forward, compression you can explain, quality, retrieval modes, an asset model, and tools your people will open.

Start with the situation, not the product:

Situation	What you have today	The signal it is not enough	Next step
One line, a few hundred tags, weeks of memory	SCADA logging to a database	Rarely; watch for gaps and slow trends	Name an owner for the database; set retention
Several lines, recurring “what happened at 2 a.m.”	SCADA logging, maybe per line	Gaps after outages; nobody trusts the averages	Assess a site historian with store-and-forward
Quality investigations need years of data	Archived exports or backups	Answers take days, not minutes	Site historian with quality codes and a retention policy
Multi-site, corporate wants one number	A different historian or database per plant	Each plant’s numbers mean something different	Common naming and asset model first, then the enterprise tier
Unreliable link to a line, skid or remote asset	Values lost during outages	Holes that match network events	Edge buffering with store-and-forward

Once the situation says a historian is worth it, put the same ten questions to every vendor. The answers are comparable, and the gaps are obvious.

Questions to ask any historian vendor:

1. Which drivers do you ship for our controllers, and which need a third party?
2. Where does the store-and-forward buffer live, how big is it, and what happens when it fills?
3. What exception and compression methods do you use, and who sets them per tag?
4. How are quality codes stored and shown in aggregates?
5. Which retrieval modes are available, and how is an average calculated?
6. How does the asset model work, and can it use our ISA-95 naming?
7. Which client tools are included, and how are they licensed?
8. What is the licensing model: per tag, unlimited, per server or subscription?
9. How do we get all of our data out, in what format, if we leave?
10. Who patches it, who supports it, and who in our plant owns it?

Question 9 is the one most often skipped and most often regretted. A historian holds years of the plant’s record, and the format it holds it in decides what the next decision costs. If you want an outside view before you commit, that is the work we do in an independent data architecture review.

Frequently asked questions

What is a data historian in simple terms?

A data historian is software that collects time-stamped values from plant control systems, keeps them through network outages, stores years of them efficiently, and serves them back as trends, reports and analysis. Each value is stored with its tag, its timestamp and a quality flag. Storage is the smallest part of the job; collection, buffering, compression, quality and retrieval are what make it a historian.

Is a data historian just a time-series database?

No. A time-series database is a storage engine that writes and queries time-stamped data quickly. A historian is a product built around storage like that, adding plant connectivity, store-and-forward buffering, exception and compression rules, quality codes, retrieval modes, an asset model and tools operators open. Some historians now run on a time-series database inside: Ignition 8.3’s Core Historian is built on QuestDB.

Can an MQTT broker or unified namespace replace a historian?

No. An MQTT broker keeps at most one retained message per topic, so it holds the current state of the plant, not its history. A unified namespace is an architecture for sharing that current state. The historian subscribes to the namespace and records what passes through it, with quality and context, so the plant can ask what happened last March. The two work together.

Do I need a historian if my SCADA already logs to a SQL database?

Not always. A SQL database is a reasonable home for a few lines, a modest tag count and short retention, especially when the SCADA provides a historian layer on top of it. It starts to hurt at larger sites and longer horizons: queries slow down, gaps appear after outages, and every report depends on storage and retrieval logic that someone wrote and has to maintain.

Does historian compression lose data?

Compression drops points by design, but it is built to keep the shape of the signal. Swinging door compression stores a new point only when the trend leaves a corridor around the last stored slope, so a long straight line costs two points and a spike is kept. Set too loosely, it removes real behaviour, so settings should be chosen per signal and checked against real data.

Is Ignition a real historian?

Yes, in the sense that matters: Ignition’s historian modules collect, buffer, compress and serve tag history. Since version 8.3, released in September 2025, the Core Historian stores data in QuestDB, and the SQL Historian stores it in a standard relational database with compression, partitioning, interpolation and aggregation. Whether it is enough for a given plant depends on scale, retention and tools, the same test as any historian.

Find out what you actually have

A data historian is a set of jobs, not a place where data lands. Most plants do not have one. They have a SCADA writing to the database it shipped with, and that is a sound choice right up to the point where the plant asks questions across lines, years or outages. The mistake is not choosing a database. The mistake is never deciding at all.

Use this guide as the reference for that decision: the seven jobs to check against, the look-alikes and what each one guarantees, who owns which historian in 2026, and the questions to put to any vendor. If you want a second opinion on what your plant has today and what it would take to answer the questions you are being asked, book a conversation and bring your questions. We advise first, independent of any historian vendor, and when it makes sense we can also design and integrate what comes next.