Ask five automation engineers whether to use OPC UA or MQTT and you'll get five confident, contradictory answers — usually because each one is thinking of a different layer of the same architecture. The honest answer is that most well-built IIoT systems end up using both, just not for the same job.
What OPC UA is actually for
OPC UA describes an information model, not just a wire protocol. A tag isn't just a value — it carries type, units, quality, timestamp and its relationship to other tags in a structured address space that a client can browse and discover. That structure is exactly what a SCADA system, a historian or an MES needs when it's talking to a PLC it didn't necessarily configure itself.
Security and interoperability are built into the specification rather than bolted on: certificate-based authentication, encrypted transport and a standardised companion information model (with vendor-specific extensions) mean an OPC UA client from one vendor can usually make sense of a server from another with minimal integration work. That's the payoff for the protocol's relative weight.
What MQTT is actually for
MQTT doesn't know or care what a tag means. It's a lightweight publish/subscribe protocol built around a broker: publishers send a message to a topic, subscribers receive it, and neither side needs to know the other exists. That decoupling is the whole point — it's what makes MQTT the natural choice for constrained edge devices, unreliable connections and one-to-many data distribution.
A small controller on a cellular link, publishing a handful of telemetry values every few seconds with automatic reconnect and a "last will" message if it drops offline, is MQTT's home ground. The protocol overhead is tiny compared to OPC UA, which matters when you're paying for every byte over a metered connection.
Where they actually meet
In practice, the split usually falls along the plant boundary. Inside the plant, where PLCs, SCADA and historians already understand structured, typed data and the network is reliable, OPC UA does the heavy lifting. At the edge — remote sites, mobile assets, anything talking over a WAN or cellular connection — MQTT carries the lightweight telemetry upstream to a broker, often with an edge gateway translating between the two.
That gateway is doing real work: subscribing to an OPC UA server locally, republishing selected tags to MQTT topics for anything that needs them off-site, and optionally doing the reverse for commands coming back down. Get the tag selection wrong at the gateway and you either flood a metered link with noise or starve a dashboard of the one value someone actually needed.
A practical decision rule
- Talking between systems that both expect structured, typed, browsable data on a reliable network? Use OPC UA.
- Publishing telemetry from constrained, remote or intermittently connected devices to one or many subscribers? Use MQTT.
- Need both — plant-side structure and edge-side reach? Use OPC UA inside the fence, MQTT (ideally with Sparkplug B) outside it, and treat the gateway between them as a real piece of the design, not an afterthought.
The protocol choice that costs you a rewrite is rarely "MQTT vs. OPC UA" in the abstract — it's picking one where the other's strengths were actually the requirement.