MQTT GUIDE
4 min readMQTT QoS 0, 1 and 2 Explained
MQTT Quality of Service (QoS) sets the delivery guarantee for each message: QoS 0 delivers at most once (fire-and-forget), QoS 1 at least once (may duplicate), and QoS 2 exactly once (handshaked). Higher QoS means stronger guarantees and more overhead.
Not every message needs the same delivery promise. A temperature reading that arrives every second can afford to be dropped occasionally; a command that switches off a pump cannot. MQTT lets the sender pick that promise per message through its Quality of Service (QoS) level.
The three QoS levels
Each level trades reliability against the number of network round-trips it costs. The higher the guarantee, the more packets and broker state involved.
QoS at a glance
| QoS 0 | QoS 1 | QoS 2 | |
|---|---|---|---|
| Guarantee | At most once | At least once | Exactly once |
| Duplicates possible | No | Yes | No |
| Packets per message | 1 | 2 | 4 |
| Relative overhead | Lowest | Medium | Highest |
| Queued for offline clients | No | Yes (persistent session) | Yes (persistent session) |
Choosing a level
Match the level to the message's value. Use QoS 0 for high-frequency sensor data where the next value is seconds away; QoS 1 for telemetry and state changes that must reach the backend but can be de-duplicated; and QoS 2 for the small subset — financial events, actuation, billing — where duplicate processing causes real harm. Most fleets run QoS 1 as the default and reserve QoS 2 for the few messages that need it.
One subtlety: QoS 1 and QoS 2 messages are only queued for an offline client when that client uses a persistent session. With a clean session, undelivered messages are discarded on disconnect regardless of QoS.
QoS in TBMQ
TBMQ supports all three QoS levels. When a publisher and subscriber request different levels, TBMQ delivers at the lower of the two — so a QoS 2 subscription does not guarantee exactly-once if the publisher sent at QoS 0 or 1.
For durability, TBMQ acknowledges a QoS 1 or QoS 2 publish only after the message is persisted to its internal Kafka
backbone — so an accepted message survives a broker-node failure. TBMQ's shipped Kafka defaults use
acks=1 and a replication factor of 1, so to also survive the loss of a Kafka node you run a replicated Kafka
cluster. See the QoS reference for the full delivery model and
Sessions for how queued messages are stored per client type.
Frequently asked questions
What are the three MQTT QoS levels?
QoS 0 (at most once) sends a message a single time with no acknowledgement. QoS 1 (at least once) retransmits until the receiver confirms it, so the message always arrives but may duplicate. QoS 2 (exactly once) uses a four-packet handshake so the message is delivered once and only once.
Which QoS level should I use?
Use QoS 0 for frequent, disposable readings where an occasional gap is harmless. Use QoS 1 for data that must arrive and whose consumers can tolerate or de-duplicate repeats — it is the common default. Reserve QoS 2 for messages where duplicate processing would cause real harm, such as billing events or actuation commands.
Does higher QoS mean the message is more secure?
No. QoS controls delivery reliability, not security. Encryption and access control come from TLS, authentication, and topic authorization — a separate layer from QoS.
What happens if the publisher and subscriber use different QoS levels?
The broker delivers each message at the lower of the two levels. A subscriber that subscribes at QoS 2 still only receives QoS 1 if the publisher published at QoS 1, so design for the level actually delivered rather than the level requested.
Is QoS 2 exactly-once guaranteed end to end?
QoS 2 guarantees exactly-once between each pair of hops — publisher to broker, and broker to subscriber. True end-to-end exactly-once requires both the publisher and the subscriber to use QoS 2.
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.