Open Source MQTT Broker: Mosquitto vs EMQX vs HiveMQ CE vs VerneMQ

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 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 four brokers most teams actually shortlist in 2026: Eclipse Mosquitto, EMQX, HiveMQ Community Edition (CE), and VerneMQ. Each is a genuine open source MQTT broker with a real production track record. 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 four that most projects should be choosing between.

• Which broker at a glance
• The one license nuance you must understand
• Eclipse Mosquitto
• EMQX
• HiveMQ Community Edition
• VerneMQ
• Which broker for which situation
• Industrial IoT: Sparkplug B and Unified Namespace considerations
• What to install first if you are just starting
• Common misconceptions
• Security and operational considerations across all four brokers
• Frequently asked questions

Which broker at a glance

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).

VerneMQ

VerneMQ is a distributed MQTT broker written in Erlang/OTP, positioned as an enterprise-ready option with masterless clustering built in from the start. It was launched in 2014 by Erlio GmbH and is licensed under Apache 2.0 for the source code, though its binary packages require a commercial subscription for paid use — an unusual licensing arrangement worth understanding before choosing it.

What VerneMQ does well

Masterless clustering as a first-class feature. Unlike HiveMQ CE (no clustering) or Mosquitto (no native clustering), VerneMQ has always been designed as a distributed broker. Nodes join a cluster peer-to-peer, and the cluster distributes routing state across nodes. In principle this puts VerneMQ closer to EMQX than to the other two brokers in the clustering category.

Full MQTT 5 support. VerneMQ implements MQTT 5.0, 3.1.1, and 3.1 with all the standard property types (user properties, reason strings, content types, and so on). It has been kept current with the spec.

FIPS 140-2 support. VerneMQ can be configured to use FIPS 140-2 certified cryptography over TLS 1.2, which makes it usable in federal and regulated environments where other brokers may not qualify. This is a genuine differentiator for defense, federal, and highly regulated industrial deployments.

Plugin flexibility. VerneMQ has extensive plugin support, including built-in Lua scripting with database connectors (PostgreSQL, MySQL, MongoDB, Redis, Memcached) and webhook-based plugins so you can write custom logic in any language without needing Erlang experience.

Active maintenance. Despite reports in some competitor comparisons that VerneMQ development has slowed, the project is currently maintained. The GitHub repository explicitly states the mission is active, and version 2.0.0 was released with meaningful new features. The project remains a viable choice for teams evaluating brokers in 2026.

Genuine Apache 2.0 licensing (for source). The source code is Apache 2.0 licensed, without the BSL restrictions that apply to newer EMQX versions. If strictly permissive licensing matters for your organization, VerneMQ's source-code licensing is clean.

What VerneMQ does not do

Historical clustering reliability issues. VerneMQ's clustering was originally built on the Plumtree library implementing the Epidemic Broadcast Trees algorithm. Competitors and independent reviewers have documented persistent challenges with this architecture around network splits, data inconsistency, and crash recovery. The project has spent significant effort improving these areas over the years, but the reputation for clustering fragility persists in some quarters, and it is worth researching current status carefully for your specific deployment scale before committing.

The commercial binary subscription requirement. This is VerneMQ's most unusual arrangement. The source code is Apache 2.0, but the pre-built binary packages published by the VerneMQ team require a yearly commercial subscription for production commercial use. You can compile the source yourself to avoid this, but the friction of running your own build pipeline for a broker is real. For teams that expect to install "the official package" and treat that as free, this can be a surprise.

Smaller ecosystem than the top three. Community support, third-party plugins, tutorials, and Stack Overflow coverage are all thinner for VerneMQ than for Mosquitto, EMQX, or HiveMQ. This is not a fatal issue — the project's own documentation is reasonable — but you will find fewer external resources.

No native Sparkplug B support. For industrial deployments that want protocol-level Sparkplug B decoding on the broker, VerneMQ does not currently offer it.

JVM-like operational profile. As with EMQX and HiveMQ, VerneMQ runs on the BEAM virtual machine (Erlang runtime), which is heavier than Mosquitto's C implementation for very small deployments.

When to choose VerneMQ

