Comparison of MQTT Support by IoT Cloud Platforms

Written by The HiveMQ Team

Category: HiveMQ Cloud IoT Cloud MQTT

Published: May 12, 2020


The success of MQTT can be measured by the widespread adoption by the different IoT cloud vendors. However, support for MQTT is not always equal across the cloud vendors. In fact, Microsoft states clearly on its website that:

“IoT Hub is not a full-featured MQTT broker and does not support all the behaviors specified in the MQTT v3.1.1 standard.”

Open standards are important to avoid vendor lock-in. If a vendor partially supports a standard like MQTT then it is one step towards vendor lock-in. For this reason, we think it is interesting to evaluate the support of MQTT by some IoT cloud vendors, including AWS IoT, HiveMQ Cloud, and MS Azure IoT.

The following is the detailed analysis based on the documentation available for each of these vendors.

Deviations from Specification

Both AWS and Microsoft lack support of basic MQTT features such as QoS 2, Retained Messages and guaranteed message ordering. These MQTT features are often used to implement business critical systems. In fact, in order to be MQTT compliant these features are not optional but mandatory, which means neither AWS nor Microsoft Azure IoT Hub are compliant to the MQTT specification. HiveMQ provides support for MQTT 3.1, MQTT 3.1.1 and MQTT 5.

The other major deviation with AWS IoT and MS IoT is the lack of MQTT 5 support, which became the current MQTT standard in March 2019. Neither vendor has announced any intention to support MQTT 5. HiveMQ has supported MQTT 5 since December 2018. The lack of MQTT 5 support means users of AWS and MS services will miss out on critical MQTT 5 features such as shared subscriptions, session and message expiry, topic aliases, user properties and negative acknowledgements. These MQTT 5 features are essential for successful deployments of mission critical user cases in key industries, such as manufacturing.

Microsoft Azure IoT support for topic names and topic filters is very limited. From the Microsoft document:

“Since IoT Hub is not a general-purpose pub-sub messaging broker, it only supports the documented topic names and topic filters.”

It would appear all MQTT messages in Azure IoT need to be from a topic namespace of

devices/{device_id}/messages/events

This greatly reduces the flexibility of designing a topic namespace to fit the organizations IoT use case. It also tightly ties the IoT application to Azure IoT.

Finally, it is important to consider the SDKs that can be used to connect devices to each service. HiveMQ Cloud and MS Azure allow for open source MQTT client SDKs (ex. Eclipse Paho) to be used to connect to their service. AWS IoT only supports device connectivity using the AWS IoT SDK. MS also has the MS IoT SDK to connect to the MS Azure IoT Hub. Restricting device connectivity to the cloud services via a proprietary vendor SDK limits the options for changing the MQTT cloud service at a later date.

Deviations from MQTT Specification

Feature AWS IoT MS Azure IoT Hub HiveMQ Cloud
MQTT 5 no no yes
QoS 2 Support no no yes
QoS 0 Support Non conformance to specification [1] yes yes
Retained Messages no no yes
Guaranteed message ordering no yes yes
Direct access to messages after a successful subscription no
[2]
yes yes
Topic Filter No restrictions # and + are not supported No restrictions
Topic namespace restrictions No restrictions Topic structure limited [3] No restrictions
Compatibility with standard MQTT client libraries (ex. Eclipse Paho) No
(Requires Amazon IoT SDK)
Limited Use [4]
(Preferred connectivity via MS Azure SDK)
yes
[1] AWS IoT QoS is defined as delivered zero or more times. MQTT 3.1.1 spec defines QoS 0 as at most once delivery.

[2] The AWS IoT MQTT message stream is not guaranteed to be received directly after a SUBACK packet is received by a client, which is a MQTT protocol violation. MQTT clients might miss out on very important messages they should already receive.

[3] Topic need to follow specific format of 'devices/{device_id}/messages/events'

[4] Microsoft has a very restrictive way that you can use a MQTT library.

Limitations of MQTT support

AWS IoT and MS Azure IoT impose a number of limitations on their MQTT broker that restrict the potential use cases for their services.

Both AWS and MS make it impossible to create an MQTT client back-end consumer service that could subscribe to all the messages in the system so they can be stored in a database or another enterprise system. AWS limits each client to 100 publish events per second and throughput of 512kb/second/connection. MS limits the publishing rate to 120 events/sec/unit and throughput is limited to 300MB per device stream. A scalable back-end MQTT client consumer service would require much higher rate limits. In addition the lack of MQTT 5 Shared Subscriptions makes it even more difficult to implement. The integration with other backend services must be done using the AWS or MS proprietary event handle services, which locks companies into proprietary cloud functionality.

AWS IoT restricts the QoS 1 retry interval to 1 hour meaning if a device was offline for more than an hour, the message would not be received. For many enterprise IoT use cases, like connected cars that can go offline for extended periods of time, it is unacceptable to lose messages after a period of time. This limitation effectively makes QoS 1 support in AWS IoT non-functional.

AWS and MS limits the size of the MQTT message. AWS limits messages size to 128kb and MS limits messages size device to cloud at 256kb and cloud to device at 64kb. The MQTT specification specifies the MQTT message size limit to be 256MB. HiveMQ supports the MQTT specification of 256MB.

MQTT Limitations

Limitation AWS IoT MS Azure IoT Hub HiveMQ Cloud
QoS 1 retry interval 1 hr unlimited unlimited
Publish request per second per client 100 120/second/unit
6000/second/unit
at higher price level
unlimited
Subscriptions per connection 50 Limit depends on pricing unlimited
Cloud to device message queue unlimited 50 unlimited
Throughput 512kb/sec/connection 300MB/day unlimited
Message Size 128kb 256kb device to cloud
64kb cloud to device
unlimited

Conclusion

MQTT is a widely used and accepted ISO IoT standard. Standardization of functionality across vendors is one of the key success factors for MQTT, as this protects customers from vendor lock-in of their IoT devices, which are very often part of a company’s value chain. Unfortunately, not all MQTT cloud services have implemented the entire specification and are not MQTT compliant since they lack mandatory features that are required to implement the MQTT 3.1.1 standard. These deviations from the MQTT standard often lead to using the vendor’s proprietary IoT SDKs to send the MQTT message. The use of proprietary SDKs promote vendor lock-in and makes it difficult to switch MQTT cloud services at a later point in time. Open standards are important to avoid vendor lock-in but incomplete implementations of open standards might lead to vendor lock-in.

Cavest emptor - Buyer beware

About The HiveMQ Team

Ian is Head of Marketing for HiveMQ.
Contact Ian

HiveMQ 4.3.3 released
IoT on the Edge with HiveMQ