If you spend any time around industrial IoT, you have heard the same debate over and over again. Should we use MQTT or OPC UA? The question gets framed as a competition, as if one protocol must win and the other must lose. In practice, that framing is wrong. MQTT and OPC UA were designed to solve fundamentally different problems, and most production IIoT architectures end up using both — often at the same time, on the same gateway.
This article unpacks what each protocol actually does well, where they break down, and how to decide which one belongs on which side of your data pipeline.
TL;DR
- MQTT moves bytes. It is a lightweight transport for publish/subscribe messaging, payload-agnostic, and ideal for constrained networks and cloud telemetry.
- OPC UA moves meaning. It is a full information modeling framework with built-in security, semantic data, and discoverability — designed for plant-floor interoperability.
- They are not mutually exclusive. OPC UA PubSub (Part 14) can run over MQTT, giving you semantic data on top of lightweight pub/sub.
- A typical IIoT gateway speaks OPC UA (or Modbus, EtherNet/IP, S7) on the south side, then publishes to MQTT brokers on the north side.
Two Different Origins, Two Different Mindsets
MQTT was born in 1999 at IBM, designed by Andy Stanford-Clark and Arlen Nipper for monitoring oil pipelines over satellite links. The constraints shaped everything about it: assume the network is slow, expensive, and unreliable; assume the device is small; keep the protocol header microscopic; let the application decide what to put in the payload. Two decades later, MQTT 3.1.1 became an ISO standard (ISO/IEC 20922), and MQTT 5 added features that modern cloud architectures expect — user properties, message expiry, shared subscriptions, reason codes.
OPC UA emerged from a different world. The OPC Foundation released the first specification in 2008 as a successor to OPC Classic (OLE for Process Control), which had tied the industry to Microsoft DCOM. The mandate was to break that dependency while solving a harder problem: how do you make a Siemens PLC, a Beckhoff motion controller, a B&R servo drive, and a Rockwell DCS understand each other semantically, not just exchange raw bytes? OPC UA's answer was an information model — a self-describing address space where data has types, relationships, and meaning.
These origin stories explain almost every design decision that follows.
Architecture
MQTT is broker-centric and decoupled. Publishers send messages to topics. Subscribers register interest in topics. A central broker fans out the traffic. Publishers and subscribers never know about each other directly. The broker can be a tiny embedded Mosquitto instance or a clustered HiveMQ deployment handling millions of clients — the protocol does not care.
OPC UA was originally client-server. A client opens a session with a server, then issues services: Browse to explore the address space, Read and Write to access node values, CreateSubscription to get notified of changes. The server is stateful and authoritative. This worked well on a LAN but did not scale to cloud-style fan-out.
OPC UA Part 14 added PubSub in 2018, supporting both broker-based transports (MQTT, AMQP) and broker-less ones (UDP multicast). This was the foundation's acknowledgment that the world had moved on from pure client-server.
Protocol selection by design axis
bar chartData Models
This is where the two protocols diverge most sharply.
MQTT is payload-agnostic. A message body can be JSON, Protobuf, CBOR, raw binary, a JPEG, or plain text. The protocol carries it but does not interpret it. Your topic hierarchy (factory/line-3/oven/temperature) is a naming convention you invent and enforce yourself. If a subscriber needs to know that temperature is in degrees Celsius and ranges from 0 to 400, that knowledge lives outside the protocol — in documentation, in a contract, in a schema registry.
OPC UA is intensely structured. Every node in the address space has a NodeId, a BrowseName, a DataType, a Value, and references to other nodes. Companion specifications layered on top — PLCopen for control logic, Auto-ID for RFID readers, MachineTool, Pump, Robotics, Weihenstephan for breweries — define what a "Pump" or "MachineTool" looks like in OPC UA terms. A client that has never seen your device can connect, browse the address space, discover what is available, and understand the semantics of each value without any prior agreement.
That capability — connect-and-discover with full semantics — is OPC UA's killer feature. It is also what makes it heavier.
Security
MQTT relies on TLS for transport encryption, username/password or client certificates for authentication, and broker-level ACLs for authorization. The security model lives at the broker. Different brokers implement authorization differently, and there is no standard way to express fine-grained permissions in the protocol itself.
OPC UA has cryptographic security baked into the message layer. X.509 certificates for both client and server, configurable security policies (Basic256Sha256, Aes256_Sha256_RsaPss), per-message signing and encryption, user authentication separate from application authentication, and role-based access control defined in Part 18. For environments that need to demonstrate compliance with IEC 62443 or NERC CIP, OPC UA gives you primitives that map directly to the standards.
This is one of the strongest arguments for OPC UA on the plant floor: the security model was designed for industrial control systems from day one.
Bandwidth and Overhead
MQTT's minimum packet is 2 bytes of fixed header plus a variable header and payload. A PUBLISH of a 4-byte float to a short topic comes in under 20 bytes on the wire. QoS 0 (fire-and-forget), 1 (at-least-once), and 2 (exactly-once) let you trade reliability for bandwidth.
OPC UA Binary is more verbose. A simple monitored item notification might run 50 to 100 bytes. Sessions, subscriptions, and security tokens all add state-management overhead. The protocol was designed for LAN throughput, not cellular bandwidth. OPC UA over HTTPS/SOAP (the old XML binding) was genuinely heavy and is now rarely used.
OPC UA PubSub over MQTT or UDP brings the overhead down significantly, especially with the JSON or binary UADP encoding. For greenfield designs that need both semantic structure and bandwidth efficiency, this combination is increasingly the right answer.
Discoverability
Plug an MQTT client into a broker you have never seen. What can you do? You can subscribe to # (wildcard everything) and watch traffic flow by, then try to reverse-engineer the topic hierarchy and the payload format. That is your only option without external documentation.
Plug an OPC UA client into a server you have never seen. You can browse the entire address space, inspect data types, read historical values, see which methods are callable, and identify whether the server implements a known companion specification. The protocol is fundamentally introspectable.
For systems that evolve frequently — where machines get added, retired, or reconfigured — this matters. OPC UA clients adapt automatically. MQTT clients need their contracts updated out of band.
When to Use MQTT
MQTT is the right choice when:
- You are sending telemetry from edge devices to the cloud, especially over cellular, satellite, or other bandwidth-constrained links.
- You have many publishers and many subscribers and need loose coupling between them.
- You are integrating with hyperscaler IoT platforms (AWS IoT Core, Azure IoT Hub, Google Cloud IoT, HiveMQ Cloud) — all of them speak MQTT natively.
- You control the payload format end-to-end and do not need cross-vendor semantic interoperability.
- You need a small client footprint on resource-constrained microcontrollers.
- You are bridging OT data to IT systems (Kafka, time-series databases, business intelligence tools).
When to Use OPC UA
OPC UA is the right choice when:
- You are reading data from PLCs and motion controllers on the plant floor. Most major vendors — Siemens (S7-1500), Beckhoff (TwinCAT), B&R (Automation Studio), Rockwell, ABB — ship OPC UA servers in their controllers.
- You need semantic interoperability between equipment from different vendors without writing custom adapters for each one.
- You are operating in a regulated environment (pharmaceutical, automotive, aerospace) where data provenance and security matter.
- Your data structure will change over time and clients need to adapt without recompilation.
- You are implementing a known companion specification (Weihenstephan for breweries, Euromap for plastics machinery, Umati for machine tools).
- You need built-in support for historical access, alarms and conditions, and methods (callable functions).
The Hybrid Pattern: OPC UA on the South, MQTT on the North
Most modern IIoT gateways — including the Modibus MB213 — implement what is essentially a translation layer. On the south side (toward the field), the gateway speaks the protocols that field devices speak: Modbus RTU and TCP, OPC UA Client to PLCs, EtherNet/IP, Siemens S7, BACnet for building automation. On the north side (toward the cloud or enterprise), it publishes to MQTT brokers, often with TLS and client certificates, often using Sparkplug B for payload structure.
This pattern works because the requirements on each side are different. The plant floor needs determinism, discoverability, and standardized semantics — OPC UA territory. The path to the cloud needs bandwidth efficiency, loose coupling, and broad ecosystem support — MQTT territory. The gateway is where the translation happens.
Sparkplug B: MQTT with Semantics
Vanilla MQTT's biggest weakness is the lack of payload structure. Sparkplug B, an Eclipse Foundation specification developed by Cirrus Link, addresses this. It defines:
Sparkplug B does not match OPC UA's semantic depth — there are no companion specifications, no methods, no alarms-and-conditions model. But it is dramatically lighter than OPC UA, and for many cloud-bound telemetry use cases, it is the sweet spot.
- A standardized topic namespace (spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id})
- Birth and death certificates so subscribers know what metrics a publisher offers and when it goes offline
- Strongly-typed metric definitions with engineering units, scaling, and historical state
- Sequence numbering for detecting message loss
OPC UA PubSub over MQTT
If you want OPC UA's semantic richness but MQTT's transport efficiency, OPC UA PubSub over MQTT (Part 14) is increasingly the recommended pattern for greenfield designs. The publisher serializes OPC UA messages using the UADP binary encoding or JSON encoding and publishes them to MQTT topics. Subscribers receive fully-typed OPC UA data without the overhead of session establishment.
The trade-off: tooling maturity is lower than vanilla MQTT or OPC UA client-server. Not every broker, not every cloud platform, and not every SCADA system handles OPC UA PubSub gracefully yet. Expect this to improve quickly over the next two to three years.
Decision Framework
When in doubt, ask three questions:
Where does the data live, and where does it need to go? Plant-floor to plant-floor: OPC UA. Plant-floor to cloud: MQTT (or OPC UA PubSub over MQTT). Cloud to cloud: MQTT.
Who controls the schema? If you control both publisher and subscriber, MQTT plus a documented payload format works. If you need cross-vendor interoperability without bilateral agreements, OPC UA.
What is the bandwidth budget? Cellular, LPWAN, or satellite: lean toward MQTT. Wired LAN with no constraints: OPC UA is fine.
| Concern | MQTT | OPC UA |
|---|---|---|
| Payload size | Minimal | Higher |
| Built-in semantics | No | Yes |
| Discoverability | No | Yes |
| Cloud ecosystem | Excellent | Limited |
| Plant-floor adoption | Growing | Dominant |
| Security model | Transport (TLS) | Message + Transport |
| Companion specs | No (Sparkplug B closest) | Many |
| Best fit | Telemetry, cloud bridging | Interoperability, control systems |
Closing Thought
The honest answer to "MQTT or OPC UA?" is almost always "both, in different places." MQTT is the right tool for moving bytes efficiently across networks. OPC UA is the right tool for moving meaning across vendors. A well-designed IIoT architecture uses each one where its strengths align with the problem in front of it.
That is precisely why industrial gateways exist — to make the boundary between these two worlds clean, secure, and observable.
Modibus MB213 supports MQTT (with TLS, Sparkplug B, and configurable QoS) and OPC UA (client and server roles) out of the box, alongside Modbus RTU/TCP and other industrial protocols. To discuss a specific architecture, [contact us](https://modibus.com).