Which open-source MQTT broker fits your IoT or industrial situation
If your team is choosing a self-hosted MQTT broker for devices and plant or fleet data, the right answer depends on three things: how many nodes you need, how much of a permissive license matters to you, and whether you need a broker you can extend in Java. Eclipse Mosquitto fits lightweight, single-site or edge brokering under EPL-2.0 or BSD-3-Clause. HiveMQ CE fits teams that want a Java broker under Apache 2.0 with an extension SDK, but the community edition does not include clustering. EMQX fits large clustered deployments, provided the Business Source License and the cluster license file are acceptable to your legal and procurement teams.
Mosquitto is the simplest starting point for edge gateways and single-site brokers, and its bridge option in the mosquitto.conf manual connects multiple brokers with TLS or pre-shared-key settings. Its high availability, persistent queuing and integrations sit in Cedalo's commercially licensed Pro Edition, so confirm whether those features are needed before you design a multi-site topology. HiveMQ CE runs on Java 11 or later and is a sound base if your team already operates JVM services, but plan clustering as a separate question. HiveMQ's broker product page lists masterless clustering for the commercial HiveMQ Broker only.
EMQX has the broadest protocol and integration coverage in this group, but it changed license at 5.9.0, and a cluster of more than one node requires a license file. Each release under the Business Source License converts to Apache 2.0 four years after publication, so model that timeline in your license review. For mixed workloads, NATS and RabbitMQ's MQTT plugin are adjacent options, but this page has no verified facts on their MQTT support, so confirm protocol version, clustering and TLS behavior with each vendor before shortlisting them.
Which MQTT broker suits which project scenario
This table maps common MQTT project scenarios to the broker that fits best and the condition that makes the choice matter. Read each row against your own topology, license policy and support needs, since the right answer often depends on one constraint rather than on raw feature counts.
| Scenario | Best fit | Why |
|---|---|---|
| Single-site pilot or edge gateway | Eclipse Mosquitto | Lightweight, runs from small single board computers to full servers, and dual licensed under EPL-2.0 or BSD-3-Clause. Matters when one node is enough and you want the lowest operational footprint. |
| Multi-site fleet needing bridges | Eclipse Mosquitto | The mosquitto.conf manual documents bridges between brokers with certificate and pre-shared-key TLS options. Confirm that bridge topology and failover meet your site architecture before committing. |
| Clustered plant or national-scale device fleet | EMQX | Masterless clustering and a SQL-based rule engine suit large fleets. From 5.9.0, clusters of more than one node need a license file under the Business Source License 1.1, so confirm the license terms with the vendor. |
| Apache 2.0 requirement with a Java team | HiveMQ CE | Apache 2.0 licensed, Java-based, with a Java extension SDK for authentication, authorization and interceptors. Clustering is not in the CE README, so a multi-node HA design needs the commercial HiveMQ Broker. |
| Mixed MQTT and streaming workload | EMQX | Ships over 50 data integrations including Kafka, RabbitMQ, PostgreSQL and Redis. Matters when device data must flow directly into existing streams or databases, and the BSL terms are acceptable for your use. |
| Team that needs commercial support | EMQX or HiveMQ Broker (commercial) | Both vendors sell commercial products. Mosquitto support comes through Cedalo's Pro Edition, which adds high availability and professional support. Ask each vendor for its support scope in writing. |
| Conditional: NATS or RabbitMQ for mixed workloads | Confirm MQTT support first | NATS and RabbitMQ are included only as conditional options. Confirm the exact MQTT version, plugin and clustering support in their current documentation before shortlisting either. |
What the EMQX license change means before you deploy
Starting with version 5.9.0, EMQX unified its former Open Source and Enterprise editions into a single offering under the *Business Source License 1.1*, moving away from Apache 2.0. The Business Source License is not an OSI-approved open-source license, so treat EMQX as source-available for licensing purposes, not as open source. The other two brokers in this comparison, Eclipse Mosquitto (dual licensed under EPL-2.0 or EDL-1.0) and HiveMQ CE (Apache 2.0), use OSI-approved licenses. If your procurement policy or customer contracts require OSI-approved components, that alone may decide the question before any feature comparison begins.
The license permits production use of a single node, provided the broker is not offered to third parties on a hosted or embedded basis. It also allows unrestricted production use by educational and non-profit users for non-commercial purposes. From 5.9.0, running a cluster of more than one node requires loading a license file, so a clustered EMQX deployment is a licensing decision as well as an architecture decision. Confirm with EMQX which license file applies to your node count and whether a cluster used for internal production needs one. Read the terms directly in the emqx/emqx LICENSE file rather than relying on summaries.
Have a legal or procurement review before you deploy EMQX inside a SaaS product, an embedded device fleet you sell or any service a third party uses. Those are the cases the restriction on hosted or embedded offerings is aimed at, and a self-hosted broker serving only your own organization may fall outside them. Also plan for the time limit: each EMQX release converts to Apache 2.0 four years after it is published, so the licensing position of older releases changes over time. Record which version you deploy, its publication date and the conversion date in your asset register, and ask your legal team whether that date affects your upgrade plan.
How EMQX, Eclipse Mosquitto and HiveMQ CE differ in brief
The three brokers differ most on license terms and on where clustering and extensions sit, and those differences decide the shortlist more often than protocol support does. The cards below summarize each option's license label, MQTT versions and latest supplied release, then add a card for NATS and RabbitMQ's MQTT plugin, which the supplied facts do not cover.
EMQX under BSL 1.1
EMQX is the clustered option with the widest protocol reach, supporting MQTT 5.0, 3.1.1 and 3.1, MQTT over QUIC, and MQTT-SN, CoAP and LwM2M through gateways. Since 5.9.0 it ships under the Business Source License 1.1, and a cluster of more than one node requires a license file. Check the hosted and embedded restrictions against your product model before you build on it, and confirm the license terms for your version with the vendor.
Eclipse Mosquitto under EPL-2.0 or BSD-3
Mosquitto is the lightweight broker with the most permissive dual license, EPL-2.0 OR BSD-3-Clause, and it implements MQTT 5.0, 3.1.1 and 3.1. It ships client tools such as mosquitto_pub and mosquitto_sub and admin tools such as mosquitto_passwd, and it connects brokers through bridges. Clustering and high availability are not part of the open-source core, so confirm whether the Pro Edition from Cedalo is needed for your availability target.
HiveMQ CE under Apache 2.0
HiveMQ CE is the Java-based community broker under Apache 2.0, with full support for MQTT 3.x and MQTT 5. It offers a Java extension SDK for authentication, authorization and packet interceptors, and it is distributed as the hivemq/hivemq-ce Docker image. Clustering, zero-downtime upgrades and disk replication belong to the commercial HiveMQ Broker, so a multi-node design needs its own review. Confirm the Java runtime in your environment, since at least Java 11 is required.
NATS: confirm MQTT support
NATS is named here for mixed workloads that combine IoT messaging with service-to-service traffic. The supplied facts do not cover its MQTT support, its license or its clustering model. Before you shortlist it, confirm with the NATS project whether MQTT clients are supported, which license applies to the release you would deploy, and how it compares with the brokers above on device authentication and bridging.
RabbitMQ's MQTT plugin: confirm scope
RabbitMQ can accept MQTT clients through a plugin, which may suit teams that already run RabbitMQ for AMQP workloads. The supplied facts do not cover that plugin's MQTT version support, its license terms or its feature parity with dedicated MQTT brokers. Confirm the supported MQTT versions, the plugin's maturity for device fleets and the license of the RabbitMQ release you would run before you rely on it.
How the MQTT brokers compare on clustering, extensions and integrations
This table compares EMQX, Eclipse Mosquitto and HiveMQ CE on license, clustering, extension model, authentication, integrations and upgrade paths. Read each row as a question to put to the vendor, since cells marked as items to confirm rely on information the vendors have not fully published here. The main takeaway is that clustering and high availability are where the open-source editions differ most, so confirm them before you commit to an architecture.
| Capability | EMQX | Eclipse Mosquitto | HiveMQ CE |
|---|---|---|---|
| License | Business Source License 1.1 from 5.9.0, converting to Apache 2.0 four years after each release | EPL-2.0 or BSD-3-Clause (dual licensed) | Apache 2.0 |
| OSI-approved status | Confirm with EMQX: BSL 1.1 is source-available and is not an OSI-approved license | Yes, both EPL-2.0 and BSD-3-Clause are OSI-approved | Yes, Apache 2.0 is OSI-approved |
| MQTT versions | 5.0, 3.1.1 and 3.1 | 5.0, 3.1.1 and 3.1 | 3.x and 5 |
| Transports (TCP, TLS, WebSocket, QUIC) | TCP, TLS, secure WebSocket and MQTT over QUIC | TCP and TLS with WebSocket support, confirm QUIC with the project | TCP, TLS, WebSocket and secure WebSocket; QUIC not listed |
| Clustering in the open-source edition | Masterless clustering; a license file is required for more than one node from 5.9.0 | Not a clustering feature; bridges connect separate brokers | No clustering listed in the community README |
| High availability and commercial add-ons | Clustering governed by the license file; confirm terms for your node count | High availability and persistent queuing are in Cedalo's Pro Edition | Masterless clustering, zero-downtime upgrades and disk replication are listed for the commercial HiveMQ Broker |
| Extension model | SQL-based rule engine and data integration; confirm plugin options for custom logic | Core broker with configuration options; confirm plugin extensibility with Cedalo | Java extension SDK for authentication, authorization, client initializers and packet interceptors |
| Authentication options | Username and password, JWT, PSK and X.509 certificates over TLS and secure WebSocket | Certificate and pre-shared-key TLS options; confirm other methods in the manual | Covered by the Java SDK for authentication and authorization; confirm built-in options |
| Data integrations and rule engine | More than 50 systems including Kafka, RabbitMQ, Pulsar, PostgreSQL, MySQL, MongoDB and Redis | Confirm the integration list with the project or Cedalo Pro | Confirm integrations; the community edition is a broker with an extension SDK |
| Bridging to other brokers | Confirm bridging options in the EMQX documentation | Bridges documented in mosquitto.conf with certificate and pre-shared-key TLS | Confirm bridging options with HiveMQ |
| Commercial upgrade path | Same codebase under BSL; cluster and features governed by license file | Cedalo Pro Edition for high availability, REST APIs and professional support | HiveMQ Broker for clustering and zero-downtime upgrades; confirm migration steps |
Where clustering and high availability change the decision
Clustering is where the open-source MQTT editions differ most, so it should set the shortlist before features do. A single broker is enough for many pilot and mid-sized IoT deployments, provided the device count, message rate and recovery expectations fit one node and you can tolerate a restart window during maintenance. Confirm those numbers with your own load test before you rely on them, because the supplied facts do not give throughput figures for any of the three brokers.
Mosquitto's open-source route to multiple brokers is bridging, documented in the mosquitto.conf manual, with TLS and pre-shared-key options for bridge connections. Bridges can link sites or separate broker tiers, but they are not a clustered high availability design, so check with the Mosquitto documentation and your own failover tests how client sessions and messages behave when a bridged broker fails. High availability itself is part of Cedalo's commercially licensed Pro Edition, which is a paid option to price in a written quote.
EMQX offers masterless clustering, but from version 5.9.0 a cluster of more than one node requires a license file, and the Business Source License limits hosted or embedded offerings. HiveMQ CE's README does not list clustering among its features, while HiveMQ's product page lists masterless dynamic clustering, zero-downtime upgrades and disk replication for the commercial HiveMQ Broker. If you need a multi-node broker with zero-downtime upgrades, ask each vendor to confirm in writing which edition, license and support terms cover that design, and request a quote built from your node count and recovery targets.
What each team owns when an MQTT broker runs in its own infrastructure
Platform or IT operations owns the broker as a running service inside your cloud accounts, data center or air-gapped network. The work starts with hosting choices such as single node or clustered deployment, then moves to TLS certificate issuance and renewal for listeners, upgrade windows, backup of broker state and configuration, and monitoring of connections, message throughput and disk use. The effort rises with the number of sites, the number of devices and how often vendors ship security fixes.
- Hosting model: A single node is simpler to run, while a cluster adds nodes, load balancing and failure testing. EMQX documents that clustering more than one node requires a license file from 5.9.0 onward.
- Certificates: Listener certificates, client certificate authorities and any bridge certificates need an owner, a renewal process and an expiry alert.
- Upgrades: Plan rollbacks for each broker version and test client compatibility before rollout. Check the current release lines, such as EMQX releases, before you set a cadence.
- Backup and monitoring: Define what state must be restored, such as configuration, rules, retained messages or user stores, and who watches broker health.
Confirm with each vendor which state persists across restarts and what a supported restore looks like in your environment.
IoT or OT engineering owns what the devices and applications actually do with the broker. Their work covers device onboarding, topic design, quality of service choices, retained message policy and the client libraries used on each platform. Client tooling such as Eclipse Paho, along with the mosquitto_pub and mosquitto_sub command line clients, is often the first way teams test a topic layout before devices arrive. The effort depends on device diversity, how many protocols reach the broker and how much data each device sends.
- Device onboarding: Decide how each device gets its identity, credentials and certificate before it connects, and how a lost device is revoked.
- Topic design: A topic hierarchy is hard to change once devices publish to it. Agree on naming, ownership and wildcard subscriptions early.
- Protocol reach: EMQX offers gateways for MQTT-SN, CoAP and LwM2M, while Mosquitto and HiveMQ CE focus on MQTT itself. Confirm which device protocols you need before choosing.
- Client compatibility: HiveMQ CE states compatibility with MQTT 3 and MQTT 5 clients, including Eclipse Paho. Test the MQTT version each device firmware uses against the broker you pick.
Confirm the MQTT versions and client libraries each device family uses, and who signs off topic changes.
Security owns how clients prove identity, what each client may publish or subscribe to and how secrets are stored and rotated. Authentication options differ by broker. EMQX lists username and password, JWT, PSK and X.509 certificates over TLS and secure WebSocket connections. HiveMQ CE offers a Java extension SDK for authentication and authorization, so custom logic needs review as code. Mosquitto ships a password tool, and its bridge options support certificate and pre-shared-key TLS. The review scope grows with every custom plugin or extension.
- Authentication method: Choose one credential model per device class and document the reasons. X.509 and PSK need certificate or key lifecycle processes, while JWT depends on the token issuer.
- Access control: Define topic-level permissions and test that a compromised device cannot publish to another device's topics.
- Extension review: Any HiveMQ CE extension or EMQX rule that handles credentials or payloads needs code review, testing and an owner.
- Secrets handling: Keep broker passwords, pre-shared keys and private keys in a managed store, with rotation and access logs.
Confirm the license terms for any feature you rely on, since EMQX's Business Source License limits hosted or embedded offerings, and confirm the security patch process with each vendor.
How to choose and pilot an MQTT broker in four steps
This sequence turns a shortlist of EMQX, Eclipse Mosquitto and HiveMQ CE into a documented choice, backed by a pilot that tests the license, protocol, availability and security requirements your devices actually depend on.
Confirm license and redistribution terms
Legal or procurement owners, with the platform lead, read the license text for each candidate and record whether the broker will run only inside your own organization or be offered to third parties on a hosted or embedded basis. EMQX moved to the Business Source License 1.1 from version 5.9.0, and its license permits single-node production use without restriction only within the limits it sets, while Mosquitto is dual licensed under EPL-2.0 or BSD-3-Clause and HiveMQ CE is Apache 2.0. Confirm the redistribution position with counsel before any design work. Done means a written note per broker stating whether your intended use and any product you ship on top of it are permitted, and which edition or license file is required once you run more than one node.
Inventory device protocols and MQTT versions
The IoT or industrial architect lists every client type, its MQTT version (3.1, 3.1.1 or 5.0), the transports it uses (TCP, TLS, WebSocket) and any non-MQTT devices that reach the broker through a gateway. EMQX lists MQTT over QUIC and MQTT-SN, CoAP and LwM2M gateways among its features, Mosquitto implements MQTT 5.0, 3.1.1 and 3.1, and HiveMQ CE supports MQTT 3.x and 5 over TCP, TLS and WebSocket. Note which MQTT 5 features your clients rely on, such as shared subscriptions or user properties, and test those explicitly rather than assuming support. Done means a table of clients, versions and transports, with each feature marked as confirmed by a pilot test or as an open question for the vendor.
Define availability and whether bridges suffice
The platform lead decides how much availability the deployment needs, whether a single broker with backups is enough, and whether the sites must share a logical cluster. Mosquitto documents bridges as its way to connect multiple brokers, with certificate and pre-shared-key TLS options for bridge links, which can cover edge-to-core topologies without clustering. Clustering is the other path: EMQX offers masterless clustering, and from 5.9.0 a multi-node cluster needs a license file, while HiveMQ's clustering, zero-downtime upgrades and disk replication are listed for the commercial HiveMQ Broker rather than the Community Edition. Done means a written availability requirement and a decision recorded as either bridges or clustering, with the edition that provides it.
Pilot with TLS and client certificates
The security engineer and an IoT developer stand up each shortlisted broker in a staging environment you control, or use the Mosquitto public test server for protocol checks only, and enable TLS with client certificates for a representative device set. EMQX supports username and password, JWT, PSK and X.509 authentication, and Mosquitto and HiveMQ CE both offer TLS and WebSocket listeners, so configure the authentication method your devices will use in production and confirm certificate rotation works. Do not send production device data to a public test server. Done means each broker accepts only authenticated clients, rejects invalid certificates in a logged test, and has a runbook entry for how credentials are issued and revoked.
Measure the pilot and request a written quote
The engineering lead records message delivery under your expected publish rate, reconnect behavior after a broker restart, behavior of retained messages and persistent sessions, the throughput of any rule or integration path into Kafka, PostgreSQL or your historian, and the staff hours each broker needs for upkeep. Repeat the test once the bridge or cluster design is in place. Then ask vendors and any implementation partner for a fixed-scope written quote covering license fees, edition requirements for clustering or high availability, support terms, the scope of installation, hardening, integration and documentation, and what recurs (subscriptions, support and upgrades) versus what is one-time. Done means a comparison sheet with measured results and quotes that name the same scope, so the decision is based on evidence from your own environment.
What buyers ask about MQTT broker cost, effort and support
Are open-source MQTT brokers free to run in production?
The software licenses are free to use in most cases, but running a broker is not free. Mosquitto and HiveMQ CE are open source under permissive or dual licenses, while EMQX's current license restricts some production uses, so check its terms before you commit. The recurring costs are the infrastructure that hosts the brokers, the staff time to monitor, patch and upgrade them, certificate and credential management, and any paid support contract you add. Ask any vendor or partner for a quote that lists one-time setup separately from these recurring items.
Does EMQX's license file affect a multi-node cluster?
Yes. Starting with EMQX 5.9.0, deploying a cluster of more than one node requires loading a license file, so a clustered EMQX deployment is not covered by the free single-node allowance alone. The license also restricts offering EMQX to third parties on a hosted or embedded basis. Before you design around a cluster, ask EMQX in writing which license terms apply to your deployment model, how the license file is issued and renewed, and whether your use case, such as a product you ship to customers, falls under the hosted or embedded restriction.
Can Eclipse Mosquitto be clustered, or do you need the Pro edition?
The open-source Mosquitto project documents bridges as the way to connect multiple brokers together, with certificate and pre-shared-key TLS options for bridge connections. The Mosquitto site compares its open-source edition, which covers core MQTT features, on-premises deployment and community forum support, with Cedalo's commercially licensed Pro Edition, which adds high availability, integrations, REST APIs, persistent queuing and professional support. If your design needs high availability or a managed cluster, confirm in the current documentation which of those features you need and whether bridges meet the requirement. Treat that as a design question to answer before the pilot.
How long does an MQTT broker pilot take?
No duration can be given here without a scoped plan, so treat any figure you hear with caution. The time depends on the number of device types and message patterns, the authentication model (username and password, certificates or tokens), how many integrations you need to build, such as Kafka or a database, the number of environments to deploy, and how much load testing the workload requires. A team that already runs MQTT clients and TLS certificates will move faster than one starting from scratch. Ask for a written scope with defined milestones and an explicit list of what the pilot excludes.
What skills does the team need to run a self-hosted MQTT broker?
The team needs people who understand MQTT concepts such as QoS levels, retained messages and persistent sessions, plus skills in TLS and certificate management, identity and access control for devices, and Linux or container operations. Clustered or high-availability setups also need experience with replication, failover and upgrades. For EMQX, staff will also manage the rule engine and data integration configuration. Assess these skills honestly against your team, and budget for on-call coverage for an industrial or safety-related system. If gaps exist, a partner can fill them for the implementation period and hand over documentation and runbooks.
Should we hire an implementation partner for an MQTT broker?
Hire a partner when the broker is part of a regulated or industrial system where security testing, hardening, backup and evidence for compliance reviews matter, or when your team lacks capacity for the initial build. DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, typically under a fixed scope agreed in writing before work starts. Ongoing support and upgrades are available as retainers. DeployOpen does not publish a price list, so ask for a quote based on a written scope that names the brokers, integrations, environments and handover deliverables.
How DeployOpen scopes an MQTT broker selection and deployment
DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks. For an MQTT project, that means the broker decision is only one input. The work also covers where the brokers run, how device identities and certificates are issued, how bridges between sites are secured, how backups of retained messages and configuration are taken and tested, and how upgrades are rolled out without interrupting devices. Before any build starts, the team should agree which edition or license terms apply, which clustering model is needed, and who owns the license file where a multi-node EMQX cluster is planned.
Most engagements are *fixed-scope*. Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope rather than from a price list, which DeployOpen does not publish. Buyers should ask the quote to name the broker versions in scope, the authentication methods (for example, X.509 certificates or pre-shared keys), the integration targets, the test environments, the documentation handed over and the acceptance criteria. Ask the vendor or your licensing contact to confirm any license obligations for your topology before scope is fixed, since those obligations sit outside the implementation work.
DeployOpen's work is not tied to any one broker. The right choice depends on your device fleet, your licensing position and your operating model, and we will say so when the evidence points away from a given option. DeployOpen is not a partner or reseller of EMQX, the Eclipse Foundation, HiveMQ or Cedalo, and it does not issue certifications for them. Ongoing support, upgrades and continuous testing are available as retainers, which suits teams that want a fixed owner for patching and version changes after go-live.
