MQTT Sparkplug vs OPC UA: Which IIoT Protocol Should You Use?

Quick Verdict

Criterion	MQTT Sparkplug B	OPC UA
Communication model	Pub/sub via broker	Client/server (+ PubSub extension)
Data model	Protobuf metrics payload	Rich information model (nodes, types)
Bandwidth efficiency	Very high — report-by-exception only	Moderate — polling or subscriptions
Semantic richness	Lightweight (name + value + timestamp)	Deep (engineering units, hierarchy, methods)
Security	TLS + broker ACLs	X.509 certificates, signed/encrypted sessions
Brownfield fit	Good — broker decouples legacy devices	Good — native on most modern PLCs/SCADA
Edge-to-cloud scale	Excellent for high-device-count telemetry	Excellent for plant-floor integration
Unified Namespace	Primary transport	Can run over MQTT (OPC UA PubSub)
Standards body	Eclipse Foundation (Sparkplug Working Group)	OPC Foundation (IEC 62541)
Learning curve	Low–medium	Medium–high

Short answer: Use Sparkplug B when you need lean, high-frequency telemetry from many edge nodes with minimal bandwidth. Use OPC UA when you need a semantically rich, queryable plant-floor data model with built-in security and method calls. In most greenfield IIoT architectures in 2026, you will use both.

---

Introduction

The debate over MQTT Sparkplug vs OPC UA surfaces in nearly every IIoT architecture conversation, and for good reason — both protocols solve real problems, but they solve different problems. Vendor documentation tends to be biased toward whichever product the author sells, and most comparison articles online have not been updated since before the Sparkplug B specification reached its 3.0 milestone or before OPC UA PubSub became widely supported in commercial products.

This guide takes a vendor-neutral position. It explains exactly what each protocol does well, where each falls short, and — critically — why the most capable industrial architectures in 2026 deploy both together rather than treating this as an either/or choice.

If you are already familiar with OPC UA fundamentals, the full OPC UA tutorial covers architecture, security, and hands-on setup in detail. For background on PLC-level connectivity, the IIoT PLC integration guide and the broader PLC communication protocols overview provide useful context.

---

Communication Model: Pub/Sub Broker vs Client/Server

How MQTT Sparkplug B communicates

MQTT is a publish-subscribe protocol. Devices publish messages to a broker (such as HiveMQ, EMQX, or Mosquitto), and any number of subscribers receive those messages without knowing the publisher's address. Sparkplug B is a specification layered on top of MQTT 3.1.1 (and now MQTT 5) that adds:

• A defined topic namespace (spBv1.0/<group_id>/<message_type>/<edge_node_id>/<device_id>)
• A defined payload format using Google Protocol Buffers (Protobuf)
• A session lifecycle — BIRTH, DATA, DEATH, and COMMAND message types that allow consumers to reconstruct full device state at any time

The broker is the hub of all communication. Edge nodes (typically an IIoT gateway or a PLC with a Sparkplug-capable runtime) connect outbound to the broker over TCP/TLS. This is firewall-friendly because the connection is always initiated from the edge, never inbound from an external system.

How OPC UA communicates

OPC UA's primary model is client/server. An OPC UA server (running on a PLC, gateway, or SCADA system) exposes a node-based address space. OPC UA clients connect to the server, browse the address space, read/write nodes, and set up monitored items and subscriptions for change notification.

OPC UA also defines a PubSub extension (Part 14 of IEC 62541) that allows OPC UA information to be published over MQTT, UDP multicast, or AMQP without a persistent connection. This is discussed in the "It's Not Either/Or" section below.

The key architectural difference: in MQTT Sparkplug, the broker holds the routing state. In OPC UA client/server, the server holds the data state, and clients must connect directly to query it.

---

Data and Semantic Model

Sparkplug B: Metrics payload

A Sparkplug B DATA message carries a list of metrics. Each metric has a name, a datatype (int32, float, string, dataset, etc.), a timestamp, and a value. Metrics can also carry properties (engineering units, min/max limits) but there is no mandatory schema — the structure is whatever the edge node publishes.

This is intentionally lightweight. A PLC scanning a 100-tag program can publish only the tags that changed since the last scan, with microsecond timestamps, in a Protobuf binary payload that is typically a fraction the size of an equivalent XML or JSON message. For high-frequency telemetry — vibration, temperature, flow rates — this matters significantly.

The tradeoff is that semantic context lives in the topic path and metric name, not in a queryable information model. A historian or analytics platform receives raw name-value-timestamp tuples and must apply its own context.

OPC UA: Information model

