Sparkplug B vs OPC UA PubSub: 2026 Decision Matrix

For a decade the Sparkplug B vs OPC UA PubSub debate was held in the wrong frame. People argued MQTT versus OPC UA as if they were rival transports, when in fact MQTT is a transport and OPC UA is an information-modelling stack that happens to need one. In 2026, with Eclipse Sparkplug 3.0 fully GA and OPC UA Part 14 PubSub bindings to MQTT 5 maturing in shipped products from PTC Kepware, Softing, Prosys, and the Unified Automation stack, the comparison is finally sharp. Both protocols can ride MQTT 5 brokers, both can model thousands of devices, and both claim “unified namespace” credibility. The real 2026 question is not “which transport” but the pair of choices underneath it: what payload semantics do you want and what broker semantics do you want the integrator team to own. This post lays that pair out in detail, with five diagrams, a decision matrix, and a hybrid pattern that has been quietly winning in the brownfield.

Why This Comparison Got Sharper in 2026

Answer-first summary: The Sparkplug-versus-OPC-UA-PubSub comparison hardened in 2026 because both specifications stopped moving and started shipping at scale. Sparkplug 3.0 closed open questions on host application behaviour, rebirth semantics, and template handling. OPC UA Part 14 PubSub now has production-grade MQTT 5 mappings, JSON encodings that humans can debug, and a Security Key Service profile that solves the long-standing key-rotation problem. The result is two genuinely complete options where there used to be one mature option and one specification in flux.

Eclipse Sparkplug 3.0 reached final-spec status in 2023 and has since accumulated multi-vendor production deployments across Cirrus Link, HiveMQ, Inductive Automation’s Ignition platform, Litmus Edge, and Bevywise. Version 3.0 cleaned up the host-application state model, fixed ambiguities around rebirth requests, and tightened the use of MQTT 5 features like shared subscriptions. As of 2026 the specification is stable enough that integrator teams talk about “Sparkplug” the way they talk about “OPC UA Client/Server” — a finished thing they design around, not a moving target.

The OPC UA side of the comparison moved faster than most expected. OPC UA Part 14, PubSub, was first published in 2018, but its early implementations leaned on UDP multicast for the deterministic flavour and were not directly comparable to Sparkplug’s broker-mediated topology. Between 2022 and 2026 the OPC Foundation and member vendors did the slow, important work: stable MQTT 5 mappings (with both UADP-binary and JSON encodings), the Security Key Service profile for rotating WriterGroup keys without restarts, and the OPC UA FX field-level companion specs that anchor the deterministic edge. That work is summarised cleanly in our OPC UA FX field-level communications analysis.

A third forcing function is the unified namespace (UNS) movement popularised by Walker Reynolds and amplified by HiveMQ, Inductive Automation, and the broader ISA-95 community. UNS treats the broker as the single source of truth for plant state, with topics structured by ISA-95 hierarchy. Sparkplug was for years the obvious payload choice for UNS — the unified namespace architecture with HiveMQ and Sparkplug B is now standard tooling for greenfield UNS deployments. But OPC UA PubSub over MQTT 5 is the new entrant making a UNS claim of its own, with the argument that information-model fidelity matters more than topic-tree elegance. Both camps are right about half the time, which is why the decision matrix at the end of this post is the actual deliverable, not the headline.

Protocol Anatomies Side by Side

Answer-first summary: Sparkplug B is a thin, opinionated protocol layered on top of MQTT 5: Protobuf payloads, a fixed topic namespace, a strict session model anchored on NBIRTH/DBIRTH/NDEATH, and host-application semantics that ride MQTT’s retain and Last Will features. OPC UA PubSub is a transport-neutral binding of the OPC UA information model that can ride MQTT 5, UDP multicast, AMQP, or TSN-Ethernet — with WriterGroups, DataSetWriters, KeyFrames, DeltaFrames, and a SecureChannel-equivalent over the chosen transport. They overlap most where they both ride MQTT 5, and diverge most in what they consider canonical.

The two stacks share a transport floor in 2026 but disagree about almost everything above it. The shape of the disagreement repays a careful look because the right protocol for a project is usually obvious once the stacks are laid against each other.

