Scalability

What is scalability?

Scalability is the ability of a system, network or application to absorb increasing load, such as more users, data volumes, network traffic, sites or production capacity, without significant degradation of performance, stability or manageability. Within OT, industrial automation and OT convergence, scalability is a crucial design principle. Industrial environments often grow from isolated production lines into connected ecosystems with thousands of assets, real-time data flows, cloud integrations and analytics. Scalability matters at every layer: from PLC systems and networks to SCADA platforms, historians, IIoT platforms, databases, edge computing, monitoring and cybersecurity architectures.

🧠 Why does scalability matter in IT/OT?

Traditional OT systems were designed for a fixed installation that often remained largely unchanged for twenty years or more. With Industry 4.0 the number of connected systems is growing strongly, and an architecture that cannot cope leads to performance issues, network congestion, increased latency, management complexity and ultimately unreliable production processes.

Growth happens in almost every domain:

⚙️ What is the difference between vertical and horizontal scaling?

Vertical scaling (scale up) means adding capacity to the same system: more CPU, more memory, faster storage or a heavier server. Horizontal scaling (scale out) means adding more systems: additional servers, brokers, databases or load-balanced services.

Horizontal scaling has its limits too: according to Amdahl’s law (1967), the part of a task that cannot run in parallel, such as a central database lock, caps the gain from extra nodes. Even so, horizontal scalability is becoming increasingly important in modern OT platforms.

🏭 How do SCADA, historians and MES scale?

SCADA systems, historians and MES face the same growth factors: more tags, more clients, higher polling rates, growing historical storage and higher alarm volumes. The last of these is a safety risk: under ISA-18.2 and EEMUA 191, an alarm flood means more than 10 alarms per 10 minutes per operator. Good alarm management therefore has to grow with the number of assets.

Key architectural choices:

As a guide, Inductive Automation’s sizing guide puts Ignition at roughly 5,000 tags and 10 clients on 2 cores and 4 GB RAM, and 100,000 tags and 75 clients on 8 cores and 16 GB. Beyond that, the vendor recommends a scale-out architecture with separate I/O and front-end gateways, or a hub-and-spoke model in which edge gateways at each site buffer data and forward it to a central hub.

The licensing model often determines the cost of growth more than the technology does. WinCC Runtime is sold in PowerTag packages (for example 128, 2,048, 8,192 or 65,536), whereas Ignition is licensed per server with unlimited tags and clients. For storage, a time-series database such as InfluxDB is common, with Grafana as a scalable visualisation layer.

🔄 How do a Unified Namespace and publish-subscribe help scalability?

Classic SCADA requests data cyclically from each controller (polling). With hundreds of controllers and several consumers, the number of point-to-point connections grows with the number of sources times the number of consumers, because each consumer opens its own connections. In a Unified Namespace, sources publish their data once to a central broker, only when it changes (report by exception), and MES, SCADA, analytics and cloud subscribe to it.

Within the Industrial Internet of Things, several standards are relevant:

• MQTT - MQTT 3.1.1 has been ISO/IEC 20922 since 2016; MQTT 5.0 (OASIS, March 2019) added shared subscriptions to spread messages across multiple consumers
• Sparkplug - since October 2023 Sparkplug 3.0 has been the international standard ISO/IEC 20237, standardising topics, payloads and state management
• OPC UA PubSub - since version 1.04 (February 2018), OPC UA supports publish-subscribe alongside client/server, including over MQTT and AMQP
• Apache Kafka - often used as a scalable streaming layer between OT brokers and IT platforms

Scalability factors for a broker are the number of topics, the number of clients, message throughput and the chosen MQTT QoS levels (0, 1 or 2). The open-source Mosquitto broker runs on a single node without clustering and suits a site or the edge; large numbers of connections require clustered brokers. In 2022 EMQX demonstrated 100 million concurrent MQTT connections on a 23-node cluster. Event-driven OT architectures need careful topic design and redundant brokers to avoid bottlenecks.

🌐 What limits scalability in OT networks and protocols?

OT networks keep growing through digitalisation and connectivity. Key considerations are bandwidth, latency, jitter, broadcast and multicast traffic, and segmentation.

Not all protocols scale equally well:

Insufficient network capacity causes network congestion, packet loss, delayed control and unreliable HMIs. Where deterministic behaviour is required, growth in IT traffic must never come at the expense of control traffic.

☁️ What role do edge computing and the cloud play?