OPC UA defines a rich, hierarchical address space composed of nodes with defined node classes: Objects, Variables, Methods, ObjectTypes, VariableTypes, ReferenceTypes, and DataTypes. Every node has a NodeId, a BrowseName, a DisplayName, and a set of attributes defined by its node class.

This means an OPC UA server for a motor drive can expose not just a speed value, but:

• The engineering unit (rpm)
• The valid range (0–3,600 rpm)
• A structured alarm object with severity levels
• A Start() method the client can invoke
• A parent object of type DriveType defined in a companion specification

OPC UA companion specifications — published by organisations such as OMAC (PackML), EUROMAP, and the OPC Foundation itself — define standardised information models for specific device classes and industries. This semantic richness makes OPC UA the protocol of choice when you need a queryable, self-describing plant-floor data model.

---

Scalability and Bandwidth

Sparkplug B's pub/sub architecture scales horizontally in a way that OPC UA client/server does not. Adding 500 more edge nodes to a Sparkplug deployment means 500 more broker connections — the broker is designed for this. Adding 500 more OPC UA servers means 500 more client connections to manage, each requiring its own session, security handshake, and subscription management.

For bandwidth, Sparkplug B's report-by-exception (RBE) model is the key advantage. A Protobuf-encoded metric change notification is typically 20–100 bytes. The same data in OPC UA Binary encoding over TCP (the most efficient OPC UA transport) is compact but the session overhead is higher when a client polls rather than subscribes. OPC UA subscriptions with monitored items do implement their own form of report-by-exception, closing much of the gap — but the session setup and keepalive overhead remains.

In constrained network environments — cellular, satellite, low-bandwidth WAN — Sparkplug B's binary Protobuf payload over an outbound-only TCP connection is often significantly more practical.

---

State Management and Report-by-Exception

One of Sparkplug B's most underappreciated features is its full state management protocol. When an edge node connects to the broker for the first time (or reconnects after an outage), it publishes a NBIRTH (Node Birth) message containing the current value of every metric at that moment. Subscribers who missed messages during a disconnection can reconstruct full current state from the BIRTH message.

When the edge node disconnects unexpectedly, the broker publishes an NDEATH message using MQTT's Last Will and Testament (LWT) mechanism, so consumers know immediately that the data source is offline.

This BIRTH/DATA/DEATH lifecycle is what makes Sparkplug B suitable for cloud-scale IIoT, where connections drop, systems restart, and new consumers come online at unpredictable times. A new subscriber can always get a consistent snapshot of device state without querying a separate database.

OPC UA's equivalent is the subscription and monitored item mechanism. OPC UA servers maintain a queue of change notifications per monitored item and deliver them to clients on a configured publishing interval. If a client disconnects, the server can optionally retain queued notifications for a configurable lifetime. However, OPC UA does not have a native "broadcast current state to all new subscribers on connect" primitive equivalent to a Sparkplug BIRTH message.

---

Brownfield and Legacy Device Fit

Both protocols can address brownfield environments, but through different mechanisms.

Sparkplug B in brownfield: Most brownfield PLCs do not natively speak Sparkplug B. You deploy an IIoT gateway (such as Cirrus Link's Ignition MQTT Engine, Inductive Automation's built-in Sparkplug support, or open-source alternatives) that polls the PLC using its native protocol (Modbus, EtherNet/IP, S7) and translates the data into Sparkplug B messages toward the broker. The PLC never needs to be modified.

OPC UA in brownfield: Most modern PLCs (Siemens S7-1500, Allen-Bradley CompactLogix, B&R, Beckhoff) ship with OPC UA server functionality built in or available as a firmware option. For older PLCs, an OPC UA gateway (Kepware KEPServerEX, Matrikon, Softing, etc.) can bridge legacy protocols to OPC UA. Because OPC UA is a direct client/server connection, there is no broker to manage, but the client must have network access to the PLC or gateway.

The gateway pattern for Sparkplug means that the broker decouples all consumers from the physical network topology of the plant floor — a significant architectural advantage in large multi-site deployments.

---

It's Not Either/Or: OPC UA PubSub and the Unified Namespace

The framing of "Sparkplug vs OPC UA" implies a binary choice. The reality in 2026 is that the most sophisticated IIoT architectures combine them deliberately.

OPC UA PubSub over MQTT

The OPC UA specification Part 14 defines a PubSub mechanism that can use MQTT as its transport. An OPC UA PubSub publisher sends OPC UA-encoded messages (in JSON or UADP binary format) to MQTT topics. Subscribers receive standard OPC UA data payloads without establishing a direct OPC UA session.

This means it is possible to run an OPC UA information model on the plant floor and publish structured, semantically rich updates to the same MQTT broker handling Sparkplug B messages from other devices.

