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.
Copy file name to clipboardExpand all lines: blog/mqtt-broker-selection/mqtt-broker-selection.md
+73-43Lines changed: 73 additions & 43 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,36 +2,43 @@
2
2
3
3
## Introduction
4
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 evergrowing 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.
5
+
SuperMQ is 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. A use case for the platform is 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 analytical 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.
6
6
7
7
## The contenders
8
8
9
-
Based on popularity and size we can narrow down the search for a broker into the following:
9
+
Based on popularity and size, we can narrow down the search for a broker to the following:
10
10
11
-
1. EMQX
12
-
2. Mosquitto
13
-
3. NanoMQ
14
-
4. VerneMQ
11
+
1.[EMQX](https://github.com/emqx/emqx) - Released in 2012. Written in Erlang
15
12
16
-
The above represent the brokers with the most influence in the open source community based on their Github stars and contributions.
17
-
As SuperMQ also has an internal message broker two more contenders are introduced which are primarily message brokers but offer support for MQTT
13
+
2.[Mosquitto](https://github.com/eclipse-mosquitto/mosquitto) — Released in 2009. Written in C/C++
18
14
19
-
5. RabbitMQ
20
-
6. NATS
15
+
3.[NanoMQ](https://github.com/nanomq/nanomq)—Released in 2020. Written in C
16
+
17
+
4.[VerneMQ](https://github.com/vernemq/vernemq)— Released in 2014. Written in Erlang
18
+
19
+
The above represent the brokers with the most influence in the open-source community based on their GitHub stars and contributions.
20
+
21
+
As SuperMQ also has an internal message broker, two more contenders are introduced, which are primarily message brokers but offer support for MQTT.
22
+
23
+
5.[RabbitMQ](https://github.com/rabbitmq)—Released in 2007. Written in Erlang
24
+
25
+
6.[NATS](https://github.com/nats-io)—Released in 2011. Written in Go
21
26
22
27
## The criteria
23
28
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:
29
+
To choose a broker, a set of analytical criteria was established. The main goal was to make sure we did not compromise the SuperMQ offering but instead enriched it. For our consideration we will define the following:
25
30
26
31
### Distribution and licensing
27
32
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.
33
+
SuperMQ is an open-source project licensed under Apache 2.0; therefore, any broker we use for our infrastructure should have the same commitment to open source.
34
+
35
+
From the list of our contenders, RabbitMQ, VerneMQ, and NATS have an Apache 2.0 license. Although VerneMQ has 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 Eclipse 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 favor of the projects with Apache and MIT licenses. This metric serves as a non-negotiable for our project.
30
36
31
37
### MQTT protocol compliance and features
32
38
33
-
The MQTT protocol has features set out by the [MQTT specifications](https://mqtt.org/mqtt-specification/)
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)
39
+
The MQTT protocol has features set out by the [MQTT specifications.](https://mqtt.org/mqtt-specification/)
40
+
41
+
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. For SuperMQ having the latest version of MQTT is a non-negiotable.
50
+
From the above there is little to separate the brokers, each having a strong implementation of the specifications. However, NATS stands out because of its 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 non-negotiable.
44
51
45
52
### Performance
46
53
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.
54
+
This can be characterized by the number of connections supported, message throughput, and latency. This stands as a key metric of making SuperMQ highly performant.
55
+
56
+
Performance data for a comparison between our contenders is obtained from a combination of third-party evaluations of the brokers as well as vendor-based benchmarks.
57
+
58
+
In terms of the number of connections supported, vendor-based benchmarks 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].
48
59
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
60
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].
61
+
62
+
A third-party benchmark puts the sustainable message throughput of EMQX at 28K messages per second, while that of VerneMQ is 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].
63
+
64
+
A vendor-based benchmark provided by RabbitMQ puts the message throughput at 17K messages per second, having an average forward latency of 2.880 milliseconds [2].
65
+
54
66
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].
67
+
68
+
From vendor-based benchmarks, NanoMQ is reported to have lower latency than EMQX and VerneMQ at lower numbers of active connections but higher latency at higher numbers of active connections [4].
69
+
56
70
The same benchmark puts the latency of Mosquitto to be higher than EMQX and NanoMQ.
57
71
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.
72
+
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
73
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.
74
+
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
75
62
-
With SuperMQ we wanted a highly performant broker and EMQX, VerneMQ and RabbitMQ seem to be top of the pile.
76
+
With SuperMQ we wanted a highly performant broker, and EMQX, VerneMQ, and RabbitMQ seem to be at the top of the pile.
63
77
64
78
### Scalability
65
79
66
-
Here we were looking for a broker that offers high availabilty and clustering, all this while maintaining effecient resource consumption.
80
+
Here we were looking for a broker that offers high availability and clustering, all while maintaining efficient resource consumption.
67
81
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.
82
+
Two of our contenders fail at this point, as Mosquitto and NanoMQ do not support clustering, which is important in our mission to make a distributed and scalable platform.
69
83
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.
84
+
EMQX natively supports clustering. VerneMQ is built as a distributed message broker with masterless clustering technology based on Erlang distribution.RabbitMQ supports clustering as a logical grouping of nodes that share users,virtual hosts, queues, streams, exchanges, bindings, and other distributed states.
71
85
72
-
Each of our contenders boast of their high availabilty and fault tolerance.
86
+
Each of our contenders boasts of their high availability and fault tolerance.
73
87
74
-
In terms of resource consumption thirdparty 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].
88
+
In terms of resource consumption, third-party studies concur on Mosquitto being lightweightwith low RAM usage.The study highlights that VerneMQ and EMQX are similar in their CPU and memory use [5].
75
89
76
90
### Security
77
91
78
-
The broker should offer inbuild or pluggable options for Authentication and Authorization as well as support for TLS encryption.
92
+
The broker should offer built-in or pluggable options for authentication and authorization as well as support for TLS encryption.
79
93
80
94
All the contenders offer support for TLS/SSL.
81
95
82
-
EMQX, RabbitMQ, VerneMQ and NATS offer high pluggability when it comes to authentication and authorization.
96
+
EMQX, RabbitMQ, VerneMQ, and NATS offer high pluggability when it comes to authentication and authorization.
83
97
84
-
This serves as nice to have as SuperMQ relies on [Mgate](https://github.com/absmach/mgate)for authentication and authorization for client connections.
98
+
This serves as a nice-to-have, as SuperMQ relies on [Mgatefor authentication and authorization for client connections.
85
99
86
100
### Management and monitoring
87
101
88
-
Support for observability and metrics is another musthave for building this highly scalable platform.
102
+
Support for observability and metrics is another must-have for building this highly scalable platform.
89
103
90
-
EMQX, RabbitMQ, VerneMQ, NATS natively support export prometheus metrics.NanoMQ and Mosquitto do not support this natively but we have found thirdparty extensions for this.
104
+
EMQX, RabbitMQ, VerneMQ, and NATS natively support exporting Prometheus metrics.NanoMQ and Mosquitto do not support this natively, but we have found third-party extensions for this.
91
105
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.
106
+
EMQX offers a web-based dashboard for monitoring of clusters.The dashboard is nice to have, but SuperMQ already has metrics visualization methodologies.
93
107
94
-
All the brokers save for Mosquitto offer HTTP API for configuration and monitoring which is very nice.
108
+
All the brokers, save for Mosquitto, offer HTTP API for configuration and monitoring, which is very nice.
95
109
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.
110
+
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
111
98
112
## Conclusion
99
113
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.
114
+
Choosing a broker for the platform is an important decision, one that has to be made analytically. In terms of performance, with the available information, RabbitMQ, VerneMQ, and EMQX come up as favorites. As we would like a scalable solution, we have to eliminate NanoMQ and Mosquitto. These brokers seem to be built to be performant on single-node deployments on the edge. Finally, our commitment to open source means we eliminate VerneMQ and EMQX.
115
+
116
+
We chose RabbitMQ because:
117
+
118
+
- It is committed to open source: As an Apache 2.0 licensed project
119
+
120
+
- It displays exceptional scalability and distributed architecture: RabbitMQ's robust clustering capabilities are paramount for SuperMQ, which is designed for high availability and distributed operations.
121
+
122
+
- It has proven performance: While other contenders also showed strong performance, RabbitMQ's benchmarks for message throughput and low latency are impressive and fully capable of meeting SuperMQ's demanding performance requirements [6].
123
+
124
+
- It has comprehensive management and monitoring: RabbitMQ offers native support for Prometheus metrics, alongside an HTTP API for configuration and monitoring. These features integrate with SuperMQ's existing observability methodologies, providing the visibility and control necessary for operational excellence.
125
+
126
+
- It has security integration: It supports TLS/SSL and has highly pluggable authentication and authorization mechanisms that align with SuperMQ's security architecture.
102
127
103
128
## References
104
129
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)
130
+
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)
131
+
132
+
2.[Native MQTT in RabbitMQ](https://www.rabbitmq.com/blog/2023/03/21/native-mqtt)
133
+
107
134
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)
135
+
136
+
4.[Open MQTT benchmarking comparison of MQTT brokers](https://www.emqx.com/en/blog/open-mqtt-benchmarking-comparison-mqtt-brokers-in-2023)
137
+
109
138
5.[Stress-Testing MQTT Brokers: A Comparative Analysis of Performance Measurements](https://www.mdpi.com/1996-1073/14/18/5817)
139
+
110
140
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