You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 26, 2026. It is now read-only.
SuperMQ promises to be distributed, highly scalable and secure open-source cloud platform. Remember this it will be useful for later. One of thekey pillars of the platform is its multiprotocol support. One possible usecase of the platform would be in the ever growing field of IOT(Internet of Things) and it would be remiss if it did not support one of the most popular protocol in the field, MQTT. To achieve this we had to select an MQTT broker that would work under the hood. The following is a summary of what we considered and eventually who we considered as our broker of choice.
4
+
5
+
SuperMQ promises to be a distributed, highly scalable and secure open-source cloud platform. Remember this, it will be useful for later. One of the key pillars of the platform is its multiprotocol support. One possible usecase of the platform would be in the ever growing field of IOT(Internet of Things). It would therefore be remiss if it did not support one of the most popular protocols in the field, MQTT. To achieve this we had to select an MQTT broker that would work under the hood. Following an analytcal review of the landscape we settled on [RabbitMQ](https://www.rabbitmq.com/). The following is a summary of what we considered and eventually why we chose our broker.
4
6
5
7
## The contenders
8
+
6
9
Based on popularity and size we can narrow down the search for a broker into the following:
10
+
7
11
1. EMQX
8
12
2. Mosquitto
9
13
3. NanoMQ
@@ -16,38 +20,98 @@ As SuperMQ also has an internal message broker two more contenders are introduce
16
20
6. NATS
17
21
18
22
## The criteria
19
-
To choose broke a set of analytical criteria can be set in place to evaluate the choice of brokers. For our consideration we will define the following:
23
+
24
+
To choose a broker a set of analytical criteria were established. The main goal being to make sure we did not compromise the SuperMQ offering but instead enriched it. For our consideration we will define the following:
20
25
21
26
### Distribution and licensing
22
27
23
-
SuperMQ is an open source project licensend under Apache 2.0, therefore any broker we use for our infrastructure should have the same commitment to open source. From the list of our contenders, RabbitMQ, VerneMQ and NATS have an Apache 2.0 license.Though VerneMQ have restrictions on redistributing the docker image as detailed in the [EULA](https://vernemq.com/end-user-license-agreement). NanoMQ has the MIT license which is as permissive as the Apache license but not as explicit. Mosquitto has an Eclipe sula license and EMQX has a Business Source License. These can be limiting to distribution.In the case of SuperMQ it would have to be a point in favour of the projects with Apache and MIT licenses.
28
+
SuperMQ is an open source project licensend under Apache 2.0, therefore any broker we use for our infrastructure should have the same commitment to open source.
29
+
From the list of our contenders, RabbitMQ, VerneMQ and NATS have an Apache 2.0 license.Though VerneMQ have restrictions on redistributing the docker image as detailed in the [EULA](https://vernemq.com/end-user-license-agreement). NanoMQ has the MIT license which is as permissive as the Apache license but not as explicit. Mosquitto has an Eclipe dual license and EMQX has a Business Source License. These can be limiting to distribution. In the case of SuperMQ it would have to be a point in favour of the projects with Apache and MIT licenses. This metric serves as a non-negotiable for our project.
24
30
25
31
### MQTT protocol compliance and features
26
32
27
33
The MQTT protocol has features set out by the [MQTT specifications](https://mqtt.org/mqtt-specification/)
28
-
The broker should offer support for various versions of MQTT(v3.1, v3.1.1 and v5) Furthermore the broker should offer support for varous levels of QoS(Quality of Service), Retained Messages and Last Will and Testament(LWT)
34
+
We would like to offer support for various versions of MQTT(v3.1, v3.1.1 and v5). Furthermore we aim to offer support for various levels of QoS(Quality of Service), Retained Messages and Last Will and Testament(LWT)
From the above there is little to separate the brokers, each having a strong implementation of the specifications. However, NATS stands out because of it lack of support for MQTT v 5.0 and RabbitMQ for its lack of support of QoS 2.
43
+
From the above there is little to separate the brokers, each having a strong implementation of the specifications. However, NATS stands out because of it lack of support for MQTT v 5.0 and RabbitMQ for its lack of support of QoS 2. For SuperMQ having the latest version of MQTT is a non-negiotable.
38
44
39
45
### Performance
46
+
40
47
This can be characterized by the number of connections supported, message throughput and latency. This stands as a key metric of making SuperMQ highly perfomant.
The broker should offer high availabilty and clustering, all this while maintaining effecient resource consumption.
49
-
5. Security
50
-
The broker should offer inbuild or pluggable options for Authentication and Authorization. The broker should also offer support for encryption
51
-
6. Management and monitoring
52
-
The broker should have inbuilt or have plugin in support for observability, metric and logging.
49
+
Performance data for a comparison between our contenders is obtained from a combination of third party evaluation of the brokers as well as vendor based benchmarks.
50
+
In terms of number of connections supported vendor based benchamrks put EMQX, VerneMQ and RabbitMQ in the millions range with EMQX having the edge with a reported support of 4M+ connections per node[1][2].
51
+
Mosquitto and NanoMQ have lower connections per node numbers.
52
+
A third party benchmark puts the sustainable message throughput of EMQX at 28K messages per second while that of VerneMQ at 10k messages per second[3]. From Benchmark comparisons provided by EMQX, we can extrapolate that the message throughputs of NanoMQ and Mosquitto are lower than EMQX and VerneMQ [1].
53
+
A vendor based benchmark provided by RabbitMQ puts the message throughput 17K messages per second having an average forward latency of 2.880 milliseconds [2].
54
+
With VerneMQ and EMQX having a reported latency of 8.7 and 6.4 milliseconds per 1000 messages per second [3].
55
+
From vendor based benchmarks, NanoMQ is reported to have lower latency than EMQX and VerneMQ at lower number of active connections but higher latency at higher numbers of active connections [4].
56
+
The same benchmark puts the latency of Mosquitto to be higher than EMQX and NanoMQ.
57
+
58
+
It is at this point where it is important to note that NanoMQ was authored by EMQ technologies, the authors of EMQX, to be a fast and lightweight broker for the IOT edge.
59
+
60
+
Limited comparison benchmarks are available for NATS as an MQTT broker, we can attribute it to being less popular as compared to our other contenders as an MQTT broker.
61
+
62
+
With SuperMQ we wanted a highly performant broker and EMQX, VerneMQ and RabbitMQ seem to be top of the pile.
63
+
64
+
### Scalability
65
+
66
+
Here we were looking for a broker that offers high availabilty and clustering, all this while maintaining effecient resource consumption.
67
+
68
+
Two of our contenders fail at this point as Mosquitto and NanoMQ do not support clustering, which is important in our attempt to make a distributed and scalable platform.
69
+
70
+
EMQX natively supports clustering. VerneMQ is built as distributed message broker with master-less clustering technology based on Erlang distribution.RabbitMQ spports clustering as a logical grouping of nodes that share users,virtual hosts, queues, streams, exchanges, bindings, and other distributed state.
71
+
72
+
Each of our contenders boast of their high availabilty and fault tolerance.
73
+
74
+
In terms of resource consumption third party studies concur on Mosquitto being light weight with low RAM usage.The study highlights that VerneMQ and EMQX are similar in their CPU and memory use [5].
75
+
76
+
### Security
77
+
78
+
The broker should offer inbuild or pluggable options for Authentication and Authorization as well as support for TLS encryption.
79
+
80
+
All the contenders offer support for TLS/SSL.
81
+
82
+
EMQX, RabbitMQ, VerneMQ and NATS offer high pluggability when it comes to authentication and authorization.
83
+
84
+
This serves as nice to have as SuperMQ relies on [Mgate](https://github.com/absmach/mgate)for authentication and authorization for client connections.
85
+
86
+
### Management and monitoring
87
+
88
+
Support for observability and metrics is another must have for building this highly scalable platform.
89
+
90
+
EMQX, RabbitMQ, VerneMQ, NATS natively support export prometheus metrics.NanoMQ and Mosquitto do not support this natively but we have found third party extensions for this.
91
+
92
+
EMQX offers a web-based dashboard for monitoring of clusters.The dashboard is a nice to have but SuperMQ already has metrics visualization mehodologies.
93
+
94
+
All the brokers save for Mosquitto offer HTTP API for configuration and monitoring which is very nice.
95
+
96
+
In Mosquitto monitoring is mainly through its $SYS topic tree, users subscribe to standard MQTT clients for broker statistics and it relies on third-party tools for more advanced visualization.
97
+
98
+
## Conclusion
99
+
100
+
Chosing a broker for the platform is an important decision, one which has to be made analytical. In terms of performance, with the available information, RabbitMQ, VerneMQ and EMQX come up as favourites. As we would like a scalable solution we have to eliminate NanoMQ and Mosquitto. These brokers seem to be built to be performant on the edge. Finally our commitment to open source means we eliminate VerneMQ and EMQX.
101
+
RabbitMQ emerges as our choice. It has very good performance [6], is highly scalable and offers in built and pluggable management tools for monitoring and authorization. It is disappointing but not detrimental that it does not yet support QoS 2.
102
+
103
+
## References
104
+
105
+
1.[A comprehensive comparison of open source mqtt brokers](https://www.emqx.com/en/blog/a-comprehensive-comparison-of-open-source-mqtt-brokers-in-2023)
106
+
2.[Native mqtt in RabbitMQ](https://www.rabbitmq.com/blog/2023/03/21/native-mqtt)
107
+
3.[A Comparison of MQTT Brokers for Distributed IoT Edge Computing](https://link.springer.com/chapter/10.1007/978-3-030-58923-3_23#citeas)
108
+
4.[Open mqtt benchmarking comparison of mqtt brokers](https://www.emqx.com/en/blog/open-mqtt-benchmarking-comparison-mqtt-brokers-in-2023)
109
+
5.[Stress-Testing MQTT Brokers: A Comparative Analysis of Performance Measurements](https://www.mdpi.com/1996-1073/14/18/5817)
110
+
6.[Using IoT Protocols in Real-Time Systems: Protocol Analysis and Evaluation of Data Transmission Characteristics](https://onlinelibrary.wiley.com/doi/10.1155/2022/7368691)
0 commit comments