For most industrial telemetry, QoS 1 is the practical starting point. It reduces the risk of losing a message on an MQTT delivery hop, but the receiving system must tolerate duplicates. Use QoS 0 when individual readings are replaceable and low overhead matters more than complete delivery. Reserve QoS 2 for flows where duplicate delivery on that hop is unacceptable and the added protocol exchange is justified.
None of these choices guarantees a complete historian. MQTT Quality of Service controls delivery between one sender and one receiver. It does not prove that a payload was parsed correctly, assigned the right timestamp, written once, and committed to durable storage.
What MQTT QoS actually controls
The OASIS MQTT 5.0 standard defines QoS for a single delivery flow. A device publishing to a broker is one flow. The broker sending the message to a subscribing collector is another. The broker can deliver at a different QoS from the one used by the publisher, depending on the original publication and the subscriber’s granted maximum QoS.
This boundary matters in a historian pipeline. A publisher may deliver a message successfully to the broker, while the collector is disconnected. The collector may receive it successfully, while mapping rejects the payload. MQTT has completed its part even though no usable historian row exists.
| Level | Delivery semantics | Protocol work | Main risk | Typical industrial fit |
|---|---|---|---|---|
| QoS 0 | At most once | PUBLISH, with no acknowledgement or protocol retry | A message can be lost | Frequent, replaceable telemetry where occasional gaps are acceptable |
| QoS 1 | At least once | PUBLISH plus PUBACK | A message can be delivered more than once | Most telemetry where loss matters and duplicates can be handled |
| QoS 2 | Exactly once within that sender-receiver flow | PUBLISH, PUBREC, PUBREL, and PUBCOMP | More state and protocol overhead | Selected flows where duplicate delivery on the MQTT hop is unacceptable |
QoS 0: low overhead, accepted loss
At QoS 0, the sender does not wait for an MQTT acknowledgement and does not retry through the QoS protocol. If a connection fails while a message is in transit, that message may never reach the receiver.
This can be a reasonable choice for a vibration gateway publishing a new summary every second when the application uses trends and can tolerate an occasional missing interval. It is a poor choice when each message represents a completed batch, an operator action, or another non-repeating fact.
Do not choose QoS 0 only because the source publishes quickly. First determine whether each reading is replaceable. A later temperature sample may make a missing earlier sample tolerable for a live dashboard, but it does not reconstruct that earlier value for an audit or event investigation.
QoS 1: reliable delivery with duplicates
QoS 1 requires the receiver to acknowledge the PUBLISH with PUBACK. If the connection breaks before the acknowledgement arrives and the existing session is resumed, the sender must retransmit the unacknowledged PUBLISH after reconnecting. This improves delivery assurance on that MQTT hop, but it also means the receiver may receive the same application message more than once.
For many industrial pipelines, QoS 1 is the best tradeoff. A site gateway can resend after an interruption, while the ingestion path uses a stable event identifier, source timestamp, sequence number, or another application key to recognize repeats. Without such a key, a retry can become two historian rows or two applications of the same counter update.
The MQTT DUP flag is not a complete business-level deduplication key. It describes a retransmitted MQTT packet in a protocol flow; it does not identify equivalent payloads created by a publisher retry, connector restart, or database retry.
QoS 2: exactly once does not reach the database
QoS 2 uses a two-stage acknowledgement process. The sender and receiver retain protocol state so the receiver processes the application message once for that MQTT flow. That is a stronger delivery contract than QoS 1, with more packets, state, and recovery work.
The guarantee stops at the MQTT receiver. Suppose a collector accepts a QoS 2 message, acknowledges it, transforms its JSON, and then loses its database connection. MQTT cannot determine whether the database committed the write before the failure. When the collector retries, the database layer still needs an idempotency rule or duplicate policy.
QoS 2 is therefore not a substitute for end-to-end transaction design. Use it when its specific hop-level guarantee is required, not as a general “most reliable” setting.
Connection interruptions require more than a QoS number
QoS 1 and QoS 2 can preserve in-flight protocol work across a reconnect when the client and broker resume the same session. In MQTT 5.0, Clean Start and Session Expiry Interval control whether Session State continues after the network connection ends. Broker capacity and administrative policy still limit stored state.
Three other mechanisms solve different problems:
- A retained message gives a new subscriber the broker’s latest retained value for a topic. It is not a backlog or a time series.
- A persistent session can preserve subscriptions and eligible pending or unacknowledged messages for an offline subscriber. It does not capture data the publisher never delivered to the broker.
- Local buffering stores data at the device, gateway, or collector for later replay. It protects a different failure boundary and needs capacity, expiry, ordering, and duplicate rules.
A robust design states where buffering exists on both sides of the broker and what happens when each buffer fills.
A practical selection method
Start with the engineering requirement, then select the lowest QoS that meets it.
- Classify the payload. Decide whether it is a replaceable measurement, a cumulative reading, a state transition, or a unique event.
- Define acceptable loss and duplication. “Reliable” is not a test condition; specify how many missing or repeated records are acceptable.
- Map every failure boundary. Include the publisher, network, broker, subscriber, transformation process, and database.
- Check source identity. Add a source timestamp, sequence number, or stable event ID when downstream deduplication or replay requires it.
- Test interruption and recovery. Disconnect each component, exhaust queues, reconnect, and compare source messages with committed historian rows.
Applying the decision with TDengine
TDengine documents an Enterprise MQTT ingestion connector that subscribes to broker topics and writes mapped data into TDengine. Its current ingestion configuration supports MQTT 3.1.1 and 5.0 and lets engineers configure the subscribed topic and QoS. This inbound connector is separate from TDengine’s outbound MQTT publishing capability.
When MQTT data is stored in TDengine TSDB, the protocol setting remains only one part of the path. Topic parsing, payload extraction, table mapping, timestamps, exception handling, and database-write behavior determine whether a delivered message becomes useful history. Select QoS together with those downstream rules, then validate the complete path under failure, not just the broker connection.
