MQTT GUIDE
3 min readMQTT Persistent Sessions and Clean Start
A persistent MQTT session lets the broker remember a client’s subscriptions and queue its messages while it is offline, so nothing is missed across reconnects. The Clean Start flag (MQTT 5.0) and Clean Session flag (3.1.1) control whether a fresh session is created or an existing one resumed.
Devices drop off networks constantly — a truck enters a tunnel, a sensor's battery dips, a gateway reboots. A persistent session is how MQTT makes those gaps invisible: the broker holds the client's state and its missed messages until it comes back.
How sessions work
A session is the server-side state the broker keeps for a client: its active subscriptions, in-flight QoS 1/2 acknowledgements, and — for persistent sessions — messages queued while it was offline. Whether that state survives a disconnect is what separates a persistent session from a non-persistent (clean) one.
A clean session exists only for the life of the connection: the broker creates it on connect and discards it on disconnect, so the next connect starts from scratch. A persistent session is retained across the disconnect — on reconnect the broker resumes it, the client does not resubscribe, and any messages that arrived while it was offline are delivered in order.
Clean vs persistent at a glance
| Non-persistent (clean) | Persistent | |
|---|---|---|
| MQTT 3.1.1 flag | Clean Session = 1 | Clean Session = 0 |
| MQTT 5.0 | Clean Start = 1 and Session Expiry = 0 | Session Expiry > 0 |
| Subscriptions after disconnect | Discarded | Preserved |
| Offline QoS 1/2 messages | Discarded | Queued, delivered on reconnect |
| Best for | Dashboards, stateless tools | Devices on flaky links, backend consumers |
Persistent sessions in TBMQ
TBMQ stores persistent-session state differently depending on the client type, because devices and backend consumers have very different scaling profiles:
In MQTT 5.0 the session-expiry interval bounds how long an offline session is kept, so stale sessions don't accumulate. For the full model, see the clean vs persistent sessions guide.
Frequently asked questions
What is a persistent session in MQTT?
A session where the broker keeps a client’s subscriptions and queues its QoS 1 and QoS 2 messages while it is offline, then restores everything on reconnect. The client does not need to resubscribe and does not miss messages sent during the outage.
What is the difference between clean session and clean start?
Clean Session is the MQTT 3.1.1 flag: set to 1 for a fresh, non-persistent session; 0 to resume a persistent one. MQTT 5.0 splits that into Clean Start (whether to start fresh on this connect) and a separate Session Expiry Interval (how long the session survives after disconnect).
Do QoS 0 messages get queued in a persistent session?
No. Only QoS 1 and QoS 2 messages are queued for an offline client. QoS 0 messages are never stored — they are discarded if the subscriber is not connected, even in a persistent session.
How long does a persistent session last?
In MQTT 5.0 the Session Expiry Interval controls it: 0 clears the session immediately on disconnect, a number of seconds sets a timed expiry, and the maximum value keeps it indefinitely. In MQTT 3.1.1 a persistent session lives until the client reconnects with Clean Session = 1.
Do persistent sessions use broker storage?
Yes. Retaining subscriptions and queued messages costs storage per client, so at large scale the broker must persist them efficiently. This is exactly what session expiry and per-client-type storage strategies are for.
Run it yourself
TBMQ is a free, open-source MQTT broker built to scale. Spin it up in minutes or try the live demo — no install required.