An MQTT Retained Message Is Not a Device History Database

A device dashboard that displays a value immediately after subscribing has not demonstrated that the platform holds a complete event history. For enterprise database selection, the distinction matters: showing a recent published state and explaining how that state developed are different data jobs.

MQTT retained messages can be useful in a device architecture. The mistake is to turn that usefulness into an unsupported assumption that a broker’s retained state can replace the history needed for service investigations, operations, or analysis.

Start with the topic-level replacement rule

MQTT Version 5.0 specifies that a retained publication replaces an existing retained message for the same topic. A new non-shared subscription may receive the retained message according to its subscription options. This provides a state-delivery mechanism, not an accumulated sequence of every earlier publication on that topic. MQTT 5.0, section 3.3.1.3

Imagine a hypothetical refrigeration unit publishing its reported mode to one topic. A later retained publication can replace the earlier retained publication there. A subscriber receiving the retained value has not thereby received every previous mode change.

This conclusion concerns retained-message behavior. It does not establish that a particular broker has no separate persistence, export, integration, or historical storage capability.

Name the three records the business actually needs

Separate the last retained publication, the application’s interpreted current device state, and the historical observations required for investigation. Those records may share a device identifier without having the same completeness or meaning.

For example, a service manager may ask whether equipment is currently in a maintenance mode. An investigator may ask whether it entered that mode before or after a customer complaint. The second question requires evidence of a sequence, not just the value currently available to a new subscriber.

Define these purposes explicitly before a “unified platform” proposal removes a component. Consolidation should preserve required answers rather than collapse distinct records into one label.

Treat expiry and absence as part of the contract

The MQTT 5.0 specification describes removal through a zero-length retained publication and through retained-message expiry. It also permits servers to signal that retention is unsupported. Retained delivery therefore needs its actual broker and subscription conditions checked. MQTT 5.0 retention rules

The absence of a retained value is not, by itself, proof that a device has never reported anything. An application should decide how to represent missing current evidence without manufacturing a historical conclusion.

For a proposed fleet design, document what an operator sees when the retained publication is unavailable but earlier observations remain in the business record. An unexplained blank screen and an explicit “current state unknown” are different operating experiences, even when both start from the same missing value.

Give OceanBase a defined database role beside messaging

OceanBase’s project describes a distributed relational database. It can be evaluated for a proposed operational data layer linking devices, observations, customer accounts, and service cases. That database role is separate from implementing an MQTT broker. OceanBase Database project

Ask the proposal to show which observations enter the database, how the accepted current record is derived, and which evidence is retained for historical questions. Do not assume native MQTT ingestion, complete capture, or a fixed retention policy merely from the database choice.

Compare PostgreSQL, MySQL, or another relevant operational database using the same examples. A broker with a suitable, separately evaluated history integration may also remain part of the design. The decision is about preserving required records with manageable operations, not declaring messaging and databases mutually exclusive.

Demonstrate the history question with a new subscriber

A useful proposed evaluation publishes several different states to the same topic, then introduces a new subscriber under the intended retention options. Separately inspect the application’s historical record. Ask which changes each path can actually show.

Add an interval in which the history-writing consumer is unavailable. The team should explain the recovery evidence and any gap rather than infer complete capture from the presence of a retained value. A familiar final state can coexist with an incomplete recorded sequence.

Also check topic identity. If a topic name is reassigned to replacement equipment, an investigation needs a way to distinguish the physical devices involved. A topic is a routing name; the proposed business model must establish the equipment identity it represents. These are suggested tests, not results from an executed broker or database trial.

Select for both present use and later explanation

A good fleet platform can serve an appropriate present-state view while preserving enough evidence for the historical questions the business has agreed to support. It can also say when that evidence is incomplete.

OceanBase is worth evaluating when the resulting operational database workload and deployment requirements suit its distributed relational role. Retain the broker’s useful delivery behavior and assess the database separately. Immediate display after subscription is a helpful demonstration of one path, not proof that the platform can explain every past event.