Session model and lifecycle

Sparkplug B’s session model is the most visible part of the protocol and arguably its biggest design contribution. Every edge node, on connecting to the broker, publishes an NBIRTH message that enumerates every metric it can report — name, datatype, current value, and an integer alias that compresses subsequent messages. Each device under that node publishes a DBIRTH of its own. Subsequent value changes ride NDATA and DDATA messages that reference aliases rather than names, which is what keeps the protocol compact on the wire. When the edge node disconnects, the broker delivers the previously registered NDEATH Last Will Testament to subscribers, who can mark the node STALE in their state model.

The session model means that any subscriber joining the broker — even hours after the edge node connected — receives an unambiguous picture: a BIRTH replays the metric list (via a rebirth request the host application can issue), and subsequent NDATA messages update specific aliases. This is the architectural reason Sparkplug feels natural to SCADA engineers; it resembles a polled namespace they already understand, but it is event-driven on the wire.

OPC UA PubSub uses a fundamentally different model. A WriterGroup is a logical channel that publishes one or more DataSetMessages, each carrying a DataSet of fields defined by a PublishedDataSet. Lifecycle is handled by KeyFrame messages (full DataSet contents, published at a configured cadence or on join) and DeltaFrame messages (only changed fields). A KeepAlive message is emitted when no data changed inside the publish interval, so subscribers can distinguish a quiet publisher from a dead one. There is no equivalent of NDEATH-via-Last-Will out of the box; quality is inferred from missed KeepAlives and sequence numbers.

Both models work. Sparkplug’s is more prescriptive and easier to teach. OPC UA’s is more flexible — KeyFrame intervals, DeltaFrame thresholds, KeepAlive timeouts and DataSet content are all tunable per WriterGroup — at the cost of more configuration surface.

Payload encoding

Payload encoding is where the protocols diverge most visibly. Sparkplug B uses Google Protocol Buffers with a single, frozen .proto definition (the Sparkplug B Payload schema) that describes Metric, Template, Dataset, PropertyValue, and metadata. Every Sparkplug implementation in the world decodes the same bytes the same way. The schema is fixed; the metric content is dynamic. That trade-off makes Sparkplug payloads tiny — typically 30 to 80 bytes for a single-metric NDATA — and easy to parse on resource-constrained edge devices.

OPC UA PubSub offers two encodings on the same wire. UADP is the binary encoding inherited from OPC UA’s transport layer: compact, fast, and structured by the WriterGroup’s known DataSet metadata. JSON encoding is a human-readable variant added explicitly for MQTT-style transports where ops teams expect to be able to subscribe to a topic and read the messages with mosquitto_sub. The JSON form is larger on the wire (often 4x-8x the UADP equivalent) but pays for itself in debuggability — the same trade-off that pushed half the cloud-native world to JSON over Avro.

The deeper difference is that Sparkplug’s payload describes itself at BIRTH time and then references that description via aliases, while OPC UA’s payload assumes both ends already share the information model that defines the DataSet. That assumption is reasonable if you control both endpoints or share a companion specification; it is awkward if you do not, which is why Sparkplug has been easier to drop into heterogeneous brownfield environments.

Namespace semantics

Sparkplug fixes its topic namespace by specification: spBv1.0/{group_id}/{message_type}/{edge_node_id}[/{device_id}]. The integrator owns group_id, edge_node_id, and device_id; the rest is non-negotiable. This is part of what makes Sparkplug interoperable by construction — any Sparkplug-aware client knows where to find any Sparkplug-aware publisher. UNS implementations layer their ISA-95 hierarchy into the group_id and edge_node_id slots, and tooling like Inductive Automation’s MQTT modules or HiveMQ’s Sparkplug-aware components understands the structure natively.

OPC UA PubSub leaves the topic namespace mostly to the operator. The MQTT mapping in Part 14 defines a recommended structure (opcua/json/{publisher-id}/{writer-group-name}) and a metadata topic for DataSetMetaData, but it is convention rather than constraint. The information model itself — companion specifications like Robotics, Machinery, Pump, Process Automation — replaces the topic tree as the canonical namespace. An OPC UA PubSub client locates the meaning of a value through the OPC UA address space, not through the topic path.

