MQTT vs. OPC UA: Making the Right Protocol Choice for Your IIoT Architecture

From my experience with industrial integration projects, the most heated architectural debates happen around a deceptively simple question. If you are an Enterprise Architect or IT/OT Manager tasked with designing the backbone of a new digital factory, you will inevitably hit the most debated crossroads in industrial automation: Should we build our infrastructure on MQTT or OPC UA?

For years, the industry has often pitted these two protocols against each other. Vendors typically defend their chosen silo. However, reducing this to a simple "A vs. B" binary comparison is a costly architectural mistake.

In this article, we focus on protocol behavior, constraints, and trade-offs. We analyze how MQTT and OPC UA operate, where each is appropriate, and why many modern platforms such as Proxus use both in a Unified Namespace strategy.

Results vary with workload, hardware, and topology.

OPC UA: The established standard of the Shop Floor

OPC Unified Architecture (OPC UA) was released in 2008 as the successor to the notorious Windows-COM-based OPC DA. It was designed by the OPC Foundation with a primary goal: to be the widely adopted, secure, vendor-agnostic standard for industrial data exchange.

How it Works (Client/Server Polling)

OPC UA operates primarily on a Client/Server architecture. An OPC UA Server sits on a piece of equipment (like a Siemens S7-1500 PLC). An OPC UA Client (like a SCADA system) connects to the server and constantly asks: "What is the temperature? What is the temperature? What is the temperature?"

Where OPC UA Excels

• Complex Information Modeling: OPC UA is not just a transport protocol; it is a comprehensive structural dictionary. It natively understands complex object types (e.g., "This isn't just a float; it's a Fanuc Robot Arm with 6 axes, and here are the strict relationships between them").
• Local Network Speed: On a stable, hardwired, Gigabit local area network (LAN), OPC UA provides deterministic and low-latency communication for machine-to-machine (M2M) synchronization.
• Deep Penetration: Most major automation vendors (Siemens, Rockwell, Beckhoff) support it natively in their advanced hardware.

The OPC UA Bottleneck (Why it fails at Cloud Scale)

OPC UA is a "heavy" protocol. Because it relies heavily on polling, it can be chatty. Pushing OPC UA traffic across a cellular network (LTE/5G) or a weak Wi-Fi connection to a cloud dashboard can create significant bandwidth saturation.

Furthermore, you typically should tightly configure point-to-point connections. If you have 50 PLCs and 5 client applications (ERP, MES, SCADA, AI), you are suddenly managing 250 distinct, brittle connections. This significantly reduces the agility required for a Unified Namespace.

MQTT: A Lightweight Pub/Sub Alternative

Message Queuing Telemetry Transport (MQTT) was invented in 1999 specifically to monitor oil pipelines over costly and low-bandwidth satellite connections.

How it Works (Publish/Subscribe)

MQTT replaces direct client/server polling with a Pub/Sub architecture centered around a broker. Instead of asking for data, edge devices (Publishers) simply push data to the Broker only when a value actually changes (Report-by-Exception). Consumers (Subscribers) tell the Broker, "Hey, let me know if the temperature changes on Machine 1."

Where MQTT Dominates

• Bandwidth Efficiency: Because it only reports exceptions, MQTT can significantly reduce industrial network traffic compared to continuous OPC UA polling in many scenarios. It thrives on intermittent Wi-Fi or cellular networks.
• High Scalability: Adding a new AI Analytics app? It simply subscribes to the Broker. The PLC doesn't even know the AI app exists. You can scale to large numbers of concurrent connections efficiently.
• State Awareness: With features like "Last Will and Testament" (LWT), if a machine loses power, the broker can notify subscribers that the data source is unavailable.

The Problem with "Naked" MQTT

MQTT is pure transport. It is a shipping envelope that does not care what is inside. You could publish a beautifully structured JSON string, or you could publish a garbled binary mess. This lack of standardization created chaos in early IIoT adoption, forcing engineers into painful data-mapping exercises.

The Great Equalizer: MQTT + Sparkplug B

To solve the "Wild West" payload problem of naked MQTT, the Eclipse Foundation introduced Sparkplug B.

Sparkplug B is a specification built on top of MQTT. It enforces a rigorous, standardized payload format using Protocol Buffers (ProtoBuf) and dictates strict rules for session state management (Birth and Death certificates).

With Sparkplug B, MQTT gains structural predictability similar to OPC UA, while maintaining the scalability and low overhead of Pub/Sub. This combination is a common backbone of modern Unified Namespace architecture.

