The question “OPC UA or MQTT?” assumes the two technologies do the same job, and they do not. OPC UA is an information model and service architecture that presents data with its meaning and can be queried. MQTT is a light messaging protocol that does not look at what it carries. One answers “what is the data and how do I read it?”, the other “how and to whom is the data distributed?”.
Use OPC UA to talk to devices at the plant and present data meaningfully; use MQTT to distribute it to many consumers, the cloud or the enterprise layer without being blocked by network constraints. Many architectures include both.
The core difference: two models
OPC UA’s classic use is client–server: a client opens a session with a server, browses the address space, reads, writes and subscribes. MQTT is a publisher–subscriber model: publishers send messages to a broker, subscribers subscribe to topics they care about, and publisher and subscriber do not know each other. OPC UA also has a PubSub model and can use MQTT as a transport.
Comparison
| Criterion | OPC UA (client–server) | MQTT (+ Sparkplug B) |
|---|---|---|
| What it provides | Information model, services (browse, read, write, subscribe, call, history) | Light message transport; topic structure and payload format with Sparkplug |
| Meaning of data | Type, unit, hierarchy are part of the standard | Absent in plain MQTT; Sparkplug B adds a defined metric structure |
| Connection direction | The client connects to the server (an inbound port is needed on the server) | Both publisher and subscriber make outbound connections to the broker |
| Scale | Every client opens its own session | One publication is distributed to many subscribers |
| Commands and writes | Native support (write, method call) | Through topic and payload design; NCMD/DCMD in Sparkplug |
| Discovery | Browsing the address space | By subscribing to the topic tree; with Sparkplug BIRTH messages |
| Security | Application certificate, signing, encryption, user authentication | TLS, authentication and broker access rules |
| Weak links | Session is re-established; subscription management needed | QoS levels, retained messages, buffering |
Which one in which scenario?
Prefer OPC UA
- Direct integration with PLCs, CNCs, DCSs and drives (including legacy devices through a gateway such as Kepware Server).
- When you need browsing, method calls, history access and type information.
- On a reliable in-plant network, for a small number of rich clients.
Prefer MQTT (with Sparkplug B)
- When the same data is distributed to many systems (historian, analytics, MES, cloud).
- When the firewall only allows outbound connections, or the link is weak.
- When you are building a single current-data namespace (UNS).
Use both together
The common pattern is this: inside the plant, devices are read through OPC UA; an edge gateway normalizes the data, preserves quality and timestamp, and publishes to a broker with MQTT/Sparkplug B. Kepware Server’s IoT Gateway plug-in or OPC Router can take this role. The broker sits in a DMZ at the IT/OT boundary, and the OT side only opens outbound connections (IT/OT integration).
Six questions to decide
- How many consumers will receive the same data? (Many: PubSub/MQTT.)
- In which direction can the connection be opened? (Outbound only: MQTT or UA reverse connect.)
- Must meaning and types be preserved in transit? (If yes: the UA model or the Sparkplug metric structure.)
- Are writes or commands needed? (If yes, design a controlled, acknowledged mechanism.)
- Can data be lost when the link drops? (If not: buffering; see redundancy, buffering and recovery.)
- Who owns the data model? (Naming rules and ownership must be set up front.)
Common mistakes
- Not defining a common payload format over plain MQTT. Each application invents its own JSON; integration cost grows. Use Sparkplug B or a documented schema (choosing the data model).
- Publishing every tag to the cloud at the highest rate. Bandwidth and cost rise; publish by change and by need.
- Skipping broker security. TLS, authentication and topic-based access rules are mandatory.
- Dropping quality and timestamp. The value is carried but the information that it is stale or bad is lost (OPC UA data quality and timestamps).
For the OPC UA basics see What is OPC UA?; for Sparkplug B see What is Sparkplug B?.
Frequently asked questions
Is MQTT secure?
MQTT itself leaves security to the broker and the transport layer. With TLS, authentication and topic-based access rules configured correctly, a secure setup is possible.
Can OPC UA talk to the cloud directly?
Yes, but because of firewalls and scale most architectures prefer a gateway or publishing over MQTT. OPC UA PubSub with an MQTT transport makes this possible directly.
Is Sparkplug B mandatory?
No, but it is a common standard for a shared topic structure and payload format over MQTT, and it makes products from different vendors easier to combine.
