Global – October 27, 2026 -- QoS 1 is the practical starting point for most industrial telemetry over MQTT, but none of the three QoS levels guarantees a complete historian, according to engineering guidance tied to the OASIS MQTT 5.0 standard.
QoS 1 reduces the risk of losing a message on an MQTT delivery hop. The receiving system must tolerate duplicates. QoS 0 fits replaceable readings where low overhead matters more than complete delivery. QoS 2 is reserved for flows where duplicate delivery on that hop is unacceptable and the extra protocol exchange is justified.
MQTT QoS covers one sender-receiver hop, not the whole pipeline
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 to a subscribing collector is another, and it can use a different QoS depending on the original publication and the subscriber's granted maximum.
MQTT can complete its part while no usable historian row exists. A collector may be disconnected when the broker receives a message, or payload mapping may reject a message the collector received successfully.
QoS 0 accepts loss and fits only replaceable readings
At QoS 0 the sender does not wait for an acknowledgement and does not retry. A message in transit during a connection failure may never arrive. The guidance names a vibration gateway publishing a summary every second as a reasonable use, provided the application works with trends and tolerates an occasional missing interval.
It is a poor fit for completed batches, operator actions, or other non-repeating facts. A later temperature sample does not reconstruct an earlier value for an audit or event investigation.
QoS 1 retransmits unacknowledged messages and creates duplicates
QoS 1 requires the receiver to acknowledge each PUBLISH with PUBACK. If the connection breaks first and the session resumes, the sender must retransmit. The receiver may therefore see the same application message more than once.
Ingestion paths need a stable event identifier, source timestamp, sequence number, or similar key to recognize repeats. Without one, a retry can produce two historian rows or apply the same counter update twice. The MQTT DUP flag does not serve as a business-level deduplication key. It describes a retransmitted packet, not equivalent payloads from a publisher retry, connector restart, or database retry.
QoS 2 exactly-once delivery stops at the MQTT receiver
QoS 2 uses a two-stage acknowledgement and retained protocol state, at the cost of more packets, state, and recovery work. If a collector acknowledges a QoS 2 message, transforms its JSON, and then loses its database connection, MQTT cannot tell whether the write committed. The database layer still needs an idempotency rule or duplicate policy.
Sessions, retained messages, and local buffers address different failures
In MQTT 5.0, Clean Start and Session Expiry Interval control whether session state survives a network disconnect. Broker capacity and administrative policy still limit stored state.
- A retained message gives a new subscriber the latest value for a topic. It is not a backlog or a time series.
- A persistent session can preserve subscriptions and eligible pending messages for an offline subscriber. It cannot capture data the publisher never delivered to the broker.
- Local buffering at the device, gateway, or collector protects a different failure boundary and needs capacity, expiry, ordering, and duplicate rules.
Five-step method selects the lowest QoS that meets the requirement
The guidance advises engineers to classify the payload as a replaceable measurement, cumulative reading, state transition, or unique event. They should then define acceptable loss and duplication numerically, since "reliable" is not a test condition. Next they map every failure boundary from publisher to database, and add a source timestamp, sequence number, or event ID where deduplication or replay requires it. Finally they disconnect each component, exhaust queues, reconnect, and compare source messages with committed historian rows.
TDengine's MQTT connector supports versions 3.1.1 and 5.0
TDengine documents an Enterprise MQTT ingestion connector that subscribes to broker topics and writes mapped data into TDengine. Its current configuration supports MQTT 3.1.1 and 5.0 and lets engineers set the subscribed topic and QoS. It is separate from TDengine's outbound MQTT publishing capability.
In TDengine TSDB, topic parsing, payload extraction, table mapping, timestamps, exception handling, and database-write behavior determine whether a delivered message becomes useful history.