That difference is the heart of the namespace argument. Sparkplug puts meaning in the topic tree; OPC UA puts meaning in the information model and treats the topic tree as a routing detail. Both are defensible designs, and a UNS architect can build a working namespace on either — but the architecture work is in different places.

Security Model: Sparkplug TLS+AuthN vs OPC UA SecureChannel Over MQTT

Answer-first summary: Sparkplug B inherits MQTT 5’s security model — mutual TLS, MQTT-CONNECT credentials, optional OAuth 2.0 via the MQTT 5 enhanced authentication exchange, and broker-side ACLs against topic patterns. OPC UA PubSub adds an application-layer security layer on top of whatever transport carries it, with WriterGroup keys rotated by a Security Key Service and per-message sign-and-encrypt independent of TLS. The two models are complementary in theory; in practice they encode different threat assumptions about who you trust between the publisher and the subscriber.

Sparkplug security is, by design, broker-centric. The edge node authenticates to the broker with mutual TLS (the dominant pattern in 2026 production deployments) or with username/password under TLS, and from that moment on, the broker is the trust boundary. ACLs at the broker control which clients can publish or subscribe to which topic patterns. Anyone who can break into the broker — or who is the broker, in the case of a managed cloud — can in principle observe everything. That model is a deliberate trade for operational simplicity: it is dead easy to reason about, easy to audit (broker logs are the audit log), and easy to scale because the broker is already in the data path.

OPC UA PubSub takes the opposite stance. The expectation is that the transport — broker, multicast group, AMQP exchange — may be entirely untrusted. Messages carry their own sign-and-encrypt envelope using symmetric keys negotiated per WriterGroup and rotated by a Security Key Service. Sequence numbers detect replay; nonces detect tampering; the broker is a routing convenience that never sees plaintext (when SignAndEncrypt is in use). The SKS profile in 2026 finally makes this practical for non-trivial deployments because keys can be rolled without restarting the WriterGroup, which used to be the operational blocker.

The 2026 reality is more subtle than the spec sheets suggest. In most production deployments, Sparkplug runs with TLS to the broker and with the broker as a strongly authenticated component, and that is considered sufficient for the threat model of an on-premises industrial network — especially in segmentation patterns like the one we describe in the NAMUR NOA process-industry adoption architecture. OPC UA PubSub’s payload-level encryption matters when messages traverse infrastructure you cannot trust: cloud brokers in shared tenants, public-internet transports, or multi-tenant MQTT gateways. For those cases, OPC UA’s model is genuinely stronger, and the SKS-rotated keys are a meaningful improvement over the pre-2024 state of the art.

There is a third dimension that gets less attention: identity granularity. Sparkplug authenticates clients (edge nodes), and authorisation is via topic-pattern ACLs. OPC UA PubSub can authenticate DataSets — different WriterGroups within a single publisher can use different keys, share with different subscribers, and rotate independently. For multi-tenant scenarios (an OEM publishing telemetry to several customers from one gateway, for instance) the OPC UA model is structurally cleaner.

For most internal-plant deployments, Sparkplug’s broker-centric security is sufficient. For cross-organisation telemetry, regulated industries with strict end-to-end encryption requirements, or any scenario where the broker tenant is not fully trusted, OPC UA PubSub’s application-layer model earns its complexity.

Broker Semantics: MQTT 5 STATE vs OPC UA PubSub Mid-Tier

Answer-first summary: Sparkplug B encodes session state into MQTT retained messages and Last Will Testaments and expects a single conformant broker (MQTT 5, with shared subscriptions and retained messages) to do the heavy lifting. OPC UA PubSub treats the broker as a dumb pipe and encodes state into its own KeyFrame/DeltaFrame/KeepAlive cycle, which means it works on MQTT, on UDP multicast, on AMQP, and on TSN-Ethernet without changing application semantics. The state-where question is the deepest architectural difference between the two protocols.

The state-handling difference is what makes Sparkplug feel like a finished product and OPC UA PubSub feel like a kit. Both are correct designs for different deployment profiles.

