In almost every IIoT project the same question comes up: OPC UA or MQTT? Sometimes there's a genuine decision to be made. Often there's a hope behind it that a clear answer exists — “use X and you're done.”
The honest answer is: it depends. But “it depends” is only helpful if you know what it depends on. That's exactly what I'll try to explain here — from the perspective of someone who uses both protocols regularly in real manufacturing environments.
What OPC UA is — and what it isn't
OPC UA (Open Platform Communications Unified Architecture) is an industrial communication standard published by the OPC Foundation in 2008. The crucial point: OPC UA isn't just a transport protocol. It also defines a semantic data model.
What does that mean in practice? When a Siemens S7 PLC exports a data point “spindle speed” via OPC UA, an OPC UA client doesn't just know that the value is 3,200. It also knows what that value means, what unit it has, which limits apply and when it last changed.
That's the big advantage of OPC UA: the data carries its own meaning with it. That makes integration much more robust, because less implicit knowledge has to be agreed between sender and receiver.
What MQTT is — and why it became so popular
MQTT (Message Queuing Telemetry Transport) was developed by IBM in 1999 for applications in environments with poor network connectivity — originally for oil pipelines in the desert. Lightweight, robust, low latency, minimal overhead (the header needs only 2 bytes).
MQTT is a pure pub/sub protocol: devices (publishers) send messages to topics. A broker (e.g. Mosquitto or HiveMQ) distributes them to all subscribers. That works extremely well — but MQTT itself doesn't define what's in those messages. Sender and receiver have to agree on that in advance.
If a machine sends a value of “3200” via MQTT, the receiver initially knows nothing about it — apart from whatever is in the topic name. Whether it's revolutions per minute, watts or grams is entirely down to the implementation.
Head-to-head comparison
| Aspect | OPC UA | MQTT |
|---|---|---|
| Origin | Industrial standard (OPC Foundation, 2008) | IoT protocol (IBM, 1999) |
| Architecture | Client-server & pub/sub (from v1.04) | Pub/sub (broker-based) |
| Data model | Typed, semantic (address space) | Payload-agnostic (binary, JSON, etc.) |
| Semantics | Built in — data has meaning | None — meaning has to be agreed |
| Security | TLS + certificates natively | TLS optional, implementation varies |
| Overhead | Higher (XML/binary, handshake) | Very low (header: 2 bytes) |
| Latency | Low to medium | Very low |
| Best suited for | Machine connectivity, OT integration | Sensor→cloud, edge→back end |
When I recommend OPC UA
OPC UA is the right choice when the connection to the machine control is the priority — in other words, when you want to read data directly from a PLC, a CNC controller or a SCADA system.
- Machine connectivity: Siemens, Beckhoff, B&R, Bosch Rexroth — these PLCs support OPC UA natively. The integration is clean, typed and well documented.
- Interoperability: If different machines from different manufacturers need to be integrated, OPC UA gives you a common standard. With MQTT you have to define a separate topic structure for every machine.
- IT/OT integration: OPC UA has a clear security framework (certificates, authentication, encrypted sessions). That matters in regulated environments and wherever IT and OT networks are connected.
- Semantic requirements: If data points need to be interpreted consistently across different systems — e.g. in the historian, SCADA and analytics at the same time — OPC UA's typed data model is a considerable advantage.
When I recommend MQTT
MQTT is the right choice for everything that happens between the edge device and the back end — especially when lots of data points have to be transmitted at high frequency and the network connection may be unreliable.
- Sensor connectivity: Raspberry Pi, Arduino, ESP32 — these devices rarely have OPC UA implemented. MQTT runs on all of them, with minimal resources.
- Offline capability: MQTT brokers can buffer messages (QoS levels 1 and 2) until the subscriber is reachable again. That's valuable in production environments with an unstable network.
- High throughput: If 500 data points per second need to be transmitted, MQTT is considerably more efficient than OPC UA thanks to its minimal overhead.
- Cloud connectivity: AWS IoT Core, Azure IoT Hub — the major cloud IoT platforms speak MQTT natively. OPC UA always needs an adapter there.
The most common answer in practice: both
In almost every project we deliver, both protocols are used — at different points in the architecture. Typically it looks like this:
PLC (Siemens S7) ──OPC UA──▶ Edge gateway
Edge gateway ──MQTT──▶ Broker (Mosquitto/HiveMQ)
Broker ──MQTT──▶ InfluxDB / Grafana / back end
OPC UA reads the machine control — typed, semantically correct, with certificate authentication. The edge gateway (typically an industrial PC or a Raspberry Pi) normalises the data and passes it on via MQTT — lightweight, offline-capable, cloud-compatible.
That isn't a compromise. It's the architecture that uses the strengths of each protocol in the right place.
A practical decision guide
Machine has native OPC UA?
→ Use OPC UA directly.
Machine has a proprietary interface (FOCAS, SHDR, Siemens S5)?
→ Adapter on the edge gateway, output via MQTT.
Sensor without a network protocol (analogue, digital I/O)?
→ Edge gateway with sensor hardware, output via MQTT.
Data needs to go to a cloud platform (Azure, AWS)?
→ MQTT to the broker, then onwards.
Several machines from different manufacturers need to be unified?
→ OPC UA as the target protocol, adapters where needed.
Very high data rate (>100 points/s)?
→ Prefer MQTT.
Regulated environment, audit requirements?
→ OPC UA, because of its security and authentication framework.
What MQTT Sparkplug B changes
A quick note for anyone who wants to dig deeper: MQTT Sparkplug B is a specification that builds on MQTT and defines a standardised data model and topic structure for industrial applications. It tries to bring OPC UA's semantic advantage to MQTT.
In practice we mainly see Sparkplug B in greenfield projects with uniform infrastructure. For mixed environments with legacy machines, OPC UA remains the more robust choice at the machine level.
Conclusion
OPC UA and MQTT aren't competitors — they solve different problems at different points in an IIoT architecture. “OPC UA or MQTT?” is often the wrong question. The right question is: “What needs to be transmitted where, under what conditions, with what requirements for security and semantics?”
If you want to talk these questions through for your own situation — which machines you have, which protocols they speak and what a pragmatic architecture would look like: get in touch.