OPC UA vs MQTT: Which One to Choose to Connect Your Plant

OPC UA and MQTT do not compete: they solve different layers. OPC UA is the standard for reading data from machines and PLCs inside the plant, with a rich information model and built-in security. MQTT is the lightweight transport protocol for moving that data to the cloud and between systems. The usual architecture uses both: OPC UA for machine access, MQTT for distribution.

Why "OPC UA vs MQTT" is usually the wrong question

The question comes up constantly in industrial connectivity projects, and it almost always hides a confusion of layers. OPC UA and MQTT occupy different places in the architecture: one defines what the data is (an information model with types, units, hierarchies and semantics) and the other defines how it travels (a publish and subscribe transport designed for unreliable networks). Comparing the two as mutually exclusive alternatives is like comparing a language with a courier service: they can be used together, and in fact that is the norm.

That said, the question has a legitimate version: on each specific leg of the architecture (PLC to gateway, gateway to cloud, between applications) you do have to choose a mechanism, and there it pays to understand the strengths of each. This article walks through that decision leg by leg, with a comparison table of criteria and use cases by plant size.

What each protocol solves

OPC UA (IEC 62541) was born to unify access to automation data. Its central value is the information model: an OPC UA server does not expose numbered registers but a navigable address space, with typed nodes, engineering units, object hierarchies and metadata. The client can discover what the server offers without external documentation. It includes security as standard (certificate-based authentication, per-channel signing and encryption), subscriptions with deadband, historical reads, alarms and callable methods. It is the de facto standard for talking to PLCs, CNCs and modern equipment inside the OT network.

MQTT was born at the other extreme: telemetry over expensive, unstable links. It is deliberately minimal: a central broker, clients that publish and subscribe to hierarchical topics, three QoS levels, persistent sessions and the last-will mechanism for detecting disconnections. It imposes no payload format: the content of the message is the publisher's responsibility. That lightness is its strength (it works the same with ten clients as with ten thousand, and it crosses firewalls with a single outbound connection) and also its gap: without a topic and payload convention, every integration invents its own. Sparkplug B exists precisely to fill that gap with a standard convention on top of MQTT.

Comparison table: OPC UA versus MQTT

When OPC UA makes sense

OPC UA is the natural choice in these scenarios:

• Access to modern machines and PLCs. If the equipment already exposes an OPC UA server, it is the richest and most maintainable way to read it: the information model avoids the work of mapping raw registers and documenting them separately. It is the central scenario of PLC connectivity.
• Machine-to-machine communication inside the plant, where the local network is reliable and semantics matter: a cell querying the state of the previous one, a quality system reading process parameters.
• Environments with formal security requirements. OPC UA's certificate-based security is defined in the standard itself and is auditable, which matters in regulated sectors.
• When discovery adds value: integrators and systems that need to explore what data a machine offers without relying on external signal sheets.

When MQTT makes sense

• Sending plant data to the cloud. A single outbound connection, tolerance to outages, per-message QoS: it is exactly the problem it was designed for. Combined with local buffering at the gateway, it guarantees a gap-free historian (covered in the guide on industrial edge with buffering).
• Many consumers for the same data. The broker decouples producers from consumers: historian, dashboards, alerts and ERP subscribe without adding a single connection to the machine.
• Building a unified namespace: a common topic hierarchy for the whole organisation where every system publishes and consumes. It is the pattern we develop in the guide to the OT/IT unified namespace.
• Small devices and IIoT sensors where a full OPC UA stack does not fit or is not worth it.

The combined architecture: OPC UA below, MQTT above

The practical answer in most plants is not to choose but to combine. The reference pattern has three legs:

1. Machine to gateway: OPC UA (or the machine's native protocol: Modbus, S7 and so on). The gateway acts as an OPC UA client inside the OT network, where the heavy session is no burden and the information model earns its keep.
2. Gateway to broker: MQTT. The gateway normalises (structured names, engineering units, source timestamp) and publishes over MQTT at the appropriate QoS, with a single outbound connection that respects OT/IT segmentation.
3. Broker to consumers: MQTT. Historian, analytics, dashboards and business applications subscribe to the topics they need.

This pattern keeps the best of each protocol: the semantic richness of OPC UA where the data is generated and the robustness and decoupling of MQTT where it is distributed. It is the foundation of the OT/IT integration and MQTT integration projects we deliver at Captia Connect.

OPC UA over MQTT: when the information model travels through the broker

There is a third route that confuses many teams: OPC UA PubSub, defined in part 14 of the standard (IEC 62541-14). Instead of the classic client-server model, PubSub lets an OPC UA server publish its data over a publish and subscribe transport, and MQTT is one of the transports the specification covers. The publisher serialises the data (as JSON or in the binary UADP format) and sends it to an MQTT broker; subscribers consume it without opening a session against the machine. On paper, it combines the best of both worlds: the typed semantics of OPC UA travelling with the decoupling and scalability of MQTT.

In practice, expectations deserve tempering. PubSub adoption across the installed base is still uneven: many PLCs and machines that expose a classic OPC UA server do not publish over PubSub, and consuming tools vary in maturity. The subscriber also does not browse the address space the way a classic client would: it depends on the metadata the publisher emits alongside the data, so part of the discovery value shifts to the publisher's configuration. And you still need a well-governed MQTT broker, with the same decisions on topics, security and quality of service as in any MQTT deployment.

Our practical reading: OPC UA over MQTT does not invalidate the gateway pattern, it refines it. The real decision on the gateway-to-broker leg is not the transport (it will be MQTT either way) but the payload convention: documented custom JSON, Sparkplug B or OPC UA PubSub encoding. If your equipment and your target platform already speak PubSub, using it avoids translations; if not, a well-defined convention at the gateway delivers the same result today with less friction, and keeps the migration to PubSub open for when the ecosystem justifies it.

Use cases by company size

Small plant (one line, few machines)

With five or ten machines and an initial goal of visibility (counters, statuses, stoppages), the minimal architecture is a single gateway that reads over OPC UA or Modbus and publishes over MQTT to a managed broker in the cloud. Building intermediate infrastructure is not worth it: MQTT's simplicity lets you start with a historian and dashboards in weeks and grow later without redoing anything.

Mid-size plant (several lines, a mix of old and modern machines)

Here equipment with an OPC UA server coexists with veteran machines that only speak fieldbuses or hardwired signals. The useful pattern is a gateway per line or per area that unifies that heterogeneity: downwards, each native protocol; upwards, a single normalised MQTT topic space. The important decision stops being the protocol and becomes the naming convention and the quality of the published data.

Industrial group (several plants, corporate)

At multi-plant scale, MQTT delivers its biggest advantage: each plant publishes its signal tree to a broker (local, or corporate with bridges between them) and the corporate level consumes a homogeneous view of every factory without direct access to any OT network. OPC UA remains the standard for machine access inside each plant, and governance shifts to maintaining the common topic convention and the broker's security policies.

Frequently asked questions about OPC UA and MQTT

If you are deciding how to connect your plant, at Captia Connect we design this complete architecture: from PLC connectivity and edge ingestion to MQTT integration with your industrial data platform.