In Sparkplug, the broker is a participant. A STATE topic carries the host application’s online/offline status as a retained MQTT message; edge nodes use that retained message at connect time to know whether their host is alive and whether to send a BIRTH. NDEATH is registered as the Last Will at MQTT-CONNECT time, so the broker delivers it automatically on abnormal disconnect — no application code on the edge node has to detect its own death. BIRTH messages are not retained (they would go stale across reconnects), so a late-joining subscriber issues a rebirth command that the host application or any privileged client can send, prompting the edge node to republish its BIRTH.

That design assumes a single coherent broker and pays for that assumption with a very clean conceptual model. There is exactly one place plant state lives — the broker — and exactly one rule for how to reconstruct it: subscribe, get the STATE retained message, get the BIRTH on rebirth, then receive NDATA streams. SCADA engineers can teach this to a junior on a whiteboard in an afternoon.

OPC UA PubSub treats the broker as a pipe with no obligations beyond delivering bytes. State lives in the publisher and is reconstructed on the subscriber side from the message stream: a periodic KeyFrame (configurable cadence, typical values are 1 to 60 seconds) republishes the entire DataSet from scratch; DeltaFrames carry only changed fields in between; KeepAlive messages are sent at the publish interval when nothing changed so the subscriber knows the publisher is alive. The subscriber tracks sequence numbers per DataSetWriter and infers data quality from gaps and timeouts.

The advantages of the OPC UA approach show up under stress. Brokers can fail over, multiple brokers can be aggregated, and the same WriterGroup definition can be reused over UDP multicast for deterministic field-level use cases. The cost is a denser configuration surface (every WriterGroup has its own intervals, security keys, and DataSet definitions) and a less obvious mental model. Operators with mature OPC UA tooling find this normal; operators coming from an MQTT-first background find it busy.

The 2026 sharp edge here is bridge behaviour. A Sparkplug-to-OPC-UA bridge — common in UNS deployments that need to feed an MES or twin that speaks UA — has to reconcile these two state models. The bridge must hold a Sparkplug session (consuming BIRTH/DATA/DEATH) and republish it as a WriterGroup with periodic KeyFrames and reasonable DeltaFrame thresholds. HiveMQ’s documentation on OPC UA over MQTT and Cirrus Link’s bridge modules both have to make explicit choices about KeyFrame cadence, KeepAlive timeout, and how an NDEATH propagates into a BadCommunicationError for downstream OPC UA subscribers. Those choices are where the brittleness lives in mixed deployments and where most field issues originate.

Decision Matrix and Hybrid Patterns

Answer-first summary: The right protocol depends on five questions: real-time determinism requirements, cross-vendor information-model breadth, who owns the topic namespace, the team’s existing skill mix, and whether the data needs to leave the plant boundary on standard brokers. The decision tree resolves to one of four answers — Sparkplug B alone, OPC UA PubSub over MQTT, OPC UA PubSub over UDP/TSN (FX), or a hybrid with Sparkplug at the edge and OPC UA PubSub upstream. The hybrid pattern is winning more than 2026 marketing implies.

The five questions in the decision tree deserve specifics.

Real-time determinism. If any part of the use case needs sub-10-millisecond, deterministic delivery — motion synchronisation, distributed control loops, fast safety chains — MQTT brokers are the wrong substrate for that segment regardless of protocol. The 2026 answer there is OPC UA PubSub over UDP or TSN-Ethernet, as covered in our OPC UA FX deep dive. Sparkplug over MQTT does not pretend to solve this problem. Most plants have at most one or two segments with this requirement, and they coexist alongside softer messaging fabrics for the rest of the plant.

Cross-vendor information models. If the architecture depends on multiple OEMs presenting devices via OPC UA companion specifications — Robotics, Machinery, Pump, Process Automation, Asset Administration Shell — then OPC UA PubSub keeps those models intact end-to-end. Sparkplug can carry the same data but flattens the model into topic + metric, losing the structural fidelity that companion specs deliver. Plants that have invested heavily in companion-spec adoption tend to keep that fidelity all the way up.

