MQTT vs. OPC UA in Modern IIoT: Which Protocol Should You Choose?

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. If you already know you need to bridge OPC UA sources into MQTT topics, jump to the focused OPC UA to MQTT gateway page.

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 commonly uses a client/server architecture. A server exposes an address space and services; clients can read, write when authorized, call methods, or create subscriptions and monitored items for change and event notifications. OPC UA also defines PubSub profiles.

Where OPC UA is a strong fit

• 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").
• Rich industrial interoperability: OPC UA supports typed information models, subscriptions, events, methods, security, and vendor-neutral semantics. Deterministic safety control still belongs to the appropriate fieldbus and safety system.
• Deep Penetration: Most major automation vendors (Siemens, Rockwell, Beckhoff) support it natively in their advanced hardware.

OPC UA scaling considerations

OPC UA is not limited to polling: clients can use subscriptions and monitored items, and OPC UA also defines PubSub. At enterprise scale, teams still need to manage server sessions, subscriptions, certificate trust, address-space differences, network zones, and source ownership. Direct access from many consumers to every source can become difficult to govern.

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. Publishers send messages to broker topics according to application-defined timing or events. Subscribers receive matching messages without opening a direct connection to each source. MQTT itself does not decide when a value is meaningful or define the payload schema.

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.

Message overhead cannot be compared with one universal byte count. Topic length, QoS, session state, security, batching, payload encoding, OPC UA service choice, and transport all affect the result. Benchmark the actual mapping and workload.

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)

For machine information models, secure data access, alarms, events, or vendor-neutral interoperability, OPC UA may be the better source-side contract. Safety-critical and hard real-time control should use the fieldbus and safety architecture approved for that machine; choosing OPC UA alone does not establish determinism.

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

For broker-mediated delivery across sites and multiple consumers, MQTT may reduce direct source-consumer coupling. Use Sparkplug B when its state, metric, and topic conventions fit the participants. The choice must be verified against broker capacity, payload semantics, delivery expectations, and lifecycle governance.

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. Proxus is not just a transport relay; it acts as an industrial MQTT gateway with edge buffering, topic mapping, UNS alignment, and delivery into the broader industrial data platform.

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 →