Global – October 27, 2026 -- Even QoS 2's exactly-once delivery covers only one MQTT sender-receiver flow, not the subscriber's database transaction, so an MQTT broker cannot serve as an industrial historian. A broker moves messages between publishers and subscribers. A historian keeps time-indexed records that engineers can query, trend and aggregate later.
Broker retention mechanisms fall short of historical storage
A retained message is only the current message for a topic, and a new one normally replaces the prior state. A persistent session preserves subscriptions and eligible queued messages for an offline client. Session expiry, broker capacity, message expiry and administrative policy can all limit what remains.
Broker persistence protects broker state across restarts. It does not define table schemas, engineering timestamps, multi-year retention, SQL queries, aggregates or audit-ready change history.
Four steps after delivery escape MQTT acknowledgement
After a subscriber receives a message, it must accept the correct topic and payload version, and parsing must extract identity, values, units, quality and timestamps. Mapping must then route fields to the intended database, table, columns and tags. The write path must handle timeouts, retries, duplicates and rejected records, and storage must commit the record under an explicit data policy. An MQTT acknowledgement verifies none of these four steps, which is why a "connected" dashboard proves little about stored history.
Five ingestion decisions determine historical integrity
Schema mapping: plain MQTT defines no industrial payload schema, so ingestion must validate payload versions and map fields consistently.
Timestamp selection: broker receipt time, collector processing time and device measurement time can differ, and replayed values may arrive minutes or hours late. The historian needs rules for event time, ingestion time, clock quality, time zone and invalid timestamps.
Duplicate handling: QoS 1 permits duplicate delivery, and application or database retries can add more. A source sequence number, stable event ID or database key separates retransmissions from legitimate repeated values.
Retention and recovery: teams must define buffer limits at the source, broker and collector, plus replay order and recovery evidence.
Query behavior: filtering by asset and time, interval aggregation and gap detection are database responsibilities, not MQTT delivery semantics.
Three-station compressed-air example shows where buffering stops
In the source's example, three compressed-air stations publish pressure, flow, power and compressor state to a central broker. Dashboards and alerting services subscribe for live operations, while a separate ingestion service validates JSON schemas and writes measurements to a historian. If a station loses its upstream connection, neither persistent sessions nor broker queues capture its measurements unless the station or gateway buffers them locally. After reconnection, ingestion must replay in a controlled order, reject invalid payloads visibly and prevent retries from corrupting historical totals.
TDengine connector covers inbound collection only
TDengine documents an Enterprise MQTT ingestion connector that subscribes to broker topics, parses topic and payload fields, maps them to tables and writes them into TDengine. Its outbound MQTT publishing capability is separate. With TDengine TSDB, the broker stays the routing component while the connector and database create durable history.
Five checks validate the pipeline from source to query
Before deployment, teams should record the owner and retention limit of every buffer and compare published counts, subscriber receipts, accepted writes, rejected writes and stored rows. They should interrupt each connection and component to verify replay order, duplicates, gaps and recovery time. Representative periods should be queried by source timestamp to confirm late data lands correctly. Separate alerts should cover broker health, ingestion lag, mapping failures, database write failures and historical gaps.