OPC UA started life as a request-and-response protocol: a client connects to a server, opens a session, and subscribes to the tags it wants, and the server sends updates back over that connection. That client-server model is excellent for a controlled point-to-point conversation, but it does not naturally fan data out to many consumers or push telemetry into the cloud. To address that, OPC UA gained a second communication model, PubSub, which publishes messages to many subscribers at once without a per-consumer session, either directly over the network or through a message broker such as MQTT. This guide contrasts the two models, explains where each fits, and shows how PubSub lets OPC UA data flow into MQTT-based cloud pipelines.
OPC UA PubSub vs Client-Server in one line: OPC UA defines two communication models. The client-server model is request and response: a client establishes a session with a server, creates subscriptions with monitored items, and receives updates over that dedicated connection, which suits controlled point-to-point access. The PubSub model is publish and subscribe: a publisher sends messages, encoded as UADP or JSON, to many subscribers at once, either directly over UDP or through a message broker such as MQTT, with no session per consumer. Client-server fits interactive access and configuration where the client needs to browse and read on demand, while PubSub fits one-to-many, decoupled, cloud-friendly telemetry distribution.
In the client-server model, communication is a direct conversation between one client and one server. The client connects to the server, establishes a secure session, and then browses the server's address space to find the nodes it cares about. To receive ongoing data, it creates a subscription and adds monitored items to it, one per variable it wants to watch, telling the server how often to sample each and how much a value must change before it is reported. The server then sends data-change notifications back to the client over the session whenever the monitored values meet those criteria. The whole exchange is stateful and tied to that one client's connection.
This model's strengths are control and interactivity. Because the client and server maintain a session, the client can do far more than just receive values: it can browse the full address space to discover what is available, read and write nodes on demand, call methods, and adjust its subscriptions on the fly. Security is negotiated per session, so access is authenticated and encrypted for that specific connection. This makes client-server ideal for tools that need to explore and interact with a server - engineering software, an HMI configuring itself, a client reading specific tags when asked - where the richness of the interaction matters more than broadcasting to many consumers.
The limitation is that everything is per-connection. Each client that wants data opens its own session and maintains its own subscriptions, so serving many consumers means many sessions, each consuming server resources. There is no built-in way to publish one stream that many independent consumers receive, and the client has to be able to reach and connect directly to the server, which is awkward across network boundaries and into the cloud. For interactive, one-to-one access this is exactly right, but for distributing the same telemetry to many destinations, or pushing it outward through firewalls to a cloud service, the session-per-client design becomes a constraint rather than a feature.
PubSub decouples publishers from subscribers so that data flows one-to-many without a session per consumer. A publisher packages the values it wants to send into a dataset message and publishes it, and any number of subscribers can receive that message, none of them needing an individual connection to the publisher. The publisher does not know or care who is listening; it simply publishes, and subscribers simply receive. This is a fundamentally different shape from client-server: instead of consumers pulling data over their own sessions, the source pushes messages that many consumers can pick up, which is what makes PubSub suited to broadcasting telemetry widely.
PubSub comes in two transport flavours that suit different situations. The brokerless form publishes messages directly onto the network, typically as UADP - a compact binary encoding - sent over UDP, often multicast, so that many subscribers on the same network receive the data with very low latency and no intermediary. This is well suited to fast, local, controller-to-controller or field-level distribution. The brokered form publishes messages to a message broker, most notably MQTT, encoding the payload as UADP or as JSON; the broker then delivers the messages to whichever subscribers have subscribed to the relevant topics. The brokered form trades a little directness for the reach, buffering, and flexibility that a broker provides.
The choice of encoding follows the transport and the consumer. UADP is compact and efficient, well matched to bandwidth-conscious or high-rate distribution, and it is the natural choice over UDP. JSON is more verbose but human-readable and trivially consumed by ordinary software, cloud services, and web tooling, which makes it attractive when the subscribers are IT systems rather than industrial devices. Publishing OPC UA data as JSON over MQTT, for instance, produces messages that a standard cloud ingestion pipeline can read without any OPC UA-specific code. This flexibility in encoding and transport is a big part of why PubSub is described as cloud-friendly, because it lets OPC UA meet consumers on the terms those consumers already understand.
Choosing between the two comes down to the shape of the data flow. Client-server fits when a consumer needs to interact with a server - browse its structure, read or write specific nodes, call methods, or tune subscriptions - and when the relationship is essentially one client to one server. It is the right model for engineering tools, for an HMI pulling specific values, and for any case where discovery and on-demand access matter. PubSub fits when the same telemetry needs to reach many consumers, when publisher and subscriber should be decoupled so neither depends on the other being present, and when data has to travel outward to the cloud, which is precisely the telemetry-distribution problem client-server handles awkwardly.
The two are not rivals so much as complements, and many systems use both: client-server for configuration and interactive access, PubSub for high-volume, one-to-many telemetry streaming. A device might expose a full client-server interface for an engineer to browse and configure it, while simultaneously publishing its live values via PubSub to a broker for everyone else to consume. Understanding which model suits which job avoids the mistake of forcing one to do the other's work, such as opening a session per cloud consumer when a single published stream would serve them all, or trying to browse and configure over a fire-and-forget PubSub feed.
The bridging into MQTT pipelines is where PubSub becomes especially valuable for cloud monitoring, because it lets OPC UA data enter the same MQTT-based world that so much modern telemetry already lives in. When OPC UA PubSub publishes to an MQTT broker, its messages sit alongside every other MQTT topic, and any consumer that can subscribe to MQTT can receive them, including a cloud ingestion service that knows nothing about OPC UA sessions. A cloud SCADA platform such as Merobix, which ingests from MQTT, can therefore receive OPC UA data through the broker just as it receives any other publisher's telemetry, decode the UADP or JSON payloads, and store them. For field operations, this means OPC UA sources can feed a cloud platform over standard MQTT without every consumer maintaining its own OPC UA client session, which is the decoupled, cloud-friendly path that PubSub was designed to enable.
Client-server is a stateful request-and-response conversation: a client opens a session with a server, creates subscriptions with monitored items, and receives updates over that dedicated connection, which suits browsing, reading, writing, and interactive access one client at a time. PubSub is publish-and-subscribe: a publisher sends messages to many subscribers at once with no session per consumer, either directly over UDP or through a broker such as MQTT, which suits one-to-many telemetry distribution and cloud delivery. Client-server excels at interaction and control; PubSub excels at decoupled, scalable data distribution.
They are the two encodings PubSub can use for its messages. UADP is a compact binary encoding, efficient for bandwidth-conscious or high-rate distribution and the natural choice when publishing directly over UDP. JSON is more verbose but human-readable and easily consumed by ordinary software, cloud services, and web tooling, which makes it attractive when subscribers are IT systems rather than industrial devices. Publishing as JSON over MQTT, for example, produces messages a standard cloud ingestion pipeline can read without any OPC UA-specific code.
In its brokered form, PubSub publishes its messages to a message broker, and MQTT is a common choice, encoding the payload as UADP or JSON on MQTT topics. Once the OPC UA data is on the broker, it sits alongside every other MQTT topic, so any consumer that can subscribe to MQTT can receive it, including a cloud ingestion service that knows nothing about OPC UA sessions. This lets OPC UA sources feed cloud pipelines over standard MQTT without each consumer maintaining its own OPC UA client connection, which is the decoupled, cloud-friendly flow PubSub was designed for.
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.