Sparkplug vs Plain MQTT for SCADA
MQTT gives you a broker and a way to publish payloads, but it says nothing about what those payloads mean or how to know a device is alive. Sparkplug is a specification layered on MQTT that fills exactly those gaps for industrial use. This page is for the engineer deciding whether to adopt the convention or roll their own on raw MQTT. It compares state awareness, payload structure, and interoperability, then gives a rule for choosing.
Sparkplug vs Plain MQTT in one line: Choose Sparkplug when you want defined state awareness, typed self-describing metrics, and out-of-the-box interoperability across industrial tools, because it standardizes birth and death certificates, payloads, and stale-data handling on top of MQTT. Choose plain MQTT when you need full control of a custom lightweight payload and are willing to define your own conventions for meaning and liveness. The decision is whether you want a ready-made industrial contract or a blank slate you will define yourself.
Compare State Awareness and Payload Structure
Plain MQTT is deliberately minimal: it publishes bytes to a topic and delivers them to subscribers, with a last-will message as the only built-in liveness hint. Sparkplug adds an industrial contract on top - defined message types, typed metrics with metadata, birth certificates that announce a device's full tag set, death detection, and sequence numbers that catch gaps.
| Attribute | Plain MQTT | Sparkplug |
|---|---|---|
| Payload meaning | Whatever you define | Typed, self-describing metrics |
| Device liveness | Last will only | Birth and death certificates |
| Tag discovery | Manual convention | Announced in the birth message |
| Gap detection | None built in | Sequence numbers per message |
| Interoperability | Bespoke per project | Common across Sparkplug tools |
| Flexibility | Total | Constrained to the spec |
The birth-certificate and state model is covered in Sparkplug B, and the underlying will mechanism in the MQTT last will and testament.
The tradeoff is structure versus freedom. Sparkplug gives you a shared contract that other Sparkplug-aware tools understand immediately, at the cost of conforming to its payload and topic rules. Plain MQTT gives you complete freedom to design the smallest, most custom payload for your case, at the cost of building and documenting all the meaning and liveness handling yourself. Which is right depends on whether interoperability or bespoke control matters more.
When Each One Wins
Sparkplug wins when interoperability and state awareness matter. If multiple tools and teams must understand the same MQTT data, or you need to know instantly and reliably when a device drops and comes back with its full tag set, Sparkplug's defined certificates and typed metrics deliver that without you inventing it. It shines across a fleet where consistent birth, death, and rebirth behavior keeps the whole picture coherent, as covered in the Sparkplug edge-node and device hierarchy.
Plain MQTT wins when you control both ends and want the leanest custom payload. For a bespoke device-to-app pipeline where you own the publisher and subscriber, a tiny hand-designed payload can be smaller and simpler than Sparkplug's structure, and you are not bound by its conventions. It is the right choice for constrained, closed systems where interoperability with other industrial tools is not a requirement and every byte counts.
The pragmatic view: adopt Sparkplug when your MQTT data will be consumed by more than one system or team, and use plain MQTT when it is a closed loop you fully control. Many fleets standardize on Sparkplug precisely so a new consumer - a dashboard, a historian, an analytics job - can subscribe and immediately understand the data, which is the whole point of a shared contract. Ingestion into a historian is discussed in MQTT to time-series database ingestion.
Adoption Pitfalls
The plain-MQTT pitfall is reinventing Sparkplug badly. Teams that start with raw payloads often end up adding their own birth messages, type tags, and liveness handling, arriving at a worse, undocumented version of what Sparkplug already specifies. If you find yourself building those features, adopt the standard instead of a private dialect only your project understands.
The Sparkplug pitfall is misusing its state model. Getting sequence numbers, rebirth requests, and primary-host state right takes care, and a node that mishandles rebirth can leave stale metrics or trigger reconnect churn. Sparkplug's guarantees only hold if you honor its lifecycle, so treat the birth, death, and rebirth flow as load-bearing rather than optional. Its constrained payload also means you cannot cram arbitrary structures in without breaking interoperability.
Either way, the data lands in a monitoring platform. A cloud SCADA such as Merobix can consume Sparkplug metrics with their built-in typing and state, or plain MQTT payloads against a documented schema, so the choice is about the contract between your devices and consumers, not about the platform. Choose Sparkplug for shared, state-aware fleets and plain MQTT for closed custom loops, and document whichever you pick so the next consumer is not left guessing.
Frequently Asked Questions
What does Sparkplug add that plain MQTT lacks?
State awareness and self-description. Sparkplug defines birth and death certificates so a subscriber knows exactly when a device connects with its full tag set and when it drops, typed metrics so payloads describe their own meaning, and sequence numbers to detect gaps. Plain MQTT provides none of this beyond a single last-will message, leaving you to invent liveness and payload meaning yourself, which Sparkplug standardizes for industrial use.
When is plain MQTT the better choice?
When you control both the publisher and subscriber and want the leanest possible custom payload without conforming to a spec. For a closed device-to-app pipeline where interoperability with other industrial tools is not required, a small hand-designed payload can be simpler and smaller than Sparkplug's structure. If the data must be understood by multiple teams or tools, though, Sparkplug's shared contract usually pays off.
Can I mix Sparkplug and plain MQTT on the same broker?
Yes. Sparkplug is a convention on top of MQTT, so Sparkplug and plain MQTT clients can share the same broker as long as they use distinct topic namespaces. Many deployments run Sparkplug for the fleet telemetry that needs state awareness and interoperability, while a few closed integrations use raw MQTT on their own topics. Keep the namespaces separate and document which convention governs which topics.
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.