OPC UA and MQTT solve different halves of the same problem, and a bridge is what makes them cooperate. OPC UA is rich and structured but built around a client asking a server for data, while MQTT is lightweight and built around publishers pushing data to subscribers through a broker. Getting the structured world of OPC UA onto the loosely coupled world of MQTT is exactly what plants need when they want field data to flow outward to cloud and IIoT systems. This page explains how a bridge converts one paradigm into the other, how node identities become topics and metrics, and when to reach for OPC UA PubSub instead.
OPC UA to MQTT bridge in one line: An OPC UA to MQTT bridge is an edge component that reads data from an OPC UA server using its request/response model and republishes that data onto MQTT topics using the publish/subscribe model. It maps OPC UA node identifiers to an MQTT topic hierarchy and typically wraps the values as metrics, often following the Sparkplug B specification, so that cloud and IIoT systems can subscribe to plant data without speaking OPC UA. The bridge is how a polling protocol becomes a push protocol at the boundary between the plant network and the wider infrastructure.
The core job of the bridge is to reconcile two opposite communication styles. On the OPC UA side, the bridge acts as a client: it connects to a server, browses or is configured with the nodes it cares about, and then either polls those nodes on an interval or, more efficiently, creates a subscription so the server sends updates when values change. On the MQTT side, the bridge acts as a publisher: whenever it has a new value, whether from a poll cycle or a change notification, it publishes that value to an MQTT topic on a broker, where any number of subscribers can receive it. The bridge sits in the middle translating the pull into a push.
Using OPC UA subscriptions rather than raw polling is the more elegant approach and usually the right one. A subscription lets the bridge tell the server which nodes to watch and how often to sample them, and the server pushes only the changes, which the bridge then forwards to MQTT. This report-by-exception behavior keeps the MQTT stream carrying meaningful movement rather than a constant tick of unchanged values, and it reduces load on both the server and the network. Where a server does not support subscriptions well, the bridge falls back to timed reads, applying its own deadband so it does not republish values that have not meaningfully moved.
There is state to manage in this translation. MQTT has a retained-message feature, where the broker keeps the last value published to a topic so a new subscriber immediately gets the current value rather than waiting for the next update. A well-built bridge uses this so that consumers coming online see current plant state right away, and it also has to decide how to represent the quality and timestamp that OPC UA carries with every value, since a bare MQTT payload of just a number loses the context that makes the reading trustworthy. Carrying value, quality, and time through the bridge is what keeps the MQTT side as trustworthy as the OPC UA source.
OPC UA identifies every data point with a node ID, which is unique within a server and lives inside a browsable address space that reflects the structure of the equipment. MQTT, by contrast, organizes messages into a topic hierarchy, a slash-delimited path that publishers and subscribers agree on by convention. The bridge's mapping job is to turn each node ID into a topic path, and the quality of that mapping shapes how usable the MQTT side is. A thoughtful mapping encodes site, area, and measurement into the topic levels so subscribers can use wildcards to select broad or narrow slices, rather than producing opaque topics that mirror internal node numbering nobody outside the server understands.
This is where Sparkplug B often enters, because plain MQTT says nothing about payload format, leaving every integration to invent its own. Sparkplug B is a specification layered on MQTT that defines a standard topic structure and a metric payload format, including birth and death messages that announce when a device comes online or drops off, and a consistent way to carry value, data type, quality, and timestamp for each metric. A bridge that wraps OPC UA values as Sparkplug metrics produces a stream that any Sparkplug-aware consumer can interpret without custom parsing, which is a large part of why Sparkplug has become common for exactly this field-to-IIoT hop.
The mapping also has to handle the metadata that makes a value meaningful. Each OPC UA value arrives with a source timestamp and a status code indicating good, uncertain, or bad quality, and dropping those on the floor produces an MQTT stream of numbers with no way to tell a fresh reading from a stale one or a healthy value from a faulted sensor. Whether through Sparkplug's metric fields or a chosen JSON structure, the bridge carries the timestamp and quality alongside the value, so a downstream system can trust and time-align the data exactly as it could have if it had queried OPC UA directly.
A custom bridge is not the only way to get OPC UA data onto a publish/subscribe transport, because the OPC UA specification itself now includes a PubSub model. OPC UA PubSub extends the standard so that a server can publish data directly, including over MQTT, using OPC UA's own data model and, in some configurations, its own binary encoding, rather than requiring a separate client-server bridge to sit in between. Where the field equipment and the consuming systems both support OPC UA PubSub, it removes a moving part, because the data leaves the source already in a standardized OPC UA form on the wire.
The choice between a custom bridge and native PubSub comes down to what the endpoints support and how much control is needed over the mapping. Much installed equipment predates OPC UA PubSub or exposes only the classic client-server interface, in which case a bridge is the practical way to reach MQTT at all. A bridge also gives explicit control over the topic scheme and the payload format, which is exactly what a plant wants when it has committed to a particular convention such as Sparkplug and needs every source to conform. Native PubSub is attractive when the whole chain speaks it and the goal is to minimize custom components, but it is only an option when the source actually supports it.
In practice the bridge frequently lives inside a broader edge monitoring layer rather than as a standalone converter, and this is where a platform earns its place. A platform such as Merobix can read OPC UA servers across the plant, apply consistent naming and carry quality and timestamps through, and publish a clean MQTT or Sparkplug stream that cloud systems subscribe to, so the protocol conversion is one function of a layer that also gives operators a live view of plant state. Consolidating the bridge into that monitoring layer means the field-to-IIoT hop is handled with the same conventions everywhere, rather than each server running its own converter with its own idea of how topics should look.
The bridge acts as an OPC UA client that either polls nodes or, better, creates a subscription so the server pushes changes, and then republishes each new value to an MQTT topic where subscribers receive it. Using OPC UA subscriptions keeps the MQTT stream carrying meaningful changes rather than a constant tick of unchanged values. Where subscriptions are not available, the bridge falls back to timed reads with its own deadband.
Plain MQTT defines no payload format, so every integration would otherwise invent its own. Sparkplug B is a specification layered on MQTT that standardizes the topic structure and a metric payload carrying value, data type, quality, and timestamp, plus birth and death messages announcing when a device connects or drops. Wrapping OPC UA values as Sparkplug metrics produces a stream any Sparkplug-aware consumer can interpret without custom parsing.
Use native OPC UA PubSub when both the field equipment and the consuming systems support it, since it lets a server publish directly over a transport like MQTT using OPC UA's own data model and removes the separate bridge component. Use a custom bridge when equipment only exposes the classic client-server interface, or when you need explicit control over the topic scheme and payload format to conform to a convention like Sparkplug. Much installed equipment predates PubSub, so a bridge is often the only practical option.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.