How to Size & Scale GENESIS Version 11: A Practical Guide for SCADA & Digital Projects Using the Platform

Everything You Need to Know About GENESIS Nodes, Clients, and System Capacity 

Choosing the right SCADA automation and digitalization platform is only part of the equation when you’re modernizing operations in industrial manufacturing, buildings, or public infrastructure.   

Just as important is knowing how to size your SCADA deployment properly—how to define the right system architecture, computing resources, and hardware specifications to meet your needs without overbuilding or underpowering your environment.  

For instance, sizing a SCADA system means accounting for: 

• The number of real-time data points (tags) to be monitored 
• The number of clients or users who will view or interact with the system 
• The required scan rate (how fast data needs to be captured) 
• The volume of historical data to be stored and analyzed 
• The number of dashboards and reports to be run 

In this blog, I’ll define what a “node” is in GENESIS version 11 (sometimes simply referred to as GENESIS), explore how much a single node can handle, explain when it’s time to scale, and show how to match your hardware to your goals using GENESIS. 

What’s a Node? 

In GENESIS version 11, a node refers to a physical or virtual machine running a full GENESIS installation—this includes any core services such as I/O, visualization, historian, or alarms. Each GENESIS instance counts as a node, whether it’s part of a distributed system, serving a specific function, or configured for redundancy. 

Importantly, having multiple nodes does not automatically mean the architecture is multi-tiered. A system may be multi-node or multi-layer—where different GENESIS instances perform specific tasks or act as I/O subsystems—while still operating as a single control system. A multi-tier architecture, by contrast, involves multiple levels making distinct control decisions. 

Some examples of nodes are the following: 

• A primary GENESIS server and its redundant backup server = 2 nodes 
• Separating the GENESIS historian onto its own server = 2 nodes total 
• A system with 1 primary GENESIS server and 4 additional GENESIS servers = 5 nodes 

If each of those 5 nodes is performing separate control functions (e.g., at different layers of a facility), they form a multi-node, possibly multi-layer architecture—but not necessarily a multi-tier one unless another GENESIS instance sits above them coordinating those actions.  

Start Simple: Single-Tier Architecture for Small- to Mid-Sized Projects 

For non-critical or single-site projects, a single-tier architecture—with all SCADA components hosted on one server—is a practical, budget-friendly choice. It’s ideal when you need local visualization and monitoring without extensive redundancy or analytics. 

Typical Capabilities: 

• Data acquisition 
• Data historizing 

Visualization delivered to a limited number of clients (dashboards, mobile maintenance views, etc.) 
Calculations and alarm management 

System Design Limits: 

• < 100,000 real-time tags 
• Up to 25 Web/Mobile (AnyGlass) or 50 GraphWorX desktop clients 
• 1-second scan rates 
• Low latency, moderate uptime requirements 

Recommended Specs: 

• A single server 
• 4-core CPU 
• 16GB RAM (32–64GB for upper-end) 
• 512GB–1TB SSD 

Tip: Keep CPU usage under ~40% and RAM under ~60% to ensure performance headroom. The more functions GENESIS performs, the more CPU usage increases. 

When to Scale: Signs You Need Multi-Tier Architecture 

Before assuming you need a multi-tier setup, it’s important to understand what scaling looks like in GENESIS: 

• Multi-node or multi-layer setups may involve several GENESIS instances performing specific functions (e.g., I/O, historian, visualization) within the same control layer. 
• Multi-tier architecture is different—it involves distinct levels of control, where one or more GENESIS instances oversee and coordinate decisions made by lower-level nodes. 

In a true multi-tier system, control decisions are made at multiple levels. You might:

• Have 5 independent control systems (each with their own GENESIS stack), with an additional GENESIS node above them to aggregate, monitor, or coordinate—this top-level node represents a second tier. 
• Think of it as a pyramid: multiple GENESIS nodes at the base performing local operations, and fewer supervisory nodes higher up coordinating across layers. 

