We are implementing a Facility SCADA system using zenon, and need guidance on the supported architecture for the historian database layer.
Project setup:
zenon deployed in redundant configuration across two industrial computers (primary + standby).
Historian data is being archived from zenon to a relational database backend (SQL evacuation)
We require the database backend to also be redundant, running on two separate physical machines, to match the availability of the rest of the SCADA system
Both DB servers will sit on the same LAN in the same facility
zenon is the only writer and the only reader of the historian database (no Power BI, MES, or other external consumers)
Requirements for the database layer:
Two database instances on two separate physical machines holding the same historian data
Zero data loss if one database server fails
Automatic or near-automatic failover — zenon should continue archiving without manual intervention
Operationally manageable by a SCADA-focused team
Our Investigation So Far
We have explored several approaches for keeping two database instances in sync, and we want COPA-DATA's guidance on which is correct for zenon.
Specifically:
1. SQL Server Always On Basic Availability Groups
Using SQL Server Standard Edition (Enterprise is outside our budget) with a Windows Server Failover Cluster, Basic Availability Group, synchronous commit, and an AG Listener that zenon would connect to as a single endpoint.
Our concern: The total infrastructure cost (SQL Server Standard licensing for both nodes, Windows Server licensing, the operational complexity of WSFC + AG Listener + quorum witness + domain or workgroup certificates) is substantial for a single-database historian with one writer.
2. Zenon Dual-Write to Two Independent SQL Servers
Configure zenon's historian SQL evacuation to write to two independent SQL Server instances, relying on zenon's own redundancy and buffering to maintain consistency.
Our questions about this approach:
Does zenon's historian SQL evacuation natively support writing to two independent SQL Server instances simultaneously?
If one SQL Server is unavailable, does zenon buffer the evacuation data locally and replay it when the server returns?
Are there known issues with consistency or duplicate writes when zenon's redundant pair both evacuate to two database targets?
What is COPA-DATA's recommended pattern for redundant historian SQL evacuation?
3. Alternative Database Backends (PostgreSQL + TimescaleDB)
We have considered open-source alternatives — specifically PostgreSQL with the TimescaleDB extension for time-series workloads, clustered with Patroni for automatic failover. PostgreSQL is architecturally well-suited to time-series historian data and avoids the licensing cost of SQL Server.
Our questions about this approach:
Does zenon's historian SQL evacuation officially support PostgreSQL as a backend, via the ODBC interface or any other mechanism?
If PostgreSQL is supported, do all evacuation features work — including transparent read-back into the Extended Trend Module, archive revision screens, and reports?
Are there COPA-DATA customers currently running zenon historian evacuation against PostgreSQL (or any non-SQL-Server backend) in production?
Are there limitations or caveats we should be aware of?
4. Other Patterns We May Have Missed
Is there a recommended pattern from COPA-DATA for redundant historian deployment that we haven't considered?
Does zenon's own internal archive (ARX) provide enough redundancy on its own, with SQL evacuation positioned as a non-critical downstream archive that doesn't itself need HA?
For installations of similar scale, what do COPA-DATA's customers typically run in production?
Environment Details
zenon version: 15
Network topology: Both DB servers on the same LAN as the zenon servers; air-gapped OT network
Expected tag count and write rate: ~ 120 000 vars every 30 seconds
We appreciate any guidance, references to documentation, or examples of similar deployments that COPA-DATA can share. Thank you.