LADX
Start free
← Resources
Networking·8 min read·

MQTT Sparkplug or OPC UA: pick by where the data is going

One is a session between two machines, the other is a broadcast to a plant. The comparison people make, and the one they should.

Short answer

OPC UA is a client server session with a rich browsable information model, and it suits reading structured data from a machine on a local network. MQTT with Sparkplug B is publish and subscribe through a broker, and it suits distributing values to many consumers across a site or over a poor link. Most real architectures use both: OPC UA at the equipment, MQTT for distribution.

Which protocol sits whereENTERPRISEOPC UAMQTTCONTROLEtherNet/IPPROFINETModbus TCPDEVICEIO-LinkPROFIBUS DPModbus RTUEthernet carries most of it now, which is why the layers blur.

The comparison is usually framed as which protocol is better, which has no answer, because they are shaped for different topologies.

The shapes

OPC UA is a session. A client connects to a server, authenticates, browses an address space, and reads, writes or subscribes to nodes within it. The relationship is one to one and stateful.

MQTT is a broker. Publishers send messages to topics; subscribers receive the topics they asked for. Neither knows the other exists. The relationship is many to many and the broker holds it together.

That difference decides nearly everything else.

Where OPC UA is strong

The information model. This is genuinely the thing MQTT has no answer to. An OPC UA server does not offer a flat list of tags; it offers a typed, browsable hierarchy with units, ranges, descriptions and relationships. A client can discover what a machine offers without being told in advance.

Companion specifications. Industry groups have defined standard models for machine types, so two conforming machines from different makers expose the same structure. That is a large amount of integration work already done.

Built in security. Certificates, signing and encryption are part of the specification rather than something bolted on, and a conforming server has them.

Methods. You can call a function on the server, not just read values. Genuinely useful and often forgotten.

Where MQTT is strong

One publish, many consumers. A temperature published once reaches the historian, the dashboard, the MES and the analytics job without the publisher knowing about any of them. Adding a fifth consumer changes nothing at the source.

Poor links. Quality of service, retained messages and last will handle a connection that comes and goes. Over cellular or a satellite link to a remote pumping station, this is decisive.

Light footprint. The protocol is small enough for a constrained device that would struggle with an OPC UA stack.

Firewall shape. Clients connect outbound to the broker. There is no inbound rule to open into the plant network, which security teams like considerably.

The last point wins more arguments in practice than any technical merit, and it is a real advantage rather than a political one.

Sparkplug B, briefly

Plain MQTT has no opinion on payloads, so everybody invents their own and none of them interoperate.

Sparkplug B defines the payload, the topic structure, birth and death certificates so subscribers know what exists and when it left, and sequence numbers so gaps are detectable. Running industrial MQTT without it means building all of that yourself, less well.

The arrangement most people end up with

OPC UA from the machine to an edge gateway, on the local network, where the information model and the security model earn their cost.

MQTT with Sparkplug from that gateway to everything else, where the fan-out and the firewall shape earn theirs.

It is not a compromise. It is each protocol used where it is strongest, and the gateway between them is a small, ordinary piece of software.

Common questions

Is MQTT faster than OPC UA?
For distributing a value to many consumers, yes, because it is published once and fanned out by the broker. For a request and response exchange with one machine, OPC UA is comparable and carries far more context. Latency is rarely the deciding factor; topology is.
Can MQTT work over an unreliable link?
Better than OPC UA, which is one of its main advantages. Quality of service levels, a last will message, and buffering at the edge mean a link that drops for ten minutes results in a gap and a resynchronisation rather than a failed session and a manual restart.
What about OPC UA Pub/Sub?
It exists in Part 14 of the specification and addresses exactly this gap, including an MQTT mapping. Adoption is still much thinner than plain MQTT and the tooling is less mature, so it is worth knowing about and hard to recommend as a default today.

Keep reading