So When Do You Use Which?

The reality is that you do not have to choose. A practical IT/OT architecture uses both protocols exactly where they belong.

Scenario A: Strict Machine-to-Machine Control (Typical Choice: OPC UA)

If a robotic welding arm needs to talk to a safety PLC in 5 milliseconds to prevent a physical collision on the local factory floor, use OPC UA (or PROFINET/EtherCAT). It is deterministic, heavy, and built for local closed-loop control.

Scenario B: Enterprise Data Collection & Cloud AI (Typical Choice: MQTT + Sparkplug B)

If you want to pull data from 300 machines across 4 different factories into a central data lake for OEE calculation and predictive maintenance, use MQTT with Sparkplug B. OPC UA can become inefficient under the network weight and connection complexity at this scale.

Bridging the Gap with Proxus

The hardest part of Industry 4.0 is getting your legacy OPC UA (and Modbus/Siemens S7) equipment to speak MQTT Sparkplug B to the enterprise.

This is exactly what the Proxus OPC UA to MQTT gateway and the broader industrial edge platform were built to solve.

When this may not be suitable

• Lower-frequency telemetry may not justify full distributed complexity.
• Small single-line plants may prefer simpler architectures first.
• Strict legacy constraints may require phased adoption.
• Safety-critical closed-loop control should remain in PLC/Safety PLC layers.

Observed performance depends on workload shape, node capacity, and deployment design.

Frequently Asked Questions

Can MQTT and OPC UA work together?

Yes, and in most modern IIoT architectures they should. OPC UA excels at structured, local machine-to-machine communication (reading complex multi-level data models from a CNC machine). MQTT excels at lightweight, scalable pub/sub distribution across sites. The Proxus Edge Gateway acts as the bridge - it reads via OPC UA locally, translates to MQTT Sparkplug B, and publishes to the Unified Namespace.

Is OPC UA Pub/Sub a replacement for MQTT?

Not in practice as of 2026. OPC UA Pub/Sub (Part 14) exists in the specification but has limited production-grade broker implementations and minimal adoption compared to the large MQTT ecosystem. Most vendors still implement OPC UA in its traditional client-server mode. If your vendor offers a stable OPC UA Pub/Sub broker with tooling support, evaluate it - but do not bet your architecture on an ecosystem that is still maturing.

Which protocol is more secure?

OPC UA has native, built-in certificate-based security with signing and encryption at the application layer (not just transport). MQTT relies on TLS for transport encryption plus username/password or certificate-based authentication at the broker level. For OT-to-cloud paths, both achieve comparable security when properly configured. The critical security decision is architectural - use outbound-only gateways, not protocol choice.

What about Modbus? Is it obsolete?

Modbus TCP/RTU remains the most widely deployed industrial protocol worldwide. It is simple, well-understood, and deeply embedded in instruments (power analyzers, VFDs, flow meters). It lacks semantic data modeling - a register address like 40001 carries zero context. This is precisely why Edge Gateways exist: they read Modbus registers, apply semantic context, and publish to the UNS with full metadata.

Do I need Sparkplug B, or is plain MQTT sufficient?

For a single-site pilot with homogeneous PLCs and a small team, plain MQTT with a documented JSON schema is simpler to start with. Sparkplug B becomes essential when you have multi-vendor environments, multi-site deployments, or third-party consumers that need self-describing payloads with Birth/Death session management. See the UNS Architecture Guide for guidance on when to adopt Sparkplug B.

References

1. OASIS MQTT v5.0 Standard - The protocol specification governing MQTT publish-subscribe messaging. mqtt.org
2. OPC Foundation - OPC UA Specification (IEC 62541) - The standard for industrial interoperability defining information modeling, client-server, and pub/sub communication. opcfoundation.org
3. Eclipse Sparkplug Specification - MQTT-based interoperability framework for IIoT, defining Birth/Death certificates and ProtoBuf payloads. sparkplug.eclipse.org
4. Modbus Organization - Modbus Protocol Specification - The open serial and TCP communication standard for industrial devices. modbus.org
5. ISA-95 / IEC 62264 - Standard for enterprise-control system integration, defining the hierarchical namespace model used in UNS topic design. isa.org

Protocol selection is most effective when aligned with workload, topology, and governance requirements. Want to see how Proxus can bridge your OPC UA equipment to an MQTT Unified Namespace, with minimal custom configuration?

Talk to a Solutions Architect →