What the Core Historian changes

Ignition 8.3 introduced a new built-in historian, and it is a genuinely different thing from a SQL historian rather than a faster version of one. Several of the changes only surface when you go looking for them.

It is an option, not a default

Worth establishing first, because the rest depends on it. The Core Historian is not what a gateway uses unless you set it up: Inductive Automation describes it as an additional historical provider option, and most provider types must be created manually. You add one under Services, Historians, Create Historian.

The one edition that ships a historian automatically is Edge, and there it is an instance of the Internal Historian (Legacy) rather than the Core Historian — which matters for everything below, because the legacy provider behaves like the SQL ones rather than like this.

Where the data goes

A SQL historian writes to a database you configured, through a connection you set up. The Core Historian is an embedded time-series database that writes directly to the gateway’s own disk using a write-ahead log, under data/var/com.inductiveautomation.historian/.

That difference propagates further than it looks. There is no separate database server to size, no database credentials to manage, and no database administrator who already knows how to look after it — which is the appeal, and also the cost.

External access is possible but deliberately narrow. Inductive Automation packages a PG Wire server allowing direct read-only access to the data, on port 8812 by default, bound to localhost and opt-in via a gateway configuration parameter. So an outside system can read it over an ordinary Postgres connection, once somebody has decided to allow that. It is not the same proposition as a SQL historian sitting in a database another system already queries.

The habit that stops applying

This is the one worth internalising, because it invalidates a piece of standard Ignition knowledge — and because Inductive Automation words it two different ways.

The provider documentation is flat. In IA’s words, the Core Historian “writes directly to disk using a high-performance write-ahead log (WAL) system. It does not use Store and Forward, so it bypasses the buffering and retry mechanisms used by other historian types.” Inductive Automation’s historian overview adds that the Internal Historian (Legacy) and external SQL providers always route historical data through store and forward.

The 8.1-to-8.3 upgrade guide is narrower: “Additionally, the Core Historian will only use the Store and Forward system if there are pending writes to the database. If there are no pending writes, the Core Historian will skip the Store and Forward system entirely.”

Both are IA. The practical reading is that store and forward is not the mechanism protecting Core Historian data, and you should not design as though a buffer sits in front of it — while not asserting that the system never touches store and forward in any state. Either way, “tag history is buffered by store and forward during a database outage” was true through 8.1 and does not describe this provider. We wrote about what that buffer does and does not cover in what happens when the database goes away; the Core Historian is the case that sits outside it, because there is no external database in this path.

Maintenance is partition-based, and the default is prune

Retention works differently. The Core Historian partitions data on an interval you choose — week, month or year — and maintenance operates on whole partitions rather than rows.

Three modes. None keeps history indefinitely in place. Prune removes data by deleting partitions past a configured age threshold, and is the default. Archive removes partitions from the live store and retains them in a new target location.

Two consequences. The maintenance age has to be a whole-number multiple of the partition interval, so the two are chosen together. And because the default is prune rather than none, the provider is configured to delete partitions once they pass the maintenance age rather than to keep everything — Inductive Automation does not document a default age, so that is a number to go and check rather than assume.

One related setting worth knowing: IA notes that out-of-order writes, such as with the analog deadband style, can be taxing for the Core Historian, and recommends the discrete deadband style or turning deadband off, together with the periodic sample mode.

Metadata is opt-in

Metadata must be explicitly enabled in the Tag Editor by setting Include Metadata to true, and IA says it is required for features like annotations, aggregates and historian scripting functions.

Whether enabling it later covers history already recorded is not documented either way, and there is a scripting function, system.historian.storeMetadata, that applies to the Core Historian and Internal Historian. The safe reading is to decide this at configuration time rather than to rely on repairing it afterwards.

Protecting it is a different job

With a SQL historian, protecting history is the database’s problem and somebody probably already has a process. With the Core Historian the data is on the gateway, and a gateway backup does not carry it — IA documents the module data directory as not added to a .gwbk.

There is a documented mechanism worth knowing here: the Historian Splitter writes tag history to two configured providers simultaneously, which IA lists as useful for redundancy, system migrations and archiving in multiple locations. That listing makes it the obvious way to move off a SQL historian without switching cold. One caveat if you use it for protection: queries execute against the first connection unless it is unavailable, so a silently failing second provider will not show up through normal querying.

Either way the plan has to be explicit rather than inherited, which is one of the questions we put in a recovery drill for an Ignition gateway.

Which provider, and what it costs

Licensing changed with the historian. The Tag Historian license item has been replaced by Historian Core and SQL Historian license items, so “which historian” is now partly a licensing question rather than purely an architectural one. Concretely, IA states the SQL Historian module is required in addition to the Historian Core module for that provider to be listed on the gateway. Multiple providers can coexist, and tags select a storage provider individually.

Two documented performance differences cut in opposite directions. Pre-processed partitions, which significantly improve qualifying queries, are not supported by the Core Historian — though IA documents that they are only used by the deprecated legacy query functions, so that advantage narrows on new development. Native aggregation directly in the database engine is a Core Historian strength.

The short version: the Core Historian suits a site whose history is consumed inside Ignition, and a SQL historian remains the better answer when something outside Ignition already queries that database, when an existing database administration process should cover it, or when you want the buffering store and forward provides in front of a remote database.

Which provider is this gateway using — and does everyone who supports it know?
If it is the Core Historian, what protects that data, and has that been tested?
What is the partition interval, the maintenance mode and the maintenance age?
Is Include Metadata set on the tags where you will later want aggregates or annotations?
Does anything outside Ignition need to read this history, and does the read-only localhost interface actually satisfy it?

Common questions

Does the Core Historian use store and forward?

Inductive Automation documents this two ways. The provider documentation says it writes directly to disk using a write-ahead log and does not use store and forward, bypassing the buffering and retry mechanisms other historian types use. The 8.1 to 8.3 upgrade guide says more narrowly that it uses store and forward only if there are pending writes to the database, and skips it entirely otherwise. The practical reading is that store and forward is not the mechanism protecting this data.

Is the Core Historian the default historian in Ignition 8.3?

No. It is described as an additional historical provider option, and most provider types must be created manually under Services, Historians. The one edition that ships a historian automatically is Edge, where it is an instance of the Internal Historian (Legacy).

Where does the Core Historian store data?

On the gateway itself, in an embedded time-series database under the Ignition installation data directory at data/var/com.inductiveautomation.historian, rather than in a separate database server.

How does retention work on the Core Historian?

Data is partitioned on an interval of week, month or year, and maintenance acts on whole partitions. There are three modes: None keeps history indefinitely, Prune deletes partitions past an age threshold and is the default, and Archive removes partitions and retains them in a new target location. The maintenance age must be a whole number multiple of the partition interval.

Can something outside Ignition read Core Historian data?

Yes, within limits. Inductive Automation packages a PG Wire server allowing direct read-only access on port 8812 by default, bound to localhost and enabled by an opt-in gateway parameter. That is narrower than a SQL historian sitting in a database another system already queries.

Is a gateway backup enough to protect Core Historian data?

No. The module data directory that holds it is documented as not added to a gateway backup, so protecting it needs its own arrangement. The Historian Splitter, which writes history to two providers simultaneously, is one documented option.