Topic namespace ownership. If the topic namespace is owned by the operator or system integrator — the UNS pattern — Sparkplug is the more natural fit because the topic structure carries meaning that the operator controls. If the namespace is effectively defined by the device vendor or by a companion specification, OPC UA’s address-space-as-namespace model is the better match.

Team skill mix. This is the question everyone wants to skip and everyone should answer honestly. Sparkplug B is teachable in days to an SCADA engineer with MQTT exposure; OPC UA PubSub requires comfort with the OPC UA address space, DataSet modelling, and SKS configuration. A team without OPC UA depth that adopts PubSub will struggle through the first six months. A team without MQTT depth that adopts Sparkplug will struggle through the first three weeks, and then it will work.

WAN and cloud fan-out. Both protocols ride MQTT 5 brokers, so both can fan out across WANs through cloud-hosted brokers, mTLS-protected. Sparkplug’s topic ACLs map naturally to cloud broker tenant boundaries. OPC UA PubSub’s WriterGroup-level keys map naturally to multi-tenant scenarios where the broker tenant is not fully trusted. If both are deployed over MQTT 5, either works; the decision falls back to the other four questions.

The hybrid pattern in Figure 5 is what a lot of plants are quietly converging on. Sparkplug B at the cell and edge — where the protocol’s simplicity, BIRTH/DEATH semantics, and SCADA-friendly topic structure deliver value fast, on hardware that can run a lightweight MQTT broker locally. Above the supervisory tier, a bridge translates into OPC UA PubSub WriterGroups over a hardened MQTT broker fleet, so MES, historian, and digital-twin consumers see structured information models with rotating WriterGroup keys. The supervisory broker handles the UNS hub function (see the unified namespace architecture with HiveMQ and Sparkplug B for a deeper walkthrough), while the OPC UA layer carries the information-model fidelity outward. This pattern is not in any specification, but it is what the more pragmatic 2026 architectures look like in practice.

Trade-offs, Gotchas, and What Goes Wrong

The Sparkplug failure modes cluster around rebirth storms and alias drift. A misconfigured host application that issues blanket rebirth requests can pin an edge node’s CPU as it republishes BIRTH for every device under it; multiply by hundreds of nodes and a single rebirth burst can knock a small broker over. Alias drift happens when an edge node’s metric list changes between BIRTH messages without a clean DEATH in between — subscribers cache the old alias-to-name mapping and decode subsequent NDATAs against stale aliases until they realise something is wrong. Both are operational problems, not specification problems, but both are common in production.

OPC UA PubSub’s failure modes are different and arguably nastier when they happen. KeyFrame cadence misconfiguration leaves late-joining subscribers waiting up to a minute to see the full DataSet, which can look like the application is dead. SKS misconfiguration silently drops every message because the subscriber cannot decrypt — a class of failure that often shows up as “the broker is fine, but no data is flowing,” which is murder to diagnose. JSON-versus-UADP mismatch between publisher and subscriber configuration leads to perfectly valid bytes that decode to nothing. The OPC UA stacks log helpfully, but the failure surface is wider than Sparkplug’s.

Both protocols share two longer-tail gotchas. Bridge brittleness in hybrid deployments is the single most common production issue in 2026 — every translation step is a place where state models disagree and bugs hide. Backpressure is rarely modelled explicitly: a slow subscriber on a Sparkplug broker can cause unbounded queue growth, and an OPC UA publisher with too-frequent DeltaFrames can overwhelm a cloud broker tenant’s rate limits. Plan for both.

Practical Recommendations

For greenfield UNS deployments anchored on MQTT skills and an operator-owned namespace, Sparkplug B 3.0 is the lower-risk choice. The session model is finished, the tooling is mature, and the operational model fits the team most plants already have.

For deployments where OPC UA companion specifications carry serious value — process automation with the PA-DIM companion, robotics cells with the Robotics companion, or any multi-vendor information-model-heavy architecture — OPC UA PubSub over MQTT 5 keeps the structural fidelity that Sparkplug flattens.

For any segment with hard-real-time requirements, use OPC UA PubSub over UDP or TSN-Ethernet (OPC UA FX) and isolate it from the MQTT fabric. Do not try to bend MQTT into a deterministic transport.