The Unified Namespace

The Unified Namespace (UNS) architecture, popularised by Walker Reynolds and widely adopted in greenfield IIoT projects, uses a central MQTT broker as the single source of truth for all plant data. Sparkplug B is the most common payload format for edge nodes in a UNS, but OPC UA PubSub is also a valid publisher. The UNS pattern is not tied to either protocol — it is an architectural pattern that both can serve.

In a typical UNS implementation:

1. Edge nodes (PLCs, sensors, drives) publish to the broker via Sparkplug B
2. OPC UA servers on more capable devices publish via OPC UA PubSub over MQTT
3. SCADA, historians, MES, and cloud analytics subscribe to relevant topics
4. No consumer needs to know the physical address of any device

This architecture delivers the semantic richness of OPC UA's information model where needed (complex equipment with methods and alarm objects) and the bandwidth efficiency of Sparkplug B where appropriate (high-frequency telemetry from many simple sensors).

---

When to Choose Which

Choose MQTT Sparkplug B when:

• You have many edge devices (dozens to thousands) publishing telemetry to a central system
• Bandwidth is constrained — cellular, satellite, or low-bandwidth WAN connections
• Your data is primarily time-series telemetry (temperature, pressure, flow, vibration)
• You need firewall-friendly, outbound-only connections from the plant floor to cloud
• You are building a Unified Namespace architecture from scratch
• Your team is comfortable managing an MQTT broker and has limited OPC UA expertise
• You need horizontal scalability without per-device connection management

Choose OPC UA when:

• You need a queryable, self-describing information model with engineering units, data types, and hierarchy
• Your SCADA or MES system has native OPC UA client support built in
• You need to invoke methods or write commands back to devices with semantic context
• You are integrating with equipment that follows an OPC UA companion specification (PackML, MTConnect OPC UA, etc.)
• You require fine-grained, certificate-based security at the session level
• Your plant floor is Ethernet-connected with direct network access between clients and servers
• You are connecting to a modern PLC with built-in OPC UA server (Siemens S7-1500, B&R, Beckhoff)

Use both when:

• You are building a large multi-site IIoT platform where different equipment classes have different requirements
• You want Sparkplug B as the UNS transport with OPC UA information models published via OPC UA PubSub
• Your SCADA layer needs the full OPC UA model locally while the cloud analytics layer consumes Sparkplug B telemetry
• You are migrating from a legacy OPC UA client/server architecture toward a broker-centric UNS

---

Frequently Asked Questions

What is the difference between MQTT Sparkplug and OPC UA?

MQTT Sparkplug B is a publish-subscribe protocol built on MQTT that uses Protobuf payloads and a defined topic namespace to deliver efficient, stateful telemetry from edge devices to a central broker. OPC UA is a client/server protocol (with an optional PubSub extension) that exposes a rich, hierarchical information model on the device or gateway, allowing clients to browse, read, write, and invoke methods with full semantic context. Sparkplug B optimises for bandwidth efficiency and scale; OPC UA optimises for semantic richness and interoperability.

Is Sparkplug B better than OPC UA?

Neither is universally better. Sparkplug B is better for high-frequency, bandwidth-constrained telemetry from many edge devices. OPC UA is better when you need a self-describing, queryable information model with engineering units, alarm objects, and method calls. For most greenfield IIoT architectures in 2026, "better" is the combination: Sparkplug B as the transport layer for a Unified Namespace, with OPC UA information models where semantic richness is required.

Can you use OPC UA and MQTT together?

Yes, in two ways. First, OPC UA Part 14 defines a PubSub mechanism that uses MQTT as its transport, allowing OPC UA-encoded payloads to be published to an MQTT broker without a direct OPC UA session. Second, in a Unified Namespace architecture, OPC UA servers on the plant floor can coexist with a Sparkplug B MQTT broker — an IIoT gateway reads OPC UA data and republishes it as Sparkplug B topics, combining both protocols' strengths.

Which is better for IIoT?

For pure IIoT telemetry at scale — many devices, high message rates, constrained networks — Sparkplug B over MQTT has clear advantages in bandwidth efficiency and horizontal scalability. For IIoT scenarios that require deep integration with plant-floor equipment, rich data context, and interoperability with existing OPC UA-native SCADA and MES systems, OPC UA remains the standard. Most serious IIoT platforms support both, and the choice of "which is better" often resolves to "use both, each where it excels."

---

To go deeper on the OPC UA side of this comparison, the full OPC UA tutorial covers architecture, security modes, and a hands-on first-connection walkthrough. For the broader landscape of industrial connectivity from the PLC up, see the IIoT PLC integration complete guide and the PLC communication protocols complete guide.