When an MQTT client connects, it tells the broker whether to start fresh or to pick up where it left off. That single choice - clean session versus persistent session - decides whether the broker remembers the client's subscriptions and holds onto messages while the client is offline. For a device on a reliable link the difference is easy to overlook, but for a cellular SCADA gateway that keeps dropping and reconnecting, it is one of the most consequential settings in the whole connection. This guide explains what the flags do in both MQTT 3.1.1 and MQTT 5, how they govern reconnect behavior, and how they interact with retained messages and the last will.
Clean vs Persistent Session in one line: The clean-session flag in MQTT 3.1.1 (called clean-start plus a session-expiry interval in MQTT 5) decides whether the broker keeps state for a client between connections. A clean session tells the broker to discard any prior state and start fresh, so subscriptions and queued messages are forgotten on disconnect. A persistent session tells the broker to remember the client's subscriptions and queue its QoS 1 and 2 messages while it is offline, delivering them on reconnect.
An MQTT session is the state a broker holds about a particular client, tied to that client's identifier. The most important parts of that state are the client's subscriptions - the topics it has asked to receive - and any messages that arrived on those topics while the client was disconnected, held for later delivery. Whether the broker keeps this state across a disconnect is exactly what the clean-session choice controls. It is the difference between a broker that forgets a client the moment it drops and one that keeps a place set for it.
With a clean session, the broker treats each connection as a blank slate. When the client disconnects, the broker throws away its subscriptions and any messages it was holding; when the client comes back, it must resubscribe to everything, and anything published on its topics during the gap is simply gone. This is the right behavior for a client that only cares about live data and can re-establish itself cheaply - a dashboard that just wants whatever is happening now, for instance, has no reason to want a backlog of stale readings on reconnect.
With a persistent session, the broker keeps the client's subscriptions alive across disconnects and, crucially, queues qualifying messages that arrive while the client is away. When the client reconnects with the same identifier and asks to resume, the broker recognizes it, restores its subscriptions without the client having to ask again, and delivers the queued backlog. The client picks up where it left off as though it had never been gone. This is what you want for a device that must not miss data during the inevitable gaps in its connection.
In MQTT 3.1.1, this is a single boolean: the clean-session flag. Set it true and the broker starts fresh and keeps nothing after disconnect; set it false and the broker maintains the session and queues messages while the client is away. The limitation of the 3.1.1 model is that a persistent session, once established, is kept by the broker with no built-in expiry - the state lingers until the client returns or an administrator clears it, which can leave brokers holding sessions and queued messages for clients that may never come back.
MQTT 5 splits the single flag into two more expressive controls. There is a clean-start flag that says whether to begin this particular connection with a fresh session or resume an existing one, and there is a separate session-expiry interval that says how long the broker should keep the session after the client disconnects. This decoupling is genuinely useful: a client can start clean but request that its session be retained for a defined period afterward, so the broker holds its state and queued messages for exactly that window and then discards them automatically if the client has not returned. It solves the 3.1.1 problem of sessions accumulating forever.
The practical upshot is finer control over the trade-off between reliability and resource use. A short session-expiry interval keeps the broker from hoarding state for a client that is gone for good, while a longer one protects a client that is expected to be offline for a while but will come back. Choosing the interval is really a statement about how long a disconnected client's data is worth keeping, which depends entirely on the device and what it monitors.
The setting comes alive in the case a lot of industrial MQTT actually faces: a remote gateway on a cellular link that drops out repeatedly. Cellular coverage at a remote well pad or pipeline site is rarely perfect, and a gateway may lose its connection for seconds or minutes many times a day as signal fades or the network hands off. If that gateway connected with a clean session, every one of those drops would wipe its subscriptions and discard anything published to it during the gap, and every reconnect would be a cold start. Depending on the direction of data flow, that is often a recipe for missing exactly the data the outage window contains.
A persistent session changes the reconnect story completely. The gateway connects with a stable client identifier and a session the broker retains, so when the cellular link drops and comes back, the broker still knows the gateway's subscriptions and has been holding its queued QoS 1 and 2 messages. On reconnect the gateway resumes without resubscribing and receives the backlog that accumulated while it was dark. For a device whose whole job is to not lose field data across a flaky link, this is the behavior that makes MQTT trustworthy - the connection can bounce all it likes, and the data bridges the gaps.
This is exactly why a cloud SCADA platform such as Merobix pairs persistent sessions with appropriate quality-of-service levels for gateways on unreliable connections: together they ensure that a cellular dropout becomes a brief delay rather than a hole in the record. The session choice also interacts with two related MQTT features. A retained message is the broker holding the last value on a topic so a newly subscribing client gets the current state immediately, which complements a persistent session on reconnect. And the last-will message - the notice the broker publishes if the client disconnects ungracefully - works alongside session state to let the rest of the system know a gateway has gone quiet unexpectedly, so an operator learns about a dead link rather than silently trusting stale data.
A clean session tells the broker to start fresh and keep no state after the client disconnects, so subscriptions are forgotten and no messages are queued during the gap. A persistent session tells the broker to remember the client's subscriptions and to queue its QoS 1 and 2 messages while it is offline, delivering them on reconnect. Clean suits clients that only want live data; persistent suits devices that must not miss data across disconnects.
MQTT 3.1.1 uses a single clean-session boolean, and a persistent session it creates is kept indefinitely until the client returns or is cleared. MQTT 5 splits this into a clean-start flag, which decides whether this connection resumes or starts fresh, and a separate session-expiry interval, which sets how long the broker keeps the session after disconnect. This lets a client have its state retained for a defined window and then automatically discarded.
Usually yes, if it must not lose data across the frequent dropouts a cellular link brings. A persistent session, combined with QoS 1 or 2, lets the broker keep the gateway's subscriptions and queue its messages during outages so nothing is lost when the link returns. A clean session would wipe subscriptions and discard queued data on every disconnect, turning each dropout into a potential gap in the record.
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.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.