For mixed brownfields with strong opinions in different parts of the plant, adopt the hybrid pattern: Sparkplug at the cell/edge for operational simplicity, a UNS broker as the integration point, and OPC UA PubSub upstream wherever the receiving systems already speak UA. Invest disproportionately in the bridge and in testing the BIRTH/DEATH-to-KeepAlive mapping under failure modes — that is where production issues will live.

Finally, treat the protocol decision as orthogonal to the broker choice. HiveMQ, EMQX, Mosquitto, and the major cloud MQTT services all handle either protocol well enough; the choice between them is driven by clustering, observability, and operations needs, not by Sparkplug-versus-OPC-UA.

FAQ

What is the practical difference between Sparkplug B and OPC UA PubSub in 2026?
Sparkplug B is a Protobuf-payload protocol with a fixed topic namespace and a strong session model (NBIRTH/DBIRTH/NDEATH) that rides exclusively on MQTT 5. OPC UA PubSub is a transport-neutral binding of the OPC UA information model that can ride MQTT 5, UDP multicast, AMQP, or TSN-Ethernet, with WriterGroup-level security and KeyFrame/DeltaFrame/KeepAlive state semantics. In 2026 both can run on the same MQTT 5 broker, so the choice is about payload semantics and operational model rather than transport.

Is Sparkplug B a competitor to OPC UA?
No. Sparkplug B is an MQTT-payload specification that solves the “MQTT topic and payload chaos” problem; OPC UA is a full information-model stack with client/server, PubSub, and companion specifications. The competitive overlap is specifically between Sparkplug B and OPC UA PubSub over MQTT 5 as a transport for industrial telemetry. Outside that intersection, OPC UA covers ground (companion specs, address space, services) that Sparkplug deliberately does not.

Can I run both Sparkplug B and OPC UA PubSub on the same MQTT broker?
Yes, and many 2026 deployments do exactly that — they use Sparkplug topics (spBv1.0/...) for edge data and OPC UA JSON-encoded WriterGroup topics for supervisory layers, sharing one broker fleet. Topic-pattern ACLs keep the two namespaces from interfering, and the broker treats each like any other MQTT 5 traffic. The integration cost shows up not at the broker but at the bridge between the two protocols, which needs to reconcile their state models.

Does OPC UA PubSub over MQTT replace OPC UA Client/Server?
For high-fanout telemetry it largely does, which is the main reason Part 14 was written. For request/response interactions — browsing the address space, calling methods, alarms and conditions, historical-access queries — Client/Server remains the appropriate model. Most production architectures use Client/Server for engineering and config interactions and PubSub for runtime data fan-out, sometimes alongside Sparkplug for the edge layer.

Which is better for a unified namespace?
Both work; they encode the namespace differently. Sparkplug puts the meaning in the topic tree (ISA-95 hierarchy in group_id/edge_node_id), which is intuitive and integrator-controlled. OPC UA PubSub puts the meaning in the information model, with the topic structure as a routing detail; this preserves companion-spec fidelity but pushes more modelling work onto the integrator. For greenfield UNS with MQTT-first teams, Sparkplug B is the smoother fit. For UNS where information-model fidelity is a hard requirement, OPC UA PubSub over MQTT 5 earns its complexity.

Further Reading

Internal:

• Industrial IoT pillar overview — where this comparison sits in the broader IIoT architecture map.
• Unified Namespace Architecture with HiveMQ and Sparkplug B (2026) — the canonical UNS deployment pattern.
• OPC UA FX Field-Level Communications Analysis (2026) — the deterministic, TSN-anchored side of OPC UA.
• NAMUR NOA Process-Industry Adoption Architecture (2026) — how segmentation patterns shape the protocol decision in process plants.

External:

• Eclipse Sparkplug 3.0 specification (eclipse.dev/sparkplug).
• OPC Foundation OPC UA Part 14: PubSub (opcfoundation.org).
• HiveMQ blog series on OPC UA over MQTT.
• Walker Reynolds and the 4.0 Solutions community on Unified Namespace.