OPC UA vs MQTT — when to use what in industrial IoT

If you're building an industrial IoT architecture in 2026, you've probably asked the question: should I use OPC UA or MQTT? The internet is full of tribal answers — OPC UA people say "OPC UA", MQTT people say "MQTT." Neither answer is helpful.

Here's the real answer, from an engineering team that has shipped both in production: they solve different problems, and most serious architectures use both.

The one-sentence difference

OPC UA gives your data a structure and meaning. MQTT moves bytes from A to B.

That's it. OPC UA is an information model plus a transport. MQTT is a transport only. Everything else follows from this distinction.

Where each protocol wins

OPC UA: rich data semantics

OPC UA defines a type system for industrial data — data types, relationships, units, ranges, access rights. A pump isn't just a floating-point number; it's a pump with a flow rate in liters per minute, an operational state, an alarm threshold, and a maintenance schedule. This semantic richness is what makes OPC UA interoperable between vendors without custom mapping.

MQTT: lightweight publish-subscribe

MQTT was designed for constrained devices and unreliable networks. A tiny client, a simple topic string, QoS levels, and a broker in the middle. It's excellent at moving telemetry from sensors to a cloud platform with minimal overhead. But MQTT topics are just strings — the protocol has no opinion on what the data means.

OPC UA: built-in security model

OPC UA includes X.509 certificate-based authentication, encryption, signing, and role-based access control as part of the specification. Security is not optional — it's the default. This matters when your system needs to comply with IEC 62443 or the Cyber Resilience Act (CRA).

MQTT: broker simplicity

An MQTT broker is trivial to deploy and operate. Mosquitto runs on a Raspberry Pi. Cloud providers (AWS IoT Core, Azure IoT Hub, HiveMQ Cloud) offer managed brokers with millions of connections. The operational simplicity is unmatched for pure telemetry use cases.

The comparison table

When to use OPC UA

Use OPC UA when the consumer needs to understand the data, not just receive it.

SCADA and MES integration. Your supervisory system needs to browse the data model, read process values with engineering units, call methods on the PLC, and subscribe to alarms. This is OPC UA's home turf.

Vendor-neutral interoperability. You're connecting machines from different vendors and need a shared semantic model. Companion Specifications like PackML, Euromap 77/83, and PADIM provide industry-standard models that vendors share.

Brownfield modernization. You want to expose legacy PLCs (Siemens S7, Modbus, EtherNet/IP) through a single, standardized interface without rewriting firmware.

Compliance. IEC 62443, NIS2, or the CRA require documented security and traceability. OPC UA's built-in security model provides this out of the box.

When to use MQTT

Use MQTT when you need lightweight, scalable data movement and the consumer already knows what the data means.

Sensor-to-cloud telemetry. Thousands of sensors pushing small payloads to a cloud platform for storage and analytics.

Constrained devices. Microcontrollers and low-power devices where the OPC UA stack overhead is too high.

Event-driven microservices. Decoupled services communicating through a message broker.

Mobile and web dashboards. MQTT over WebSockets is well-supported in JavaScript and browser environments.

When to use both: OPC UA PubSub over MQTT

This is the pattern most production architectures are converging on in 2026. OPC UA PubSub lets you publish OPC UA data — with full semantics, types, units, and structure — over an MQTT broker as the transport layer.

At the edge, an OPC UA server connects to PLCs and sensors, exposes a structured address space, and serves local SCADA and engineering tools via the standard Client/Server model. The same edge server then publishes selected data as OPC UA PubSub messages to an MQTT broker — preserving the data model while leveraging the broker's scalability and cloud integration.

This "best of both worlds" pattern gives you:

• Semantic data at every layer — consumers in the cloud receive typed, structured OPC UA data, not opaque JSON blobs.
• Broker scalability — millions of connections, managed cloud services, QoS.
• One source of truth — the OPC UA information model is the single data definition, whether consumed via Client/Server or PubSub.

The mistake most teams make

The most common architectural mistake we see: using MQTT as the only protocol and reinventing the information model in JSON payloads.

What happens in practice:

1. Team A defines a JSON schema for pump telemetry.
2. Team B defines a different JSON schema for the same pump.
3. Six months later, nobody knows which field is the flow rate and which is the pressure.
4. Someone writes a "data dictionary" spreadsheet to map field names.
5. The spreadsheet is always out of date.

OPC UA solves this by design. The information model is the contract between producer and consumer. Companion Specifications provide industry-standard models that vendors share — no spreadsheet required.

Bottom line

Stop asking "which one?" Start asking "which one where?"

We're the creators of node-opcua and the team behind Omni-Edge — the OPC UA server that publishes PubSub over MQTT out of the box. If you need help designing your OPC UA + MQTT architecture, talk to our engineers.