Differences Between MQTT Version 3 and Version 5

MQTT (Message Queuing Telemetry Transport) is a lightweight communication protocol for the Internet of Things. Version 3 (primarily referring to V3.1.1) and Version 5 are two significant versions. V5 adds a wealth of features on top of V3 to meet the needs of more complex IoT scenarios. Below are the core differences between the two:

1. Protocol Functionality Expansion

Feature	MQTT V3.1.1	MQTT V5
Session and Connection	Only supports basic session (clean session) management.	New session expiry time (Session Expiry Interval): Clients can set the time to retain the session after disconnection (default is permanent), addressing the issue of offline message retention. New connection timeout (Keep Alive) extension: Allows dynamic negotiation of heartbeat intervals.
Message Properties	No message properties, only includes fixed fields (QoS, Retain, etc.).	Introduces message properties: Adds key-value pair properties for connection, publishing, subscribing, etc. (such as message expiry time, topic alias, response topic, etc.), supporting richer business metadata transmission.
Topic Alias	Not supported, topics must be transmitted in full.	Supports topic alias: Clients can map frequently used topics to integer IDs, reducing the transmission of repeated topic strings and saving bandwidth.
Shared Subscription	No standard support, relies on broker extensions (e.g., `<span><span>$share</span></span>`).	Standardized shared subscription: Supports multiple clients sharing the subscription of the same topic (load balancing) to avoid duplicate consumption through `<span><span>$share/<group>/<topic></span></span>` format.
Message Expiry	No expiry mechanism for messages, requires manual cleanup by the broker.	Supports message expiry time (Message Expiry Interval): Clients can set an expiry time when publishing messages, and the broker automatically discards them after expiry, suitable for time-sensitive data (e.g., real-time sensor data).
Enhanced Retained Messages	Only supports a single retained message, which is overwritten when updated.	Supports retained message deletion: Publishing an empty payload with Retain=1 can delete the retained message of the topic; New retained message handling policy: Clients can specify whether to receive retained messages upon subscription.
Request/Response Pattern	No native support, must be manually implemented through topics (e.g., `<span><span>req/</span></span>` + `<span><span>res/</span></span>`).	Native support for request/response: Associates request messages with response messages through `<span><span>Response Topic</span></span>` and `<span><span>Correlation Data</span></span>` attributes, simplifying bidirectional communication.

2. Error Handling and Feedback

Scenario	MQTT V3.1.1	MQTT V5
Connection Failure Feedback	Only returns a simple connection return code (e.g., 0=success, 1=refused), with no specific reason.	New connection return codes (Connect Reason Code): Includes 31 detailed reasons (e.g., “username or password error”, “client ID already exists”), and supports returning custom error messages through attributes.
Subscription Feedback	Only returns whether the subscription was successful, with no specific failure reasons.	Returns subscription return codes (Subscribe Reason Code) upon subscription: Returns results for each subscribed topic individually (e.g., “insufficient permissions”, “topic format error”), allowing clients to know which topics failed to subscribe.
Publishing Feedback	QoS 1/2 only confirms whether the message was delivered, with no business-level feedback.	Supports publishing completion return codes (PubAck Reason Code): The broker or receiving end can return reasons for publishing failure (e.g., “message too large”, “no permission for topic”).

3. Traffic Control and Resource Management

Feature	MQTT V3.1.1	MQTT V5
Maximum Message Length	No protocol limit, determined by broker implementation.	Supports maximum message length negotiation: Clients can declare the maximum message length they can handle when connecting, and the broker will refuse to accept messages exceeding this length.
Maximum Number of Receivables	No limit, which may lead to client overload.	New maximum number of unacknowledged QoS 1/2 messages: Clients can declare the number of unacknowledged QoS 1/2 messages they can handle simultaneously, and the broker will throttle accordingly to prevent client buffer overflow.
Topic Filter Limitations	No limit, which may lead to malicious subscriptions to numerous topics.	Supports maximum subscription topic count: The broker can limit the maximum number of subscriptions for clients to prevent resource abuse.

4. Other Important Differences

Feature	MQTT V3.1.1	MQTT V5
Strict UTF-8 Validation	Loose UTF-8 encoding validation for client IDs, topics, etc.	Strict UTF-8 encoding validation, illegal encodings will be rejected (to avoid parsing errors).
Enhanced Will Message	Will messages only contain topic, payload, QoS, and Retain.	Will messages support message properties (e.g., expiry time) and will delay (Will Delay Interval): After the client disconnects, the broker delays a specified time before publishing the will message (to avoid false triggers due to network fluctuations).
User Properties	No native support, must be embedded in payload.	Supports user properties: Allows adding custom key-value pairs (string type) in all operations such as connection, publishing, and subscribing, for transmitting business metadata (e.g., device model, message priority).

5. Scenario Comparison

MQTT V3.1.1: Suitable for simple scenarios (e.g., low-power devices, bandwidth-limited networks), easy to implement, and has good compatibility (almost all clients and brokers support it).
MQTT V5: Suitable for complex IoT scenarios (e.g., industrial control, vehicle networking, multi-device collaboration), preferred when more precise permission control, error feedback, traffic management, or request/response patterns are needed.

Conclusion

MQTT V5 does not replace V3.1.1 but enhances flexibility, reliability, and functionality on its basis. Migration to V5 requires consideration of client and broker compatibility (e.g., mainstream brokers like EMQX, Mosquitto already support V5) and additional development costs (handling properties, return codes, etc.). For new systems, it is recommended to prioritize using V5 to meet future expansion needs.