Comparison of MQTT Support by IoT Cloud Platforms

Comparison of MQTT Support by IoT Cloud Platforms

author HiveMQ Team

Written by 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.

Learn about MQTT Protocol

Get the MQTT Essentials eBook

72 pages of MQTT education and learning for beginners and experts alike.

Deviations from Specification

Basic MQTT features such as QoS 2, Retained Messages and guaranteed message ordering are often used to implement business critical systems. In order to be MQTT compliant these features are not optional but mandatory, which means cloud platforms that do not support these features are not compliant to the MQTT specification. HiveMQ provides support for MQTT 3.1, MQTT 3.1.1 and MQTT 5. In fact, HiveMQ has supported MQTT 5 since December 2018.

What does this mean for you as a user of these cloud platforms that do not support MQTT 5 features? You will miss out on critical features such as shared subscriptions, session and message expiry, topic aliases, user properties and negative acknowledgements. These features are essential for successful deployments of mission critical user cases in key industries, such as manufacturing.

AWS IoT Core announced support for MQTT 5, but they do not support shared subscriptions. 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 yes no yes
QoS 2 Support no no yes
QoS 0 Support Non conformance to specification [1] yes yes
Retained Messages yes no yes
Guaranteed message ordering no yes yes
Direct access to messages after a successful subscription Possible delay between subscription and receipt of messages [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) yes 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] When a client subscribes to a topic, there might be a delay between the time the message broker sends a SUBACK and the time the client starts receiving new matching messages.

[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

author HiveMQ Team

About HiveMQ Team

We love writing about MQTT, IoT protocols and architecture in general. Our experts are here to help, so reach out to us if we can help!

mail icon Contact HiveMQ
newer posts Building a Reliable and Scalable IoT Platform
IoT on the Edge with HiveMQ older posts