OPC UA vs MQTT is one of the most common debates in Industrial IoT, and it is usually framed the wrong way. This comparison explains what each protocol was designed for, how they differ in information modeling, communication pattern, security and cloud connectivity, and why the most common real-world answer is "OPC UA at the edge, MQTT to the cloud". By the end you will know which one to use for each layer of your architecture.
Two Protocols, Two Different Jobs
OPC UA (Open Platform Communications Unified Architecture) is an industrial interoperability framework. It defines not just how bytes move, but how a machine describes itself: objects, variables, methods, types, engineering units, alarms and history. A client connects to a server, browses its address space and reads, writes, subscribes or calls methods. It is standardised as IEC 62541 and is built into many modern PLCs, CNCs and SCADA systems.
MQTT is a lightweight publish/subscribe messaging protocol. Clients connect to a central broker, publish messages to topics and subscribe to topics they care about. MQTT deliberately says nothing about what the payload means; it moves bytes efficiently and reliably over unreliable networks. It is an OASIS standard, and versions 3.1.1 and 5.0 are in wide use. If you are new to the broker concept, start with what an MQTT broker does.
So the comparison is a bit like comparing a database schema with a message bus. Both move data, but the value each brings is different.
OPC UA vs MQTT at a Glance
| Dimension | OPC UA (client/server) | MQTT |
|---|---|---|
| Primary pattern | Client/server sessions; subscriptions per session | Publish/subscribe through a broker |
| Information model | Rich, typed, browsable address space with metadata | None built in; topics and payloads are defined by you or by a spec such as Sparkplug B |
| Discovery | Browse the server to find nodes and types | Subscribe with wildcards; no built-in schema discovery |
| Coupling | Each consumer connects to each server | Producers and consumers only know the broker |
| Network direction | Client must reach the server, typically inbound to the OT network | All clients connect outbound to the broker |
| Footprint | Heavier stack, larger messages, session state | Very small client libraries, 2-byte minimum header |
| Security | Application certificates, sign and encrypt, user tokens | TLS on the transport, username/password or client certificates, broker-side authorisation |
| Write and method calls | Native: write variables, call methods | Possible via command topics, but by convention |
| Cloud and IT reach | Limited native support in cloud platforms | Supported by virtually every IoT platform and language |
| Typical home | PLCs, CNCs, SCADA, MES on the plant network | Edge gateways, cloud apps, dashboards, mobile, constrained devices |
OPC UA also has a PubSub extension (Part 14) that can use MQTT as its transport. That blurs the line considerably and is covered in our article on OPC UA PubSub over MQTT. This comparison focuses on classic client/server OPC UA because that is what most installed equipment exposes today.
Information Modeling: OPC UA's Big Advantage
OPC UA's strongest feature is semantics. A server can say "this is a variable called SpindleTemperature, it is a Double, its unit is degrees Celsius, its range is 0 to 120, and it belongs to an object of type MachineToolType." Companion specifications go further and define standard models for whole machine classes, so two vendors' injection moulding machines can look the same to a client.
MQTT has none of this out of the box. A payload of 47.3 on a topic is just bytes. Teams compensate in three ways:
- Topic conventions such as an ISA-95 hierarchy, so the path itself carries context. Our guide to ISA-95 MQTT topics shows a practical layout.
- Self-describing JSON with value, unit, quality and timestamp in every message.
- Sparkplug B, which adds a defined payload, birth and death certificates and metric metadata on top of MQTT.
If rich modeling is non-negotiable for a use case, for example an MES reading recipes and calling methods on a machine, OPC UA is the natural fit.
Communication Pattern: Sessions vs Decoupling
With classic OPC UA, every consumer opens a session with every server it needs. Ten applications reading from fifty machines can mean hundreds of sessions, each consuming memory on PLCs that were never sized for it. Adding a new consumer means touching firewall rules and server configuration.
With MQTT, each machine or gateway publishes once to the broker, and any number of consumers subscribe. Adding a new dashboard or analytics job touches nothing on the plant floor. This decoupling is the core reason MQTT became the backbone of the Unified Namespace pattern.
The flip side: MQTT puts the broker in the critical path. If it is down, nothing flows, so broker availability, monitoring and capacity become operational concerns. That is one reason many teams choose a fully managed MQTT service instead of running brokers themselves.
Security Models
Both protocols can be secured well, and both can be deployed insecurely.
OPC UA security is application-level: each client and server has an X.509 application instance certificate, and the session can be signed, or signed and encrypted. User authentication is layered on top. The common operational pain is certificate trust management across dozens of devices.
MQTT security is mostly transport and broker-level: TLS for encryption, credentials or client certificates for authentication, and broker-side rules for what each client may do. The architectural advantage is direction. Because every MQTT client connects outbound to the broker, you do not open inbound ports into the OT network. Our MQTT security best practices article lists the essentials.
Cloud Connectivity
This is where the comparison is most lopsided. Cloud services, web apps, mobile apps and data tools almost universally speak MQTT, HTTP or both. Very few speak OPC UA client/server natively, and exposing an OPC UA server directly to the internet is a bad idea. MQTT's small footprint, tolerance of flaky links, keep-alives and Last Will messages were designed for exactly this kind of remote, intermittent connection.
The Pattern Most Plants Use: OPC UA at the Edge, MQTT to the Cloud
In practice the question is rarely "OPC UA or MQTT", but "where does each one go". The pattern you see again and again:
Level 0-2 Machines and PLCs -> OPC UA servers (native or via drivers)
Level 2-3 Edge gateway -> OPC UA client: subscribes to tags
-> maps nodes to a topic hierarchy, adds units and quality
Level 3-4 MQTT broker -> single hub (Unified Namespace)
Level 4+ Consumers -> dashboards, historian, MES, analytics, cloud apps
The gateway keeps OPC UA's semantics where the machines live and translates them into a topic structure and payload format that everything else can consume. Our tutorial on building an OPC UA to MQTT gateway walks through a working Python implementation that publishes to a broker over TLS.
You can see what the MQTT side of that pattern looks like in seconds. This command publishes an OPC UA-derived value, with its context, to the public test broker:
mosquitto_pub -h broker.connectmq.com -p 1883 -i opcua-vs-mqtt-5d2e \
-t "connectmq/demo/5d2e/plant1/line1/cnc1/spindle_temp" -r -q 1 \
-m '{"value":47.3,"unit":"degC","quality":"Good","source":"ns=2;s=Line1.CNC1.SpindleTemp"}'
Any subscriber to connectmq/demo/5d2e/# now receives it, without knowing anything about OPC UA.
Decision Checklist
Use this list to decide per use case, not per plant:
- A client needs to browse, write setpoints or call methods on a machine? Use OPC UA client/server.
- Many consumers need the same data, some outside the plant network? Publish it to MQTT.
- Devices are constrained (microcontrollers, battery sensors) or on cellular links? MQTT.
- You need vendor-neutral machine models with standard semantics? OPC UA and its companion specifications; carry the semantics into MQTT payloads if you bridge.
- You want a Unified Namespace? MQTT as the hub, with OPC UA feeding it at the edge.
- You cannot open inbound firewall ports? MQTT's outbound-only connections fit.
- You need deterministic, low-latency control between controllers? Neither of these is the right tool for hard real-time control; use the fieldbus designed for it.
Where ConnectMQ Fits
ConnectMQ is the MQTT side of this architecture: a managed broker supporting MQTT 3.1.1 and 5.0 over TCP, TLS and WebSockets. It does not speak OPC UA itself, and that is by design; your edge gateway handles OPC UA and publishes MQTT to it. ConnectMQ detects ISA-95 and Unified Namespace topics, shows them in a live topic explorer and a devices view organised by ISA-95 levels, and can decode Sparkplug B payloads if your gateway uses that format. For an overview of the full stack, see our industrial IoT with MQTT guide.
Get Started with ConnectMQ
Try the edge-to-cloud pattern without installing a broker. Sign up at app.connectmq.com on the free Serverless plan (no credit card), create a broker, and point your OPC UA gateway at it with the generated credentials. You will have plant data flowing to a private MQTT broker in the cloud the same afternoon.
Frequently Asked Questions
Is MQTT replacing OPC UA?
No. MQTT is replacing point-to-point integrations above the plant floor, while OPC UA remains the standard way many machines expose structured data. Most architectures use both.
Is OPC UA or MQTT more secure?
Both are secure when configured correctly. OPC UA secures sessions with application certificates; MQTT relies on TLS and broker authentication, with the advantage that clients only make outbound connections.
Can OPC UA use MQTT directly?
Yes. OPC UA Part 14 PubSub defines MQTT as a transport with JSON or binary UADP encodings, so OPC UA publishers can send messages through a standard MQTT broker.
Which is better for a Unified Namespace, OPC UA or MQTT?
MQTT is the usual hub for a Unified Namespace because of its publish/subscribe decoupling. OPC UA servers typically feed that namespace through edge gateways.
