Core Historian vs Canary/Factry for large multi-site systems? Looking for architecture recommendations

Hi everyone,

We're currently designing a new Ignition 8.3 system for a fairly large industrial customer, and I'm trying to determine the best long-term historian architecture.

The project will initially have around 5,000 historized tags, with a roadmap to 10,000+ tags over the next few years. There will be multiple PLCs, multiple departments, and eventually multiple sites.

Historically, I've always used the SQL Historian (SQL Server), but with Ignition 8.3 I'm looking closely at the new Core Historian (QuestDB).

From what I understand, Core Historian is a true time-series historian rather than just writing to partitioned SQL tables like previous versions. It seems much closer architecturally to products like Canary, OSI PI, or FactoryTalk Historian.

I'm curious about real-world experience from people running larger systems.

A few questions:

  • Have you chosen Core Historian over Canary or Factry? If so, why?
  • At what scale (tag count or write rate) would you recommend moving to a dedicated historian like Canary or Factry instead of Core Historian?
  • For those using Canary or FactoryTalk Historian with Ignition, what were the main benefits that justified the additional licensing and infrastructure?
  • In larger plants, do you typically dedicate a separate Ignition Gateway to historian services, or do you keep the historian on the main backend Gateway?
  • For example, is an architecture like this common?

Perspective Front-End Gateway(s)

        ↓

Backend Gateway
(OPC, Tags, Alarming, Scripts)

        ↓

Dedicated Historian Gateway
(Core Historian / Canary / PI)

        ↓

Database / Historian Storage

Or do most people simply run everything on the backend Gateway?

I'd really appreciate hearing how people have architected systems in the 5k–50k+ historized tag range, especially for multi-site deployments.

Thanks!