MQTT 3.1.1 vs MQTT 5 for SCADA: Which to Use

Back to Blog

The Decision in One Paragraph

Both versions share the fundamentals: the same broker model, the same three QoS levels, the same retained messages and last will. What separates them is a layer of refinements in version 5 aimed at robustness and observability. If you are building new and control both ends, standardize on MQTT 5, because the features it adds are precisely the ones that make a flaky cellular fleet easier to run and diagnose. If you have a stable, simple 3.1.1 system that works, the case to migrate is weaker and should be driven by a specific pain the newer features would relieve.

Below is a side-by-side of the differences that matter most for SCADA, followed by where each version still wins and the pitfalls of moving between them.

Feature Comparison Side by Side

The table summarizes the practically important differences. Each MQTT 5 row corresponds to a real field problem, from diagnosing a refused connection to bounding retries on a slow link.

Capability	MQTT 3.1.1	MQTT 5
Failure diagnostics	Limited connection return codes; generic subscribe failure	Reason codes and reason strings across connect, publish, subscribe, disconnect
Session control	Clean session flag only	Clean start plus a session expiry interval
Flow control	None defined	Receive maximum bounds in-flight messages
Server-initiated disconnect	Socket just closes	Broker can send a DISCONNECT with a reason
Message metadata	Payload only	User properties, content type, message expiry, and more
Load balancing consumers	Not standardized	Shared subscriptions
Topic efficiency	Full topic every message	Topic alias sends the string once

Read down the version 5 column and every row maps to something covered elsewhere on this site: the diagnostics of reason codes, controlled reconnection through session expiry and clean start, backpressure via receive maximum, load balancing through shared subscriptions, and lean topics with the topic alias. None is exotic; each removes a specific field headache.

When Each Version Wins

MQTT 5 wins for anything you will commission and support remotely, which is most SCADA. The diagnostics alone justify it: when a gateway three hours away will not connect, a reason code tells you whether it is credentials, a duplicate identifier, or the network, turning a site visit into a config fix. Session expiry gives you controlled behavior across the reconnects a cellular link guarantees, and flow control keeps a slow link from being buried under retries. For a new build with modern client libraries and a modern broker, there is little reason to start on 3.1.1.

MQTT 3.1.1 still wins in a narrow band: a stable, simple system already running well, or a constrained device whose available client library only speaks 3.1.1 reliably. The protocol is mature and widely supported, and if none of the version 5 features solve a problem you actually have, migrating adds risk for little return. Version compatibility is the practical constraint, since a broker and all its clients must support the version you choose, and mixed fleets are where migration pain concentrates.

This version choice is one input into the larger architectural question of whether to run plain MQTT at all or adopt Sparkplug on top of it, which is treated separately in plain MQTT versus Sparkplug. Sparkplug builds on MQTT and benefits from version 5's features, so the two decisions are related but distinct: version 5 versus 3.1.1 is about the transport, and Sparkplug versus plain MQTT is about the payload and lifecycle model layered above it.

Frequently Asked Questions