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

Ignition
1

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 / Factry)

        ↓

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!

2

I have only used core historian on smaller systems so far. It performed fine on a small system. You probably want to closely monitor system resources if you're running it on a larger system and consider running it on Linux.

You could probably benchmark an infrastructure like what you have in mind using containers and get an idea on how it performs.

If you work for an integrator, you can schedule a meeting with an IA sales engineer through your account rep. That's a good path to go for getting a sound architectural design if you're plotting a large system.

3

Keep in mind that the core historian stores the data on the same server as the Ignition gateway running the core historian. I personally have never used it. We've standardized our systems on using PostgreSQL with TimescaleDB. Our clients typically just do trending in the HMI and pull some reports, so nothing fancy like what Canary can do, so it works for us and them. I believe someone on here made a paid-for module to connect to TimescaleDB so that when you run queries it will do all the aggregation on the server inside TimescaleDB instead of on the Ignition server which should increase performance even more.

I'm also secretly hoping that TigerData (makers of TimescaleDB) release their own module for Ignition at ICC (or that Inductive makes one and announces it at ICC) that does the same thing and just makes it part of their Industrial Historian Solution Suite.

5

Thanks for the information, I appreciate it.

That's good to know, and I'll definitely keep it in mind. I'll probably also take some time to discuss the different historian options with an Ignition engineer to get their perspective as well.

While I haven't personally worked with TigerData or TimescaleDB yet, it does sound like a very interesting approach, especially if the aggregation can be handled directly on the database side for better performance.

Thanks for sharing your experience!