Choose VerneMQ if you need distributed clustering with strictly Apache 2.0 source-level licensing, if you operate in a FIPS 140-2 regulated environment, if you want plugin flexibility with the built-in Lua scripting engine, or if you specifically want to avoid the BSL 1.1 licensing terms of newer EMQX versions. VerneMQ is also a reasonable choice for on-premises industrial deployments where operating an Erlang/OTP broker without a vendor relationship is acceptable to your team.

Be deliberate about researching the clustering situation for your intended scale, and understand the commercial binary subscription model before committing. VerneMQ is not the default choice for most teams, but it is a legitimate option for the specific situations where its differentiators matter.

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.

Distributed on-premises deployment with strictly Apache 2.0 source licensing → VerneMQ. It is the only one of the four that combines native clustering with Apache 2.0 source-level licensing. Understand the commercial binary subscription model and research current clustering reliability for your scale.

FIPS 140-2 regulated environment (defense, federal) → VerneMQ. FIPS 140-2 support is its most distinctive differentiator for this specific audience.

Learning MQTT 5 or building a MQTT-5-native application → Any of the four, but HiveMQ CE has the most spec-clean reputation. Mosquitto, EMQX, and VerneMQ all provide solid MQTT 5 support; 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), HiveMQ CE (Apache 2.0), or VerneMQ (Apache 2.0 for source). EMQX v5.9+ is BSL and does not qualify.

Industrial IoT with Sparkplug B decoding on the broker → EMQX (plugin) or HiveMQ Enterprise (extension). See the Sparkplug B section below for details.

Need MQTT over QUIC → EMQX. It is currently the only one of the four with production QUIC support.

Industrial IoT: Sparkplug B and Unified Namespace considerations

For industrial IoT and SCADA-to-IT integration deployments, two additional considerations are worth calling out because they have become nearly mandatory in modern industrial architectures.

Sparkplug B is a payload specification maintained by the Eclipse Foundation (originally developed by Cirrus Link) that standardizes how MQTT is used for industrial telemetry. It defines a specific topic namespace, a Google Protocol Buffers-based payload format, and state management via birth and death certificates, which lets subscribers know exactly which devices are connected and what data they publish. Sparkplug B is what turns MQTT from a generic messaging protocol into an industrial-grade telemetry protocol, and its adoption is growing quickly in manufacturing, process control, and IIoT platforms.

Native broker support for Sparkplug B varies across the four brokers:

• Mosquitto — no native Sparkplug B support. You can carry Sparkplug B payloads through Mosquitto (the broker is payload-agnostic) but Mosquitto itself does not decode or validate them, and does not provide any Sparkplug-aware features.
• EMQX — Sparkplug B support via plugin, with codec functions for decoding and encoding Sparkplug payloads. Works with the EMQX rule engine to route Sparkplug data to backend systems.
• HiveMQ CE — no native Sparkplug B support in the Community Edition; Sparkplug support is an enterprise-tier feature via a HiveMQ extension.
• VerneMQ — no native Sparkplug B support.

If Sparkplug B matters to your project, EMQX (via plugin) or HiveMQ Enterprise (via extension) are the paths that provide broker-native support. All four brokers can carry Sparkplug B traffic — but "carrying" is not the same as "understanding," and applications that need broker-side Sparkplug decoding for routing, filtering, or state management will find the difference significant.

Unified Namespace (UNS) is a related but distinct concept: a topic-structure convention rather than a broker feature. UNS advocates that all industrial data flows through a single MQTT topic tree organized to mirror the physical or logical structure of the enterprise (ISA-95-style hierarchy: enterprise / site / area / line / cell), giving every consumer a single place to find any data point. Any MQTT broker supports UNS, because UNS is a matter of how you structure your topics, not what the broker natively provides.

That said, the practicalities of implementing UNS at industrial scale intersect with broker features:

• Persistent sessions and QoS 1/2 matter for reliability of UNS traffic.
• Retained messages are used heavily in UNS deployments to give subscribers instant access to the last known value on any topic.
• Wildcard subscriptions are how UNS consumers subscribe to hierarchical branches.
• Shared subscriptions (MQTT 5) are useful for load-balancing UNS consumers.
• Broker clustering matters if the UNS spans a geographic region or a large fleet.

