If you have decided that MQTT is the right protocol for your project and now need to pick a broker to run it on, the good news is that the three most widely-used options are open source. The bad news is that “open source” hides some important differences: license type, what “free” actually covers, what you get in the community edition versus what requires a paid tier, and what each broker is genuinely good at. Choosing wrong is not fatal — you can migrate later, since brokers are interchangeable at the protocol level — but choosing well saves you real work.
This article compares the three brokers most teams actually shortlist in 2026: Eclipse Mosquitto, EMQX, and HiveMQ Community Edition (CE). Each is a genuine open source MQTT broker with a large user base and active development. Each is best at something different. The comparison here is technical, honest about tradeoffs, and specific about which broker to pick for which situation. It is not a “top ten brokers” list — those tend to be shallow — but a real evaluation of the three that most projects should be choosing between.
Table of Contents
Which broker at a glance
| Aspect | Eclipse Mosquitto | EMQX | HiveMQ CE |
|---|---|---|---|
| First released | 2009 | 2012 | 2019 (open sourced) |
| Written in | C | Erlang/OTP | Java |
| License | EPL 2.0 / EDL 1.0 | BSL 1.1 (v5.9.0+) | Apache 2.0 |
| MQTT versions | 5, 3.1.1, 3.1 | 5, 3.1.1, 3.1 | 5, 3.x |
| Native clustering | No | Yes, but requires license file even in free tier | No (Enterprise only) |
| Typical footprint | ~3 MB RAM per 1,000 clients | Larger (JVM/BEAM) | Larger (JVM) |
| Practical single-node scale | 100k+ connections | 5M+ connections per node | Depends on JVM sizing |
| Best-suited for | Edge, embedded, small servers, single-broker | Cloud, IIoT, connected vehicles, large fleets | Learning MQTT 5, embeddable Java, small-to-medium |
| Public web-facing dashboard | No (third-party UIs exist) | Yes (built-in) | No (Control Center is Enterprise-only) |
| Commercial version | Pro Mosquitto (Cedalo) | EMQX Enterprise / Cloud | HiveMQ Professional / Enterprise |
The rest of this article walks through each broker in depth, then gives concrete recommendations for common scenarios at the end.
The one license nuance you must understand
Before comparing features, it is worth flagging the single most-misunderstood point in this space right now: EMQX changed its license in version 5.9.0. Before that release, EMQX was Apache 2.0, a permissive open source license. From v5.9.0 onward, EMQX uses the Business Source License (BSL) 1.1.
BSL 1.1 is a “source available” license, not a fully permissive open source license in the OSI sense. The important practical consequences:
- You can still read the source code, run the software for development and evaluation, and use it in production under specific conditions.
- Deploying an EMQX cluster of more than one node requires a license file, even when using the free tier permitted by the BSL. Single-node deployments do not need a license file, but clustering does.
- The license restricts you from offering EMQX as a competing hosted service (the standard BSL “competing product” clause).
- BSL code typically converts to Apache 2.0 after a set delay (usually a few years), meaning old versions eventually become fully open source.
None of this makes EMQX unusable, and for many teams it is entirely acceptable. But it does mean that “open source EMQX” is not the same as “Apache 2.0 EMQX” the way it was before v5.9. If you or your organization requires a strictly permissive open source license (Apache 2.0, MIT, BSD), Mosquitto and HiveMQ CE remain fully open source under those terms, while EMQX does not.
Older EMQX versions (before v5.9) remain available under Apache 2.0, but they do not receive the newer features. Choose deliberately.
Eclipse Mosquitto
Mosquitto is the most widely deployed open source MQTT broker in the world, and has been for over a decade. It was created by Roger Light in 2009, donated to the Eclipse Foundation, and is now developed primarily by Cedalo (which also sells a commercial “Pro Mosquitto” edition). It is licensed under a dual EPL 2.0 / EDL 1.0 arrangement — genuinely open source and freely usable in commercial deployments.
What Mosquitto does well
Extreme lightness. Mosquitto is written in C and is single-threaded by design. A running Mosquitto broker has an executable of about 120 KB and uses roughly 3 MB of RAM to hold 1,000 connected clients. This is not a benchmark — this is what the broker actually consumes. If you need to run MQTT on constrained hardware (an ARM board, an industrial gateway, a small VM), Mosquitto fits where nothing else will.
Simplicity of deployment. A mosquitto.conf file, a directory for persistence, and a single process. There is no cluster to coordinate, no orchestrator, no dashboard. On a single node, you can be running in minutes and understand exactly what the broker is doing.
Bridging. Mosquitto has excellent broker-to-broker bridge support, which lets you build multi-site MQTT topologies by connecting Mosquitto instances to each other (and to other broker types, including EMQX and HiveMQ). Bridges forward messages between brokers based on topic filters, which is often the answer when you have edge Mosquitto brokers aggregating into a central broker.
Client tools that ship with the broker. The mosquitto_pub, mosquitto_sub, and mosquitto_rr command-line tools are packaged with the broker and are the de facto standard for testing MQTT connections. Almost every MQTT tutorial you will read uses these.
Full MQTT 5 support. Mosquitto implements MQTT 5.0, 3.1.1, and 3.1, so no MQTT feature is out of reach.
What Mosquitto does not do
No native clustering. This is the biggest limitation. Mosquitto is a single-process broker. If one node cannot handle your load, you have to scale by adding independent brokers connected via bridges, which is fine for many topologies but is not the same as an elastic, load-balanced cluster. If you need a single logical broker that scales horizontally across nodes, Mosquitto is not it.
No built-in web dashboard. There is no Mosquitto-native UI for monitoring connections, topics, or messages. Third-party tools exist (Mosquitto Auth Plugin dashboards, MQTT Explorer, and others), and the commercial Pro Mosquitto edition includes a Management Center, but the free broker leaves this to you.
Limited built-in integrations. Mosquitto is a broker, not a data integration platform. It does not natively bridge to Kafka, PostgreSQL, or other systems the way EMQX does. If you want messages routed into a database or a queue, you write that yourself or run another component in front.
Single-threaded architecture. On multi-core hardware, a single Mosquitto process only uses one core for message processing. Sharding across cores requires running multiple brokers, which brings back the coordination question.
When to choose Mosquitto
Choose Mosquitto if you are running MQTT on constrained hardware, if a single node fits your load, if you value simplicity and deployability above all else, if your team is comfortable with C-based tooling, or if you need a proven, dependable broker without operational complexity. This covers a very large fraction of real-world deployments: edge gateways, small-to-medium single-region backends, testing and development environments, embedded systems, and home automation. It is also the default recommendation for anyone starting out with MQTT.
EMQX
EMQX is the largest-scale open source MQTT broker in common use, written in Erlang/OTP — a language purpose-built for building massively concurrent, fault-tolerant, soft real-time systems. It was launched in 2012 (originally as “emqttd”) by EMQ Technologies, which continues to develop and sell commercial editions and hosted service. It uses the BSL 1.1 license from v5.9.0 onward (see the license nuance section above); earlier versions were Apache 2.0.
What EMQX does well
Massive scale. EMQX is built for scenarios where a single Mosquitto instance simply cannot cope. It uses a masterless distributed architecture and can handle 100 million or more concurrent MQTT connections in a single cluster, with millions of messages per second and sub-millisecond latency. The commonly cited figure is a 23-node cluster supporting 100 million connections, tested and verified. For connected-vehicle fleets, large IIoT deployments, and consumer IoT backends serving millions of devices, this is exactly the shape of scale EMQX targets.
Masterless clustering. Unlike brokers where scaling requires coordinating with a primary, EMQX nodes coordinate peer-to-peer. Any node can accept any client; the cluster distributes routing state and message delivery internally. Adding capacity is straightforward. Losing a node does not lose the cluster.
Built-in rule engine and data integration. EMQX includes a SQL-based rule engine that lets you transform, filter, and enrich messages as they flow through the broker, plus first-class connectors to Kafka, PostgreSQL, MongoDB, Redis, ClickHouse, InfluxDB, MQTT bridges to other brokers, HTTP webhooks, and more. Where Mosquitto is “a broker, nothing else,” EMQX is closer to “a broker plus a lightweight integration layer.” For many teams this saves building custom middleware.
Web dashboard. EMQX ships with a management dashboard for monitoring connections, subscriptions, topics, and cluster health, plus a rich HTTP API for automation. You do not have to bolt monitoring on separately.
MQTT over QUIC. EMQX supports MQTT over QUIC (the QUIC transport used in HTTP/3), which cuts connection establishment overhead and handles network handovers (Wi-Fi to cellular, for example) more gracefully than TCP. This is a newer capability few other brokers have. For mobile fleets, it can be genuinely useful.
Multi-protocol gateways. Beyond MQTT, EMQX has gateways for MQTT-SN, CoAP, LwM2M, and STOMP, letting a single broker terminate multiple IoT protocols.
What EMQX does not do
Simple deployment. EMQX is larger and more complex than Mosquitto. The Erlang runtime, the dashboard, the rule engine, and the operational surface all add up. A single-node EMQX runs fine, but if you were expecting Mosquitto-like resource use, you will be surprised. For very small deployments, EMQX is over-engineered.
BSL license constraints. As covered above, EMQX v5.9.0 and later use BSL 1.1, not Apache 2.0. Clustering more than one node requires a license file. This is fine for many teams and organizations, but not fine for teams that require strict Apache/MIT/BSD-style permissiveness.
Larger footprint on constrained hardware. EMQX runs on Linux/Windows/macOS/Docker/Kubernetes, but it is not the broker to reach for on an ARM device with 128 MB of RAM. For that class of hardware, Mosquitto or a specialized edge broker (NanoMQ, for example) is the better fit.
When to choose EMQX
Choose EMQX if you expect to run at the scale of millions of concurrent clients, if you need horizontal clustering out of the box, if you want the rule engine and data integrations without building them yourself, if MQTT over QUIC or multi-protocol gateway support matters to your use case, or if your deployment is cloud-native and you want a broker designed for that environment. This describes cloud IoT backends, connected-car platforms, large IIoT platforms, and consumer IoT at scale. Be aware of the license nuance and choose deliberately.
HiveMQ Community Edition
HiveMQ CE is the open source foundation of HiveMQ’s commercial platform, released under the Apache 2.0 license. It is written in Java and requires Java 11 or later to run. HiveMQ was founded in 2012 by dc-square (now HiveMQ GmbH), open-sourced the CE in 2019, and continues to develop it as the technical core of their enterprise offering.
What HiveMQ CE does well
Full, careful MQTT 5 support. HiveMQ’s team has been particularly active in MQTT 5 spec work and testing, and HiveMQ CE has a reputation for careful, correct implementation of the newer MQTT features. If you want to work with MQTT 5 seriously (user properties, shared subscriptions, request/response, enhanced authentication), HiveMQ CE is a solid choice.
Extension SDK for extending the broker in Java. HiveMQ CE has an Extension SDK that lets you write custom behavior in Java — authentication logic, message interceptors, custom persistence backends, and so on. If your team is a Java shop and you want to build MQTT features that need broker-side code, this is the most natural fit of the three.
Embeddable in Java applications. HiveMQ CE can be run as an embedded broker inside a Java application, using the EmbeddedHiveMQBuilder API. This is uncommon in the broker space and is genuinely useful for testing (spinning up an ephemeral broker inside a test suite) and for applications that want to expose an MQTT endpoint without operating a separate broker process.
Apache 2.0 license. Fully permissive open source. No restrictions on commercial use, no clustering license fee, no “competing product” clause.
Battle-tested code path. The same code runs in HiveMQ’s enterprise product, which is deployed at very large customers in automotive, banking, and manufacturing. Bugs found in enterprise deployments get fixed in CE too. You are running the same core as HiveMQ’s enterprise customers, minus the enterprise-only features.
What HiveMQ CE does not do
No clustering. This is the single biggest limitation and a deliberate business decision by HiveMQ. Clustering, high availability, and elastic scaling are all reserved for HiveMQ Professional and Enterprise. HiveMQ CE runs as a single node. For serious production traffic at scale, either you accept a single-node deployment, run multiple independent CE instances yourself (harder than it sounds), or upgrade to a paid tier.
No Control Center. The web-based monitoring UI (“HiveMQ Control Center”) is enterprise-only. HiveMQ CE gives you the broker but not the dashboard, which is inconvenient for operations. You can wire up your own metrics (HiveMQ CE exposes metrics via JMX and other means), but the dashboard experience is behind a paywall.
No enterprise extensions. The Kafka integration, S3 cluster discovery, Azure Blob discovery, and other enterprise extensions are separate products. HiveMQ CE gives you the broker core and the Extension SDK to build things yourself, but the pre-built integrations are Enterprise-only.
JVM overhead. A Java broker on the JVM is heavier than a C broker like Mosquitto. Small deployments feel this. Large deployments do not care.
When to choose HiveMQ CE
Choose HiveMQ CE if you are working with MQTT 5 features and want a spec-clean implementation, if your team is Java-native and you want to extend the broker in Java, if you need to embed an MQTT broker inside a Java application (a real use case for testing), if you want Apache 2.0 licensing with no strings, or if you plan to eventually move to HiveMQ Enterprise and want the same code path in development. It is not the right choice for very small edge deployments (Mosquitto is lighter) or for large-scale clustered deployments (EMQX is more capable in the open version, and HiveMQ’s own clustering is enterprise-only).
Which broker for which situation
The comparison boils down to a few clear cases. If your situation fits one of these, the choice is not ambiguous.
Edge device, industrial gateway, or single-node backend with modest load → Eclipse Mosquitto. The lightweight footprint, simple operation, and mature single-node reliability make this the default choice for anything that does not need clustering.
Cloud backend serving millions of MQTT clients → EMQX. The clustering, scale, and built-in data integrations are what this broker is for. Accept the BSL license terms and use it. Alternatively, if you strictly need Apache 2.0 at that scale, use EMQX 5.8.x (the last Apache 2.0 release) — though you will miss out on newer features.
Java-shop, want to embed a broker or extend it in Java → HiveMQ CE. The Extension SDK and embedded mode are what this broker offers that the others don’t. Accept the single-node limitation, or plan to move to HiveMQ Enterprise.
Learning MQTT 5 or building a MQTT-5-native application → Any of the three, but HiveMQ CE is the most spec-clean. Mosquitto and EMQX are both fine; the differences at the protocol level are small.
Multi-site edge-to-cloud topology → Mosquitto at the edge, EMQX or a commercial broker in the cloud, bridged. This is a common and effective architecture. Mosquitto is what fits on the edge hardware; EMQX handles the aggregation.
Home automation, hobbyist use → Eclipse Mosquitto. Almost universally.
Strict Apache 2.0 licensing required → Mosquitto (EPL/EDL, similarly permissive for most purposes) or HiveMQ CE (Apache 2.0). EMQX v5.9+ is BSL and does not qualify.
Need MQTT over QUIC → EMQX. It is currently the only one of the three with production QUIC support.
What to install first if you are just starting
If you have never run an MQTT broker before, the answer is Mosquitto. It installs with a package manager on every platform, runs with a two-line config, and gives you exactly enough to publish and subscribe. Every MQTT tutorial online uses mosquitto_pub and mosquitto_sub at least somewhere; you will be following those directly.
From there, you can outgrow Mosquitto in two directions. Upward, if you need clustering and scale, EMQX is the usual next step. Sideways, if you need Java integration or specifically MQTT 5 experimentation with an Extension SDK, HiveMQ CE is the choice. Either transition is straightforward because MQTT is the protocol; the broker is interchangeable at the protocol level.
Common misconceptions
A few things people believe about these brokers that are not quite right.
“EMQX is Apache 2.0 open source.” True before v5.9.0, not true from v5.9.0 onward. The current version is BSL 1.1. Older versions remain Apache 2.0.
“Mosquitto can scale by adding nodes.” Not natively. You can run multiple Mosquitto instances connected by bridges, but you do not get a single logical broker that load-balances across them. For that, you need a broker with clustering (EMQX in the open source space, or a commercial edition).
“HiveMQ CE is a stripped-down demo.” It is not. HiveMQ CE is the same broker core that HiveMQ Enterprise is built on. It just does not include the enterprise-only features (clustering, Control Center, Kafka extension, and so on). For a single-node deployment, HiveMQ CE is a serious production broker.
“All three brokers are equivalent at the protocol level, so pick whichever is easiest.” They are equivalent for basic MQTT, but MQTT 5 support quality, edge cases (retained messages, session expiry, shared subscriptions), and behavior under load do vary. For serious deployments, test the specific features you rely on with the specific broker you plan to use.
“Mosquitto is only for small projects.” Mosquitto scales to over 100,000 concurrent connections on a single node with modest hardware. That is enough for many production deployments. Do not underestimate it.
Security and operational considerations across all three
The comparisons above focus on features and scale, but the security and operational surface matters at least as much for a real deployment. A few points apply to all three brokers.
TLS is your responsibility. All three support TLS for client-broker connections (ports 8883 for MQTT, 443 for MQTT-over-WebSockets), but none of them ship with a valid certificate configured for you. In production, you configure TLS termination — directly on the broker or via a reverse proxy — with proper certificate management and rotation. Do not run a broker on a public network without TLS.
Authentication defaults are minimal. By default, Mosquitto and HiveMQ CE start in a mode that either requires no authentication (for local testing) or one you have to configure explicitly. EMQX is similar. Configure username/password and access-control lists before exposing a broker beyond a trusted network. Enterprise editions of all three brokers add richer authentication (LDAP, OIDC, mTLS integration); the open source versions typically require you to wire that up yourself or write extensions.
Access-control lists matter. Once you have more than a few topics and clients, blanket “connect and do anything” access is dangerous. Both Mosquitto (via ACL files or the dynamic security plugin) and HiveMQ CE (via extensions) let you define who can publish and subscribe to which topics. EMQX has a built-in ACL system with the dashboard. Design your topic hierarchy with ACLs in mind: a client should only ever have access to its own topic tree, not the whole broker.
Persistence has real cost. All three brokers can persist retained messages and session state to disk, and all three have configuration for how aggressively they do so. Persistence has a real performance cost, especially under load. Test with realistic message rates before assuming defaults work at your scale.
Monitoring is your problem. EMQX ships with a dashboard; Mosquitto and HiveMQ CE do not. For production operation, you need metrics (connection counts, message rates, memory use, disk use), alerts, and log aggregation. Wire up Prometheus, Grafana, or your existing monitoring stack early; do not wait until something breaks to notice you have no visibility.
Frequently asked questions
What is the most popular open source MQTT broker? By deployment count, Eclipse Mosquitto is the most widely deployed. By GitHub stars and cloud-scale usage, EMQX is comparable in visibility. HiveMQ CE is the newest of the three and has a smaller but growing installed base.
Is EMQX still Apache 2.0? No, not from version 5.9.0 onward. EMQX v5.9.0 and later use the Business Source License (BSL) 1.1. Versions before 5.9 remain Apache 2.0 but do not receive new features.
Which open source MQTT broker supports clustering? EMQX is the only one of the three that supports native clustering in its free tier, though deploying a cluster of more than one node under EMQX’s BSL 1.1 requires a license file. HiveMQ CE does not support clustering (Enterprise only). Mosquitto does not support native clustering (Pro Mosquitto includes it in the commercial edition).
Which is best for edge or embedded IoT? Eclipse Mosquitto, by a wide margin. Its C-based, single-threaded, ~3 MB RAM footprint fits on hardware that the other two cannot practically run on.
Which is best for cloud-scale IoT? EMQX, if you accept the BSL license. Its masterless clustering and built-in integrations are designed for exactly this shape of deployment.
Which is best for MQTT 5? All three support MQTT 5. HiveMQ CE has the most spec-focused reputation. EMQX has extensive MQTT 5 support. Mosquitto’s MQTT 5 support is solid and mature.
Can I use these brokers commercially? Yes, all three. Mosquitto (EPL/EDL) and HiveMQ CE (Apache 2.0) are fully permissive. EMQX under BSL 1.1 permits commercial use with the “competing product” restriction, and cluster deployments require a license file.
Should I use a hosted broker instead of self-hosting? That depends on your operational preferences. All three brokers have hosted or managed offerings from their commercial arms (Cedalo for Mosquitto, EMQX Cloud, HiveMQ Cloud). For teams that would rather not operate a broker, hosted is a reasonable choice; for teams that already run infrastructure or need on-premises deployment, self-hosting one of the three open source brokers is the standard path.
How do I migrate between brokers? Because MQTT is the protocol, clients don’t need to change. On the broker side, you re-implement whatever server-side configuration, ACLs, and integrations you had. Retained messages and persistent sessions do not migrate automatically between broker types, but for most deployments this is not a hard problem — clients simply reconnect and re-establish their state.