// Notes

Tag history that stays fast when retention gets long.

2026-09-22 · 6 min read · Ignition

The Ignition 8.3 historian is fine out of the box. At scale the same ceiling shows up: long-range aggregates that take tens of seconds, tag renames that mean touching SQL, and metadata that lives outside the historian. Teams either live with it or bolt on a warehouse and lose the native tag-history bindings.

TimescaleDB Historian keeps those bindings and pushes the hard work into TimescaleDB hypertables. Same tag groups, scripts and views. Aggregates that stay in tens of milliseconds when the row count does not.

Aggregate query · 1000 points over ~158M rows

One week25 ms

One month38 ms

One year56 ms

SQL historians, same range35 s +

Core historian, same rangedoes not complete

Flat from a week to a full year, because aggregation runs inside TimescaleDB rather than in the gateway.

TimescaleDB historian provider settings in the Ignition gateway — **Historian settings** TimescaleDB · Gateway

What stays the same

Same provider UI. Configured like any other historian. Tag history bindings and scripts keep working.
Rename without SQL. Rename history tags from inside Ignition. No cleanup scripts against the tables.
Annotations and metadata. Context travels with the values instead of living in a side spreadsheet.

When to reach for it

Not a general analytics warehouse. Not a MES. Tag history that stays fast when retention and tag count stop being polite. €3,000 per gateway, perpetual. Built for sites where the default historian starts to struggle.

Trial it against your own data, then request a licence from the product page.

TimescaleDB module on Mustry

← all notes