Scaling to multi-tier architecture enhances performance, enables larger deployments, and supports enterprise-wide coordination—especially valuable in complex, distributed environments. 

When You Need to Go Multi-Node 

If, for example, your system is approaching 100,000 tags, supporting 20 or more clients, or consistently experiencing high CPU and memory usage, it may be time to scale to multi-node. 

Multi-node architecture distributes workloads across multiple servers or virtual machines, enhancing performance, reliability, and scalability. In many cases, these nodes are organized into a multi-tier architecture, where each tier handles specific functions. Typical node roles include:  

• I/O Server – Device communication and namespace handling 
• Visualization Server – Hosts dashboards and mobile views 
• Historian & Alarm Server – Logs time-series data, evaluates alarms 
• SQL Server (Standard) – Reporting and analytics 
• Optional – Business intelligence (BI) connectors, test environments, cloud interfaces 

Understanding how these architectural concepts differ—and when to apply each—is the foundation for building a high-performing, scalable SCADA system.

Redundancy: Why It Matters 

In mission-critical environments, high availability is essential. However, single-node systems and high availability are mutually exclusive, so to maintain uptime, we suggest that you:  

• Use a secondary GENESIS node for redundancy (both the primary server and redundant server are nodes) 
• Split historian from the rest of the system (which would warrant two additional nodes in a redundant setup) 
• Make more nodes independent if needed, depending on the load or level of resilience you desire 

Redundancy isn’t just about backup—it’s about designing a system that can adapt and recover instantly when it matters most.

Horizontal Scaling vs. Distribution 

While horizontal scaling and distribution are related concepts, they serve different purposes in SCADA system architecture. Here's how they compare: 

• Multi-tiering refers to deploying visualization and control capabilities across hierarchical levels of an operation—from machine-level HMIs to line-level dashboards, plant-wide systems, and enterprise-level overviews. Each tier provides context-appropriate data and, in some cases, localized control. 
• Distributed systems describe architectures where system components are separated across physical or geographic locations to improve reliability, performance, or access. 
• Horizontal scaling involves increasing the number of GENESIS nodes to handle greater system load, whether due to more data, users, or functionality. 

Although multi-tiering, distribution, and horizontal scaling can coexist in a system, each represents a distinct architectural concept—tiering defines functional structure, distribution defines physical layout, and scaling defines system capacity.

Performance Isn’t Just About Size 

Beyond tag counts and client load, several other factors affect performance such as: 

• Scan Rate – Sub-second polling increases load 
• Calculated Tags – More formulas = more CPU usage 
• Concurrent Clients – Dashboards, mobile sessions 
• Historian Settings – Tight deadbands, frequent archiving 
• Scripting – Predefined or ad-hoc actions based off your projects needs 
• Third-party integrations – BI tools, CMMS (Computerized Maintenance Management System), cloud 

Tip: Use the included Data Historian to improve your system's performance and if you have to use SQL Server for data historization, use SQL Server Standard Edition (as opposed to Express Edition) to avoid database size and performance limits. 

Smarter Licensing, Better Scaling with GENESIS 

With GENESIS version 11, scaling across nodes affects how your licenses are used. We can help you align your system architecture with licensing requirements to ensure optimal value and flexibility—before you even choose the right GENESIS edition for your project. And we’ve made it easy to get started. 

GENESIS is built to scale—from small facilities to enterprise-wide deployments. Whether you’re building new or upgrading, we’ll help you size it right. 

What we offer: 

• Personalized guidance based on your tag counts and scan rates 
• Real-world performance benchmarks to inform decisions 
• Help selecting the right architecture—single-tier or multi-tier 

Get the scalability you need by working with a team that has the expertise and experience to understand your technical requirements and guide your licensing decisions with confidence.

Your Next Steps 

Explore the full capabilities of GENESIS version 11 on our product page.
Need sizing help? Contact us to talk with one of our experts