MQTT Quality of Service describes how a message is delivered between one client and the broker. It does not describe the quality of an entire application, and a higher number is not automatically a better choice.
The right QoS begins with a business question: what happens if this message is lost, duplicated, delayed, or processed twice?
QoS applies to each hop
QoS is negotiated independently on the publishing and subscribing sides.
A publisher may send at QoS 1, while a subscriber requested QoS 0. The broker delivers using the lower level available for that subscription. Likewise, a QoS 2 publish does not make a database transaction or physical actuator exactly once. It only defines the MQTT exchange on that network hop.
Treat the complete path separately:
device → broker → consumer → database or actuator
Every arrow and every processing step can fail in a different way.
QoS 0: at most once
QoS 0 sends a PUBLISH without an acknowledgment. The message may arrive once or may be lost.
Use it for data that is:
- frequent;
- replaceable by a newer sample;
- inexpensive to lose occasionally;
- more valuable with low latency and low overhead.
Examples include a temperature reading every second, a live cursor position, or a high-rate debug metric.
QoS 0 is not unreliable by definition. A healthy TCP connection is already ordered and reliable while it remains connected. QoS 0 simply avoids MQTT-level recovery when the connection fails before delivery is complete.
QoS 1: at least once
QoS 1 requires a PUBACK. If the publisher does not receive it, the message may be sent again. The receiver must accept that duplicates are possible.
QoS 1 is a strong default for:
- alerts;
- state transitions;
- jobs and commands that include an idempotency key;
- measurements where a gap matters;
- events that can safely be deduplicated.
Design the payload for idempotency:
{
"eventId": "01JZ8M7V2BR5H0R9BC2T2N2K0A",
"deviceId": "pump-042",
"type": "pressure.threshold.exceeded",
"occurredAt": "2026-07-27T10:42:18Z",
"value": 9.8,
"unit": "bar"
}
A consumer can record eventId before applying the business effect. If the same event arrives again, it acknowledges the message without repeating the action.
QoS 2: exactly once at the protocol layer
QoS 2 uses a four-part exchange: PUBLISH, PUBREC, PUBREL, and PUBCOMP. Both sides keep state until the handshake is complete.
That cost is justified only when:
- duplicate delivery cannot be handled safely at the application layer;
- the broker and all relevant clients implement QoS 2 correctly;
- added latency, bandwidth, memory, and reconnect state have been measured;
- "exactly once" is required on the MQTT hop itself.
QoS 2 still cannot make a non-transactional side effect exactly once. If a consumer starts a motor and crashes before saving completion, the MQTT handshake cannot determine whether the physical action happened. Business-level idempotency remains necessary.
MQTT QoS comparison: 0 vs 1 vs 2
MQTT QoS 0 vs 1 is primarily a tradeoff between recovery and overhead. QoS 0 sends once without an MQTT acknowledgment; QoS 1 retries until acknowledged and therefore requires consumers to tolerate duplicates. Choose QoS 1 when losing an event matters more than receiving it twice.
MQTT QoS 1 vs 2 is not simply “reliable” versus “more reliable.” QoS 1 uses a two-packet exchange and application-level idempotency; QoS 2 uses a four-packet protocol handshake to prevent duplicate delivery on one MQTT hop. QoS 2 still cannot make downstream side effects exactly once, so most production systems get a simpler and more complete result from QoS 1 plus an event or operation ID.
Use the matrix as a starting point, then verify the decision under the actual network, payload rate, client library, and broker configuration.
| Message | Suggested starting point | Reason |
|---|---|---|
| Sensor sample every second | QoS 0 | The next value replaces a missed sample |
| Device online/offline state | QoS 1 + retained | State matters and duplicates are harmless |
| Alarm event | QoS 1 | Delivery matters; deduplicate by event ID |
| Configuration update | QoS 1 + version | Apply only a newer version |
| Remote command | QoS 1 + operation ID + expiry | Avoid stale execution and duplicate effects |
| Financial or safety-critical action | Do not choose by table alone | Design the end-to-end transaction and safety model |
QoS and offline sessions
QoS 1 or 2 messages may be queued for a persistent session while a subscriber is offline, depending on broker and session settings. This can be useful, but it can also deliver obsolete work.
For commands, add:
- message expiry;
- a command or operation ID;
- the intended device identity;
- a creation time;
- a schema version;
- an acknowledgment topic or result event.
Then bound the broker queue. An unlimited offline queue is not durability; it is an unbounded backlog.
Queue only messages whose business value survives the disconnect. A fresh state snapshot can often replace old telemetry, while an expired command should be discarded. Measure the reconnect backlog per client and across the full fleet so a normal recovery does not overload the broker or downstream consumer.
Test failure, not only success
A useful QoS test interrupts the network at specific moments:
- publish while the connection is healthy;
- disconnect before the acknowledgment returns;
- reconnect with the same session;
- observe whether the message is retried;
- confirm the consumer handles duplicates;
- confirm expired commands are not applied.
Also test a reconnect storm across many clients. QoS state that looks small for one device can become significant across a fleet.
Recommended default
Start with QoS 0 for frequent replaceable telemetry and QoS 1 for meaningful events and commands. Build idempotency into consumers before considering QoS 2.
For the surrounding protocol model, read the MQTT protocol overview. Use the topic design guide to keep permissions and message meaning clear, and review the MQTT security guide before using persistent sessions with production devices. The MQTT tutorial includes copy-ready publish and subscribe commands.