Two standards, two different jobs.
OPC UA (IEC 62541) is an interoperability standard with an information model: typed, browsable objects carrying data types, engineering units and methods, normally accessed client/server. MQTT (OASIS, v3.1.1 and v5.0) is a lightweight publish/subscribe transport: a broker decouples publishers from subscribers and moves small messages over unreliable networks, with no opinion whatsoever about what is inside them. They are not two candidates for the same slot, which is why the honest answer is usually both — OPC UA to get structured data out of machines, MQTT to distribute it across the plant.
The differences that actually change your design.
| Dimension | OPC UA | MQTT |
|---|---|---|
| Interaction model | Client/server sessions with subscriptions and monitored items. A client has to know and reach each server. OPC UA PubSub (Part 14) adds a broker-based mode that can run over MQTT. | Publish/subscribe through a broker. Publisher and subscriber never know each other, so adding a tenth consumer changes nothing upstream. |
| Information model | A browsable address space: objects, variables, data types, engineering units, methods, plus companion specifications for whole machine families. | None. The payload is opaque bytes. MQTT 5 adds user properties and a content-type hint, but no model — Sparkplug B is the usual way to supply one. |
| Discovery | Browse the server at runtime. A new client can learn the structure without a spreadsheet from the integrator. | Subscribe to a wildcard and see what arrives. Meaning comes from a topic convention you design, document and govern yourself. |
| Network behaviour | Sensitive to latency and loss; sessions reconnect and re-subscribe. Wants inbound connections through the firewalls between levels, plus a certificate exchange. | Each edge device opens one outbound TLS connection. QoS 1, persistent sessions and last will survive drops, which is why it is comfortable over cellular, satellite and NAT. |
| Payload and bandwidth | UA Binary over TCP 4840 is compact; the JSON encoding is not. Subscriptions report by exception when you configure deadbands and sampling deliberately. | Two-byte minimum fixed header; ports 1883 plain, 8883 TLS. A Sparkplug DDATA update using metric aliases is typically tens of bytes. |
| Security | Per-session X.509 certificates, signing and encryption, user authentication, named security policies. Trust lists and certificate expiry are real, recurring operational work. | TLS plus username/password, client certificate or token. Topic-level authorisation lives in the broker, so broker access control is the design work you cannot skip. |
| Best fit | Machine and line integration: typed access, commands and methods with acknowledgement, or a vendor companion specification you want to inherit rather than re-invent. | Plant-wide and site-to-cloud distribution: many independent consumers, intermittent links, event-driven architecture, and the transport under most UNS deployments. |
Reach for OPC UA
When you need the structure of a machine, not a list of addresses: typed nodes, units, methods, alarms and conditions, and a companion specification that already models your equipment class. Also when a command needs a definitive acknowledgement rather than a fire-and-forget publish.
Reach for MQTT
When one measurement has many consumers — dashboards, historian, MES, an analytics job, a partner site — and you refuse to add an integration every time a consumer appears. Also whenever the link is bad: a broker with QoS 1 and store-and-forward tolerates what a client/server session does not.
The usual shape
OPC UA from the machines into an edge node; the edge node maps tags into a governed namespace and republishes by exception to an MQTT broker; everything else subscribes. The mapping step is where the modelling work lives, and skipping it is what produces a broker full of tag soup.
Traps we see in real deployments.
- Treating the choice as a plant-wide religion. The decision is per hop — machine to edge, edge to plant, plant to cloud — and different hops legitimately choose differently.
- Bridging one OPC UA node to one MQTT topic with no model in between. You have moved the tag soup, not built a namespace.
- Assuming MQTT delivers a UNS. MQTT delivers messages; hierarchy, naming, payload contract and governance are still your work.
- Letting OPC UA certificates and trust lists drift until an expiry takes the line down on a Sunday.
- Turning on QoS 2 everywhere “to be safe”. It costs a four-part handshake per message; QoS 1 with idempotent consumers is the normal industrial choice.
- Polling 20,000 OPC UA nodes on a one-second timer and calling the result event-driven. Report by exception is a configuration decision, not a protocol badge.
Where this decision sits.
Protocol choice is the plumbing under a bigger question: what information the plant publishes and who is allowed to depend on it. That is what a Unified Namespace defines, what Sparkplug B encodes on the wire, what ISA-95 gives a shared vocabulary for, and what contextualization turns into something a person or a model can read. The Minimum Technical Requirements — edge driven, report by exception, open, lightweight — are a faster filter than a feature matrix. Downstream, the same choice decides whether an OEE number can be trusted and whether predictive maintenance ever sees the signal it needs.
Check your topics before you standardise on them.
Our free browser tools lint a Sparkplug B topic against the specification grammar and check a list of namespace paths for the things that quietly rot a namespace: inconsistent depth, mixed casing, spaces, case collisions, duplicates. Nothing you paste leaves your machine.
Open the free tools