Edge Computing processes data locally, reducing the load on central databases, WAN connections, cloud platforms and historians. Benefits include lower latency, less cloud traffic and better availability: an edge gateway with store-and-forward buffers data when the connection drops. Common edge components are Node-RED, local MQTT brokers, local analytics and edge historians, often running as containers in Docker or Kubernetes.

Cloud platforms offer elasticity, dynamic resources and automated scaling. In OT these are balanced against latency, compliance, cybersecurity, determinism and availability. That is why hybrid architectures emerge, in which real-time control stays local and analytics moves to the cloud.

📈 How do you manage data growth and databases?

Digitalisation drives strong growth in industrial data from IIoT sensors, historians, network monitoring, security logging and machine learning datasets. The challenges are storage capacity, retention policy, query performance, backup windows and replication load. Techniques to keep this manageable include downsampling, compression, edge filtering and data lifecycle management.

Key design choices are partitioning, replication, query optimisation, data compression and high availability.

🔐 How does cybersecurity scale with growth?

More OT assets, network segments, cloud connections, remote access and supplier integrations make cybersecurity more complex. Measures that are configured manually per device scale poorly.

Since 15 August 2026, the Cyberbeveiligingswet (Cbw), the Dutch implementation of NIS2, has applied in the Netherlands. A scalable security architecture makes it easier to keep meeting its duty of care and reporting obligations as your environment grows.

⚠️ What problems does poor scalability cause?

Typical causes are poor architecture, under-sizing, inefficient queries, excessive polling rates and excessive logging. Measure throughput, response time, latency, CPU and memory usage. Within critical infrastructure, scalability issues directly affect safety and continuity.

🔄 What is the difference between scalability and availability?

In OT both must go together: a clustered broker scales and stays available when a node fails.

🧭 How do you design a scalable IT/OT system?

1. Define growth scenarios - number of tags, clients, sites and data volume now and in ten years.
2. Check licensing models - per tag, per client or per server; calculate the cost of expansion up front.
3. Choose a modular architecture - segmentation, edge processing, event-driven communication and distributed components.
4. Decouple sources and consumers - through a Unified Namespace or streaming layer instead of point-to-point integrations.
5. Test performance - load tests at expected load, stress tests beyond the limit and soak tests over several days, preferably in a test environment.
6. Monitor and plan capacity - track trends in CPU, storage and message throughput and act before bottlenecks appear.

A Dutch water board centralising dozens of pumping stations could, for example, place an edge gateway with a buffer at each station and send the data via a broker to central SCADA and analytics. Scalable architectures like this support IIoT, predictive maintenance, cloud analytics and digital twins, and make scalability a permanent part of industrial architecture and lifecycle management.

❓ Frequently asked questions

What is the difference between scalability and elasticity?

Scalability is the ability of a system to absorb growth by adding capacity. Elasticity is the automatic scaling up and down of that capacity based on current demand, as in cloud platforms. An elastic system is therefore always scalable, but a scalable OT system is often not elastic.

How many tags can a SCADA server handle?

How many tags a SCADA server can handle depends on hardware, scan rates, historisation and the number of clients. Ignition gives a guideline of around 100,000 tags with 75 clients on a server with 8 cores and 16 GB of memory. Beyond that, I/O tasks and client load are spread across multiple servers.

Is MQTT more scalable than OPC UA?

MQTT scales well for large numbers of devices and consumers, because a broker distributes messages and sources publish only on change. OPC UA client/server is limited in sessions per server, but OPC UA PubSub can also run over MQTT. In practice the two are combined: OPC UA close to the machine and MQTT for scalable distribution.

Why does the licensing model limit scalability?

Many SCADA and historian packages charge per tag or per client, so every expansion brings new licence costs. As a result, extra measurement points are sometimes deliberately left unconnected, even when the technology could handle them. A scalability assessment should therefore always include the licensing model.

How do you test the scalability of an OT system?

You test the scalability of an OT system with load tests at expected load, stress tests beyond that load and soak tests over a longer period. Use simulated tags or messages in a test environment so that production is not disrupted. Measure throughput, response time, latency and resource usage.

Can the cloud solve OT scalability?

The cloud solves scalability of storage, analytics and reporting well through elastic capacity. Real-time control, however, stays local because of latency, determinism and dependence on the internet connection. A hybrid architecture combining edge and cloud is therefore the common solution.

📌 In summary

Scalability determines whether an IT/OT environment can grow in tags, clients, sites and data without performance, reliability or safety suffering. Combine horizontal scaling, publish-subscribe with a Unified Namespace, edge processing and a suitable licensing model, and validate your design up front with performance tests.