MQTT and OPC UA are not competing solutions in a brownfield plant; MQTT efficiently moves messages while OPC UA defines what industrial data means, and most retrofits run them together rather than picking a side [S1].
The framing of the question is itself the first error: MQTT is a publish/subscribe messaging transport (originally designed in 1999 for satellite oil pipeline SCADA telemetry), and OPC UA is a 37-part information-modeling standard released in 2008, so a head-to-head substitution is a category mistake [S1][S5].
What OPC UA Actually Carries That MQTT Does Not
OPC UA carries structured, typed information in an address space: every node has a NodeId, a NodeClass (variable, object, method, or type), typed attributes (value, data type, timestamp, quality), and typed references to other nodes, which is why a Siemens PLC, a Beckhoff IPC, and a Linux Python script can exchange semantically identical data without proprietary middleware [S5].
MQTT, by contrast, has no concept of data types; a payload of 72.4 could be Celsius, Fahrenheit, or an error code, and topic namespaces are conventions rather than specifications, so factory/line3/temp and factory/line3/temperature are unrelated topics with no semantic link [S1]. MQTT defines three QoS levels (0 at-most-once, 1 at-least-once with possible duplicates, 2 exactly-once via a 4-way handshake) and a 2-byte fixed header that lets a temperature reading fit in under 50 bytes, which is why it excels on cellular and battery-powered sensor links [S1].
The information-model gap is the disqualifier for replacement: an MES pulling from a pressure transmitter or a flow meter needs units, range, calibration date, and a quality code, not just a number on a topic, and those semantics are part of what OPC UA is for [S4][S5].
Brownfield Reality: Legacy Fieldbuses, Gateways, and Mixed Vendors
Brownfield sites are heterogeneous by definition: a 1990s Modbus RTU skid, a 2005 Profibus PA valve manifold, a 2012 Ethernet/IP PLC, and a 2020 OPC UA server all coexist, and digital-transformation projects must integrate them rather than rip them out [S4].
On a brownfield floor, MQTT is almost never present on the end device: an EIP or Modbus sensor still talks its native protocol, and an edge gateway or broker merely republishes the tag values, which means MQTT has not replaced Modbus, it has moved the tag-creation work to the edge, and the integrator loses SCADA-grade tooling for rapid tag development [S3]. The pattern that holds in production is OPC UA at the machine layer for structured machine-to-machine communication, MQTT as the lightweight pub/sub transport up to the cloud, and the two glued at the edge.
For brownfield retrofit work the practical decision tree is: if you need typed data, alarms, methods, historical access, and discovery, run OPC UA directly on the PLC or expose legacy tags through an OPC UA server; if you need to push high-frequency, small payloads from many constrained sensors up to a cloud broker, add MQTT on top, ideally with the OPC UA information model preserved end to end [S2][S4].
Three Integration Patterns That Actually Work
Pattern 1, native OPC UA: modern PLCs from Siemens, Rockwell, and Beckhoff expose OPC UA servers with companion specifications for industry verticals, and the MES, SCADA, or HMI consumes the address space directly over TCP or HTTPS on the local network [S5].
Pattern 2, OPC UA Pub/Sub over MQTT (Part 14 of the spec): OPC UA adds a publish/subscribe model where the publisher sends NetworkMessages to a broker, retaining the OPC UA information model and gaining MQTT's lightweight transport, which is the cleanest way to bridge an OT address space up to an AWS IoT Core, Azure IoT Hub, or GCP broker without losing semantics [S5][S7].
Pattern 3, gateway or bridge: a dedicated OPC UA-MQTT gateway or industrial edge node reads from a Modbus/Profibus/EIP device, maps registers into a tag database, and either publishes raw MQTT topics or models them as OPC UA nodes before publishing, which is the only viable route when the brownfield asset cannot be modified [S6][S8]. The same comparison logic shows up in adjacent selection work, for example Calibration Management Software and Connected Instruments: What 2026 Specs Actually Demand, where the connective layer between legacy instruments and modern software is the same OPC UA plus MQTT split.
Criteria Comparison: OPC UA, MQTT, and OPC UA Pub/Sub over MQTT
On data modeling, OPC UA exposes an extensible, object-based address space with NodeClasses, attributes, and references; MQTT carries opaque, untyped payloads; OPC UA Pub/Sub over MQTT preserves the OPC UA model while using an MQTT broker as the transport [S1][S4][S5].
On connection model, OPC UA is client-server (1:1 or 1:n, ideal for HMI/SCADA/MES/diagnostics on the local network), MQTT is publisher-broker-subscriber (designed for 1-to-many fan-out to cloud and many-to-one telemetry aggregation), and OPC UA Pub/Sub over MQTT inherits MQTT's fan-out [S4][S5].
On security, OPC UA includes built-in encryption, authentication, certificates, and user authentication mechanisms; MQTT security depends on the broker and is typically delivered by external TLS plus broker ACLs; OPC UA Pub/Sub over MQTT layers the OPC UA security model on top of MQTT's transport security [S4][S5].
On overhead, MQTT's 2-byte fixed header and sub-50-byte typical payload beat OPC UA TCP for low-bandwidth cellular links, while OPC UA's per-session and per-message overhead is acceptable on a plant LAN and buys you discovery, alarms, methods, and historical access that MQTT simply does not provide [S1][S5].
Latency, Reliability, and AI Pipeline Fit
MQTT with QoS 0 or QoS 1 in a well-tuned broker commonly lands in the sub-50 ms range per hop, which is fast enough for real-time AI inference at the machine level, and is the reason MQTT has become the default cloud transport for IIoT telemetry [S2].
For brownfield control loops that need deterministic behavior (a closed-loop command to an industrial valve, a safety interlock on a pressure sensor), OPC UA client-server or Pub/Sub on the local network is the right layer, and using MQTT end to end for control is generally a misapplication because the protocol does not carry methods, write semantics, or quality codes in a way a safety PLC can trust [S4][S5].
For AI-ready data pipelines, the working pattern in 2026 is: OPC UA at the source for typed, semantically rich tags (units, ranges, engineering code, condition state), MQTT or OPC UA Pub/Sub over MQTT for transport to a historian or cloud, and Spark/Kafka/whatever at the analytics layer; the OPC Foundation has 850+ registered members and the industrial AI market reached $43.6B in 2024 growing at roughly 23% CAGR, both of which point to OPC UA as the de facto interoperability standard at the data-modelling layer even when MQTT dominates the transport [S2].
When MQTT-Only Looks Tempting and Why It Usually Fails
The seductive brownfield pitch is: "drop an MQTT broker on the plant, have every sensor publish to a topic, and ship everything to the cloud", and the reality check is that you still need a tag dictionary, units, calibration data, and a quality flag, and somebody has to build and maintain that dictionary somewhere, which is the role OPC UA is engineered to fill [S1][S4].
The longer-running skeptic position from experienced integrators holds that MQTT will not take off and replace the various protocols like EIP or Modbus on end devices, because a gateway just moves tag creation from the SCADA to the edge where you lose the rapid-development tools and where bandwidth is no longer the binding constraint, so MQTT alone tends to lose out to native polling for everyday industrial systems [S3].
Two further constraints bite brownfield MQTT-only designs: the broker is a single point of failure unless you architect clustering separately, and discovery mechanisms must be implemented externally because subscribers must know exact topic names in advance or use wildcards and filter messages client-side [S1].
Who MQTT-Only Is For, and Who It Is Not
MQTT-only is appropriate for greenfield sensor nets where payload semantics are simple, every reading is a number with a timestamp, consumers are analytics and dashboards rather than control, and there is no installed base of OPC UA-aware SCADA to integrate with; a battery-powered vibration sensor publishing to a cloud broker is the canonical case [S1][S2].
MQTT-only is not appropriate for a brownfield plant that already runs a SCADA, an MES, an HMI population, or any safety instrumented function, because you lose discovery, methods, alarms, historical access, and the type system those systems depend on; for those plants, OPC UA remains mandatory, and MQTT (or OPC UA Pub/Sub over MQTT) is added as a transport extension rather than a replacement [S4][S5][S6].
Selection Criteria for the Brownfield Retrofit
Spec by need, not by ideology: list the existing fieldbuses and their exposure, the consumers (HMI, SCADA, MES, cloud, ML pipeline), the latency budget per hop, the security perimeter, the tag count, and the historian access pattern, then map each requirement to a layer [S6].
If the answer is "everything must reach the cloud and feed an AI model", you still need OPC UA at the edge to keep semantics intact; if the answer is "I just need to read 200 temperatures from remote skids over cellular", MQTT to a broker with a small schema document is enough [S1][S2].
Track the two signals that matter in 2026: how many of your brownfield assets already speak OPC UA natively (Siemens, Rockwell, Beckhoff, ABB all ship it), and whether your cloud platform (AWS IoT Core, Azure IoT Hub, GCP) supports OPC UA Pub/Sub over MQTT with broker-side schema enforcement, because that combination is the path that preserves semantics without forcing a forklift upgrade [S2][S5][S7].