The Industrial IoT Blog

If you work in industrial manufacturing and you’re looking at MQTT, you’ve probably heard about Sparkplug B. You might be wondering: Is it really faster? Does it use less bandwidth? Is it worth the extra complexity? I’ll walk you through what I’ve actually seen in real projects, not just what the spec sheets say.

Why This Matters

MQTT is everywhere in industrial IoT. It’s lightweight, reliable, and works great for machine-to-cloud communication. But in its plain form, MQTT leaves a lot of choices up to you — how you structure topics, what your payloads look like, and how you keep track of device state. That’s both a blessing and a curse.

Sparkplug B steps in to standardize all that. It defines how topics are organized, how payloads are encoded (using Google Protocol Buffers), and even how devices signal their state. Sounds great, but does it actually perform better in the real world?

Plain MQTT: Flexible but Messy

In my early MQTT projects — think 2018, mostly in automotive — we started with “vanilla” MQTT. We’d connect PLCs, SCADA systems, and sometimes cloud analytics using brokers like Mosquitto or cloud services. Payloads were usually JSON. It worked, but we ran into a few issues:

• Payload Bloat: JSON is easy to read but not efficient. A simple temperature reading like {"sensorId":32,"sensorValue":24.5} is 36 bytes, but the real data is just a handful of bytes. On busy networks, this adds up fast, especially if you’re sending thousands of tags every second.
• No Standard Structure: Each integration team would invent their own topic and payload conventions. It was a nightmare to keep things consistent, especially when scaling across multiple plants or vendors.
• State Management: If a device dropped offline, it wasn’t always obvious. We had to bolt on our own “heartbeat” logic to know if data was stale.

Honestly, for small projects or proof-of-concepts, plain MQTT is fine. But as soon as you try to scale — say, connecting 20+ lines or multiple sites — the cracks start to show.

Sparkplug B: Standardized and Efficient

When I got to know Sparkplug B (around 2023), things changed. Here’s what I noticed:

1. Payload Compression: Protocol Buffers vs JSON

Sparkplug B uses Protocol Buffers (protobuf) instead of JSON. This is a binary format, not human-readable, but much more compact.

In side-by-side tests, protobuf payloads were typically 60–80% smaller than the equivalent JSON payloads for the same data. For example, a batch of 50 tag updates that took 2,000 bytes in JSON dropped to 400–600 bytes with protobuf.

In large-scale deployments (think 10,000+ tags updating every second), this led to real-world bandwidth reductions of 30–70%, depending on the data model and reporting frequency.

2. Message Batching

Sparkplug B lets you batch multiple tag updates into a single message. With plain MQTT, you often send one message per tag. With Sparkplug B, you might send 100 tags in one shot. This reduces broker overhead and network chatter, especially over cellular or constrained links.

3. State Awareness and Reliability

Sparkplug B is “stateful.” Devices publish a “birth certificate” when they come online and a “death certificate” when they disconnect (or lose connection). This is a huge deal for operations — you always know if your data is fresh, and you can automate alarms if a device goes offline.

4. Latency and Throughput

I’ve seen Sparkplug B and plain MQTT both deliver sub-100ms end-to-end latency on a well-designed network. The difference is usually negligible for most industrial applications, unless you’re doing ultra-low-latency control (which, honestly, you shouldn’t be doing over MQTT anyway). Sparkplug B’s batching and compact payloads mean you can push more data through the same network.

Real-World Example

I’ve seen Sparkplug B across multiple manufacturing sites, each with 10–30 production lines and hundreds of PLCs.

• Before Sparkplug B: Each line published JSON payloads over plain MQTT. Network usage was spiky, and we regularly hit bandwidth limits during shift changes or batch transitions. Device state tracking was manual — lots of custom scripts.
• After Sparkplug B: Consistent 50–60% reduction in network traffic. Device state was visible in the SCADA system out-of-the-box. Integration with new lines was faster because everyone spoke the same language (topic structure, payload, state management).

The biggest win isn’t just performance — it is operational simplicity, spending less time troubleshooting “is this device alive?” and more time actually improving the process.

Downsides and Gotchas

I have to be honest: Sparkplug B isn’t perfect.

• Complexity: Protobuf is binary. Debugging on the wire is harder than with JSON. You need the right tooling to inspect messages (Wireshark decoders, etc.).
• Learning Curve: Teams used to “just send some JSON” need to learn the Sparkplug way: topic conventions, birth/death messages, and protobuf schemas. This takes some upfront investment.
• Not Always Needed: For small, isolated projects, the extra overhead may not be worth it. If you’re just connecting a handful of sensors, plain MQTT is simpler and gets the job done.
• Reliability (The QoS 0 Dilemma): The Sparkplug B spec enforces QoS 0 (“fire and forget”). That means the publisher sends data and moves on — no delivery guarantee. In theory, this gives you maximum speed. In practice, it means you can lose data if the network hiccups or the broker restarts. For regulated environments (where every temperature reading matters), this is a big risk. With plain MQTT, you can choose your Quality of Service: QoS 0, 1 (“at least once”), or 2 (“exactly once”). If you absolutely can’t lose data, you use QoS 1 or 2 — at the cost of some performance. Some brokers (like HiveMQ) try to help by adding memory caching and duplicate detection, but they can’t override the Sparkplug spec. If you need bulletproof reliability, Sparkplug B is a risk unless you build extra safeguards (like store-and-forward at the edge, or custom retry logic).

My Opinion

If you want speed, data consistency, and easy device onboarding — and you can tolerate some data loss (or you have other ways to recover it) — Sparkplug B is fantastic. It’s especially good for real-time dashboards, OEE, and non-critical analytics.

If you need absolute reliability (compliance, traceability, regulated environments), plain MQTT with higher QoS is safer, but you’ll have to invest more in data modeling, integration, and testing.

Honestly, I wish Sparkplug B would support higher QoS levels natively. Until then, you have to pick your poison: speed and standardization vs. reliability and flexibility. Most large manufacturers I’ve worked with end up using both — Sparkplug B for most telemetry, plain MQTT (or even other protocols) for the critical stuff.

Final Thoughts

Don’t just look at benchmarks — test both protocols in your real environment, with your real data, and see what breaks. And always plan for the “bad day” scenario: what happens if the network drops, or the broker crashes? That’s where the differences really show up.