Top 10 Criteria for Selecting a MQTT Broker


MQTT has become the IoT standard for connecting devices to the cloud. It is clear that MQTT’s publish/subscribe protocol is the best way for connecting devices over unreliable networks. Using HTTP often leads to unreliable data transfer, lost messages, and unresponsive devices waiting to resynchronize with the cloud.

The good news is there are a number of MQTT solutions available in the market. However, as with any new technology space, not all MQTT brokers are equal. For this reason, we have put together a top 10 criteria for selecting an MQTT broker provider.

  1. Does the MQTT solution support the MQTT 3.1, 3.1.1 and MQTT 5 specification? Some providers have been known to say they support MQTT but only really support a subset.
  2. Does the MQTT broker support high availability? How is the broker deployed in a cluster environment? Does the broker support automatic elastic and linear scalability at runtime? How does it recover from network splits?
  3. How does the MQTT solution support disaster recovery? Does the broker persist to disk and not keep data in memory? If one node goes down, are all the sessions still available? If all nodes go down, are there still all session and undelivered messages? Is there a backup and restore feature?
  4. Does the broker perform under a heavy load of publish and subscribe? Make sure you benchmark the broker to match your production scenario. Test difficult use cases, such as no persistence after a restart or no replication (full replication with 2 nodes). Does the MQTT solution have a limit on the number of topics that are supported? Ask for benchmark data from the vendor.
  5. What type of metrics does the broker produce for monitoring? Can you get live stats based on the number of connections, CPU/memory usage? Is it easy to integrate the metrics into dashboard solutions like Grafana, Prometheus, AppDynamics?
  6. What type of management tools are included? Is it possible to query and manage individual client connections? Are their debug tools to create trace recordings to isolate misbehaving clients? Do these features scale-up to work with millions of client connections?
  7. How robust is the security solution? Is TLS/SSL supported natively? Is it possible to integrate device authentication and authorization systems into the MQTT broker? What type of logging and auditing is provided? Is their a role-based permission system built into the solution?
  8. Can you write extensions for the MQTT broker? How robust is the API to allow for extensions? Is there documentation for the SDK? Does the API support hot reload? Is there a marketplace or catalog of extensions?
  9. Who else is using the MQTT broker? Does the supplier have business-critical use cases that will act as references?
  10. What type of support is available? Is there a company willing to provide 7/24 technical support for your deployment? Is the documentation complete and robust?

Not all MQTT brokers are the same.

Be sure to evaluate your brokers based on the above criteria.

This UrIoTNews article is syndicated fromDzone