MQTT vs. OPC UA: Which Protocol Should You Use?

Short answer: MQTT and OPC UA solve different problems, so “which one” is usually the wrong question. OPC UA is a semantic framework built for plant-floor interoperability. It defines not just how data moves but what it means. MQTT is a lightweight transport protocol built for moving that data efficiently at scale, especially from constrained field devices to the cloud. Most production industrial architectures use both: OPC UA where systems need to agree on meaning, MQTT where bandwidth and scale matter most, and OPC UA PubSub or Sparkplug B where both requirements overlap.

What MQTT Actually Does

MQTT (Message Queuing Telemetry Transport) is a lightweight publish/subscribe messaging protocol. Devices publish data to named topics, a broker routes it, and any number of subscribers receive it, without publishers and subscribers ever connecting to each other directly. That decoupling, combined with a minimal protocol header, is what makes MQTT practical for thousands of remote sensors reporting over cellular or satellite links where bandwidth is scarce and connections are unreliable.

MQTT defines how messages move. It says nothing about what the payload means. Two MQTT clients can both speak the protocol correctly and still disagree on how to structure the data inside a message. That’s a deliberate simplicity trade-off, not an oversight, and it’s the reason specifications like Sparkplug B exist on top of it.

For the full picture of MQTT’s architecture, topic structure, and QoS levels, see our guide.

CTA: What Is MQTT? Architecture, QoS, and Industrial Use Cases

What OPC UA Actually Does

OPC UA (OPC Unified Architecture) is a platform-independent standard for industrial interoperability. Where MQTT is intentionally minimal, OPC UA is comprehensive: it defines a structured information model so that when a client connects to a server, it can discover what data is available, what it means, and how it relates to other data, automatically, without manual mapping between vendors.

OPC UA was also built with security as a core requirement rather than a layer added afterward. Every session operates within a certificate-based authentication and encryption framework baked into the specification itself.

Originally a client/server protocol, OPC UA added a publish/subscribe model (OPC UA PubSub) in Part 14 of the specification, which can run over MQTT, AMQP, or UDP multicast; a detail that matters a lot for how these two protocols relate to each other, covered below.

For the full picture of OPC UA’s architecture, security model, and OPC Classic comparison, see our guide:

CTA: What Is OPC UA? The Complete Guide for Industrial Automation.

The Core Difference: Transport Layer vs. Semantic Framework

The comparison that trips people up is treating MQTT and OPC UA as if they compete for the same job. They don’t sit at the same layer of the stack.

MQTT answers: how do I move this message from a publisher to every interested subscriber, using as little bandwidth as possible? It has no opinion on payload structure, that’s left entirely to whoever designs the topic and message format.

OPC UA answers: what does this piece of data mean, what type is it, how does it relate to other data, and can I trust the system sending it to me? It has a strong opinion on all of that, expressed through its information model and built-in security.

That’s why framing this as “MQTT vs. OPC UA” is often a category error in the first place; like comparing a delivery truck to a shipping manifest. One moves things, the other describes what’s being moved and why it matters. In practice, they’re frequently used together for exactly that reason.

MQTT vs. OPC UA: Side-by-Side Comparison

When to Use MQTT

MQTT is the right choice when the priority is moving data efficiently across constrained, distributed, or high-device-count environments:

• Remote monitoring of assets that are impractical to poll continuously: pipelines, offshore equipment, remote pumping stations
• Edge-to-cloud telemetry feeding dashboards, analytics platforms, or a data lake
• High-device-count deployments where a broker’s fan-out model scales better than point-to-point polling
• Environments with intermittent or bandwidth-constrained connectivity, where MQTT’s small header and change-based publishing matter

When to Use OPC UA

OPC UA is the right choice when the priority is interoperability and trustworthy semantics between industrial systems that need to understand each other’s data, not just receive it:

• Plant-floor communication between PLCs, SCADA, and MES systems from different vendors
• Any environment where security has to be part of the connection itself, certificate-based trust, not bolted-on TLS
• Applications that need OPC UA’s rich data typing, historical data access, or alarm and event models
• Systems that must discover what data is available and what it means without manual configuration

When to Use Both: OPC UA PubSub and Sparkplug B

In most real deployments, the choice isn’t MQTT or OPC UA, it’s how to combine them. Two approaches dominate:

OPC UA PubSub over MQTT transports OPC UA’s structured, typed information model using MQTT as the underlying transport. You get OPC UA’s semantics and security model with MQTT’s lightweight, broker-based delivery – useful when a cloud platform or downstream consumer needs to understand OPC UA data without a full OPC UA client/server connection.

MQTT Sparkplug B takes the opposite direction: it standardizes MQTT’s payload structure and adds session/state awareness (birth and death certificates for devices coming online or dropping off) so that any Sparkplug-compliant system can interpret the data consistently, without OPC UA in the picture at all.

Which one fits depends on whether OPC UA is already present on the plant floor. If it is, OPC UA PubSub over MQTT extends that existing investment to the cloud. If the environment is MQTT-native from the start, Sparkplug B solves the interoperability gap without introducing OPC UA as a dependency.

See Combining MQTT Sparkplug and OPC UA for a deeper look at how the two standards work together, and OPC UA Security: The Complete Guide for Industrial Cybersecurity Teams for how OPC UA’s certificate-based model compares to MQTT’s transport-level TLS.

Where MQTT and OPC UA Each Fit

CTA: See MQTT Universal Broker in Action

Decision Framework: Choosing by Architecture Layer

Rather than picking one protocol for an entire architecture, match the protocol to what each layer actually needs:

How Integration Objects Bridges MQTT and OPC UA

Most plant-floor data doesn’t originate in either protocol natively, it comes from OPC Classic servers, Modbus devices, or proprietary PLCs, and something has to translate it before an OPC UA or MQTT architecture can consume it. That translation layer is where the theoretical “use both” answer runs into a practical infrastructure problem.

Integration Objects’ IT/OT integration platform, addresses both sides of that gap. Its MQTT Universal Broker module converts OPC UA, OPC Classic, Modbus, DNP3, SNMP, and other industrial protocols into a single MQTT or Sparkplug B stream, with TLS/SSL security and a rule engine for transforming raw data before it reaches the cloud. On the OPC UA side, the OPC UA Universal Server and OPC UA Client Connectors handle the plant-floor interoperability layer, so the same architecture can serve both a local SCADA system and a cloud analytics platform from one data source.

CTA: Download MQTT Universal Broker for Free

Frequently Asked Questions