Plain MQTT vs Sparkplug for SCADA: Which Fits
Once you have chosen MQTT, a second question follows: do you use it raw, defining your own topics and payloads, or adopt Sparkplug, which fixes those decisions for you in exchange for structure and interoperability? This comparison is for the engineer weighing freedom against convention for a new industrial deployment. It lays out what Sparkplug adds, what it costs, and when each approach is the right call.
Plain MQTT vs Sparkplug in one line: Plain MQTT gives you total freedom over topics and payloads but leaves state management, payload structure, and interoperability entirely up to you. Sparkplug layers a defined topic namespace, a self-describing payload, and a birth-death state model on top of MQTT, giving interoperability and correct offline handling out of the box, at the cost of conforming to its structure. Choose Sparkplug for multi-vendor industrial fleets; plain MQTT for simple or highly custom needs.
The Decision in One Paragraph
The trade is freedom versus convention. Plain MQTT is a blank slate: you invent your topic hierarchy and payload format and you are responsible for every hard problem, notably knowing when a node is offline and how to represent its state. Sparkplug takes those decisions away and solves them well: it defines the topic structure, mandates a self-describing payload, and builds in the birth-death lifecycle that makes offline detection correct. If you are connecting industrial equipment across vendors and want it to just work together, Sparkplug's structure is a gift. If your needs are simple or genuinely bespoke, plain MQTT's freedom may serve you better.
The comparison below breaks this down by the dimensions that actually decide it, followed by where each approach wins and the pitfalls of each choice.
Side by Side on the Dimensions That Matter
The table contrasts the two on the axes engineers actually weigh, from who owns the hard problems to how well the result interoperates.
| Dimension | Plain MQTT | Sparkplug B |
|---|---|---|
| Topic structure | You design it freely | Defined namespace and message types |
| Payload format | Anything you choose | Self-describing protobuf, fixed encoding |
| Offline detection | You build it yourself | Built-in birth and death certificates |
| State on reconnect | Your responsibility | Rebirth resynchronizes automatically |
| Interoperability | Only with those who know your convention | Any Sparkplug-aware host understands it |
| Learning curve | Low to start, high to get right | Higher up front, guided thereafter |
| Flexibility | Total | Constrained to the spec |
Read the Sparkplug column and each row is a decision the plain-MQTT column leaves you to make and get right yourself. The offline and reconnect rows are the most consequential: Sparkplug's birth and death certificates and its rebirth resynchronization solve, by specification, exactly the state problems that trip up a home-grown plain-MQTT design.
When Each Approach Wins
Sparkplug wins for multi-vendor industrial fleets and for anyone who does not want to reinvent state management. Because the topic structure and payload are defined, a Sparkplug-aware host can consume data from equipment it has never seen without custom mapping, and the birth-death model means offline nodes and stale data are handled correctly by design rather than by whatever your team remembered to build. For a SCADA system aggregating many sites and devices, that interoperability and correctness are worth conforming to the specification, and it pairs naturally with a unified namespace.
Plain MQTT wins where the structure would be a straitjacket. A small, self-contained system with one team on both ends, a highly custom payload that does not fit the metric model, or a case where you are integrating MQTT with non-industrial systems that expect a particular format, all argue for keeping the freedom. You take on the responsibility for state and interoperability, but if the deployment is simple enough that those are not hard problems, you avoid the overhead of conforming to a specification you do not need. A JSON payload schema is a common plain-MQTT choice.
A realistic note: the two are not always mutually exclusive across a whole enterprise. Some architectures run Sparkplug for the industrial edge, where its state model shines, and plain MQTT elsewhere for integration flexibility, bridging between them where needed. The decision is best made per data domain rather than as a single company-wide edict, choosing Sparkplug where interoperability and correct offline handling matter most and plain MQTT where freedom does.
Pitfalls of Each Choice
The plain-MQTT pitfall is underestimating how hard the problems Sparkplug solves really are. Teams routinely build a plain-MQTT system quickly, then discover they have no clean way to know a node is offline, no consistent payload, and no resynchronization after a dropped link, and they end up reinventing a worse version of the birth-death model. If you find yourself building offline detection and state resync by hand, that is a signal Sparkplug already solved it. The Sparkplug pitfall is the opposite: adopting it for a trivial system where its structure adds ceremony without payoff, or fighting the specification because your data genuinely does not fit its model. Match the tool to the scale and heterogeneity of the deployment, not to fashion.
Frequently Asked Questions
Do I always need Sparkplug if I use MQTT for SCADA?
No. Sparkplug is a layer on top of MQTT, not a requirement of it. You can run plain MQTT with your own topics and payloads perfectly well, and for a simple, self-contained system with one team controlling both ends, that freedom may be the better fit. Sparkplug earns its keep when you have multiple vendors or many sites and want interoperability and correct offline handling without building them yourself. If you find yourself hand-building state management and reconnection resync, that is when Sparkplug becomes worthwhile.
What does Sparkplug give me that plain MQTT does not?
Three things chiefly. A defined topic namespace and message types, so any Sparkplug-aware consumer can parse your data without a custom convention. A self-describing payload, so metrics carry their own names, types, and metadata and no external tag dictionary must be kept in sync. And a birth-death state model with rebirth, so offline nodes, stale data, and reconnection resynchronization are handled by specification rather than by whatever your team built. Plain MQTT can do all of this too, but you have to design and maintain every piece yourself.
Sources and verification
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.
- MQTT Version 5.0 (OASIS Standard) - OASIS (v5.0, 2019)
Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.