Contents
What is the difference in one sentence?
OPC UA is an information model with a transport, MQTT is a transport without an information model. OPC UA describes what a value means — type, unit, membership, access rights. MQTT only moves it from A to B and leaves the meaning to your convention. Everything else follows from that single difference.
How do the two compare in detail?
| Criterion | OPC UA | MQTT |
|---|---|---|
| Information model | Part of the standard: typed nodes, references, units, industry-specific companion specifications | None. Meaning comes from topic structure and payload convention that you define and enforce yourself |
| Discovery | Built in. The address space is browsable at runtime; a client finds nodes without prior knowledge | Not present. Topics must be known or derived from a convention |
| Communication pattern | Client/server (request, subscribe) and, since 1.04, PubSub as well | Publish/subscribe via a broker, with QoS 0/1/2 |
| Latency | Session-based; typically low double-digit milliseconds on a LAN. Connection setup is expensive, the running session is cheap | Very low in steady state. QoS 2 costs two extra round trips, QoS 0 none |
| Payload size | Binary encoding is compact, JSON encoding considerably larger. Address space overhead falls at connection setup, not per value | Header from 2 bytes. Actual size is determined solely by your payload format |
| Security model | In the standard: X.509 certificates per application, signing and encryption at message level, user rights in the address space | TLS at transport level. Authentication and rights sit with the broker and differ between implementations |
| Firewall behaviour | The server sits in the plant, connections arrive inbound. Across factory boundaries this needs a firewall rule or a reverse tunnel | Outbound broker connection. Passes through NAT and restrictive firewalls without opening inbound ports |
| Broker dependency | None in client/server mode. PubSub can optionally run through a broker | Mandatory. The broker is a single point of failure and has to be operated, scaled and secured |
| Suitability at the edge | Real resource footprint: stack, certificate store, address space. Usually too much for very small devices | Runs on microcontrollers. The client fits in a few kilobytes |
| Tooling | Mature on the controller side: nearly every modern PLC ships a server. Thinner on the analysis side | Mature on the analysis side: brokers, bridges, stream connectors everywhere. Often retrofitted on the controller side |
When does OPC UA carry the day?
When the semantics have to travel along. As soon as machines from different manufacturers must deliver the same concept — tool, order, state, fault — comparably, a standardised information model saves exactly the mapping work that otherwise recurs in every integration project.
The real argument is not the protocol mechanics but the companion specifications: industry-agreed models that fix how an injection moulding machine or a robot names its data. Where such a specification exists and manufacturers implement it, integration is a one-off rather than a per-device exercise.
The second case is discovery. If you need to know at runtime what an installation even offers — because the estate changes, or because you do not want to maintain a data sheet per machine — a browsable address space is the difference between operating and babysitting.
When does MQTT carry the day?
When volume, frequency and network boundaries dominate. An outbound broker connection passes through firewalls that will not admit inbound OPC UA connections — and that is the normal case as soon as data is meant to leave the plant.
The second case is device variety under tight resources. An MQTT client fits on a microcontroller; an OPC UA server generally does not. Anyone connecting hundreds of small sensor nodes has effectively no choice.
The third case is decoupling. The broker separates acquisition from analysis: if the analysis fails, measurements keep flowing and are processed later. With a direct client/server connection they are simply missing.
What does the combination look like in practice?
The most common architecture is not either/or but OPC UA at the machine, MQTT across the site boundary. An edge node speaks OPC UA to the controller, normalises the values and republishes them via MQTT.
The semantics stay where they arise — close to the installation, where they can be verified — and the transport outward is lean and firewall-friendly. In our IIoT projects this is exactly where the boundary between processing stages sits: device connectivity in its own stage, ingest via MQTT, downstream processing via Kafka. A new device class then touches only the first stage.
What governance does MQTT cost that OPC UA brings along?
This calculation is regularly overlooked. What OPC UA ships in the standard, you have to build yourself with MQTT and sustain for years:
- Topic structure. Who decides how a topic is composed? Without a binding convention, a year produces a sprawl nobody can query any more.
- Payload schema. JSON without a schema is a promise, not a contract. The difference becomes apparent the moment a manufacturer renames a field — at best in test, at worst in production.
- Units and scaling. Is the value in watts or kilowatts? OPC UA writes it onto the node. With MQTT it lives in documentation nobody reads.
- Access rights. Broker-side topic ACLs are implementation-dependent and have to be maintained.
None of this is an argument against MQTT. It is an argument for settling these points before the first production topic rather than after.
How do the two behave at the firewall?
OPC UA in client/server mode requires the client to reach the server. Across factory boundaries that means an inbound rule, a VPN or a reverse tunnel — organisationally expensive and, in many plants, simply not approvable.
MQTT reverses the direction. The device opens the connection outward and holds it; the firewall sees an ordinary outbound TLS connection. That is why MQTT almost always wins the site boundary in practice, regardless of what runs at the machine.
What about Sparkplug B?
Sparkplug B is the attempt to retrofit onto MQTT what it lacks: a binding topic structure, a defined payload format and a state model with birth and death messages, so a consumer knows whether a device is merely quiet or actually gone.
That solves part of the governance problem and is a serious option when the alternative is home-grown conventions. But it does not replace an industry-agreed information model: Sparkplug standardises the form, not the meaning. Whether “Temp_1” is the flow temperature is as unclear there as in bare MQTT.
And when the controller speaks neither?
This case is more common than vendor presentations suggest — especially with installations expected to run for ten or twenty years. What remains is the proprietary interface, documented at best as a PDF.
We have built our own transport implementations for such controllers several times and hidden them behind the same device connectivity stage that holds OPC UA and Modbus. From above, the platform sees no difference. That is unspectacular, but it is the reason the analysis does not have to be touched every time a device is added.
How we decide
Three questions answerable without a project:
- Does the meaning have to travel, or is the value enough? If several manufacturers must deliver the same concept comparably: OPC UA — because of the companion specification, not because of the protocol.
- Where does the network boundary run? As soon as data leaves the plant: MQTT outward, regardless of what runs inside.
- Who maintains the convention in three years? If there is no answer, MQTT’s governance cost is being underestimated — then either OPC UA is the more honest choice or Sparkplug B is the minimum.
If you are facing this decision: we look at your actual installation landscape and tell you which of the three questions decides it for you. Details under Industrial IoT & automation.