For a UNS deployment, any of the four brokers works — the choice comes down to the same tradeoffs covered elsewhere in this article (scale, licensing, clustering, integration surface). But if you are building UNS and want Sparkplug B integration, EMQX or HiveMQ Enterprise are the more natural fits, because their Sparkplug support pairs with the topic conventions the UNS approach uses.

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 three directions. Upward, if you need clustering and scale, EMQX is the usual next step. Sideways for Java-native teams, if you need Java integration or specifically MQTT 5 experimentation with an Extension SDK, HiveMQ CE is the choice. Sideways for strictly-Apache-2.0 on-premises deployments with clustering, VerneMQ is worth evaluating. Any of these transitions 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 or VerneMQ 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.

"VerneMQ is abandoned." Not accurate. Despite reports in some competitor comparisons, the project explicitly states its mission is active, and version 2.0.0 was released with meaningful improvements. Development pace is slower than EMQX or HiveMQ, but the project is maintained.

"VerneMQ is fully free like Mosquitto." Not exactly. The source code is Apache 2.0, but pre-built binary packages require a commercial subscription for paid use. This is unusual and worth understanding before committing to VerneMQ.

"All four 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 four brokers

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 four brokers.

TLS is your responsibility. All four 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, all four brokers start in a mode that either requires no authentication (for local testing) or one you have to configure explicitly. Configure username/password and access-control lists before exposing a broker beyond a trusted network. Enterprise editions of these brokers add richer authentication (LDAP, OIDC, mTLS integration); the open source versions typically require you to wire that up yourself, write extensions, or use built-in plugin frameworks (VerneMQ's Lua scripting is particularly useful here).

Access-control lists matter. Once you have more than a few topics and clients, blanket "connect and do anything" access is dangerous. Mosquitto (via ACL files or the dynamic security plugin), HiveMQ CE (via extensions), EMQX (built-in ACL system with dashboard), and VerneMQ (via plugins or the built-in file-based ACL) all support defining who can publish and subscribe to which topics. 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 four brokers can persist retained messages and session state to disk, and all four 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 built-in dashboard; VerneMQ provides a basic HTTP status page; Mosquitto and HiveMQ CE provide neither. 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 and VerneMQ have smaller but genuine installed bases, with VerneMQ particularly notable in on-premises industrial and federal deployments.

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 and VerneMQ are the two of the four that support native clustering in their open source tiers. EMQX under BSL 1.1 requires a license file for clusters of more than one node. VerneMQ's source code is Apache 2.0 but its commercial binary packages require a subscription for paid use; the clustering itself has a documented history of reliability challenges worth researching for your scale. 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 three 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 four support MQTT 5. HiveMQ CE has the most spec-focused reputation. EMQX has extensive MQTT 5 support. Mosquitto and VerneMQ both have solid, mature MQTT 5 support.

Can I use these brokers commercially? Yes, but the terms differ. Mosquitto (EPL/EDL) and HiveMQ CE (Apache 2.0) are fully permissive for source and binaries. EMQX under BSL 1.1 permits commercial use with the "competing product" restriction, and cluster deployments require a license file. VerneMQ's source is Apache 2.0, but its pre-built binary packages require a commercial subscription for paid use — you can compile from source to avoid this.

Should I use a hosted broker instead of self-hosting? That depends on your operational preferences. Three of the four 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 four 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.

Which broker supports Sparkplug B natively? EMQX supports Sparkplug B via a plugin with codec functions for decoding and encoding Sparkplug payloads. HiveMQ offers native Sparkplug B support in its Enterprise edition through an extension (not in HiveMQ CE). Mosquitto and VerneMQ do not have native Sparkplug B support — they can carry Sparkplug B traffic as opaque payloads, but the broker itself does not decode or act on Sparkplug messages.

Which broker is best for Unified Namespace (UNS)? Any of the four works for UNS, because UNS is a topic-structure convention rather than a broker feature. The choice comes down to the standard tradeoffs (clustering needs, scale, licensing, integration surface). For UNS deployments that also need broker-native Sparkplug B integration, EMQX or HiveMQ Enterprise are the more natural fits.