Open Source MQTT Broker Comparison: Mosquitto, EMQX, VerneMQ and NanoMQ

This open source MQTT broker comparison looks at four widely used projects, Eclipse Mosquitto, EMQX, VerneMQ and NanoMQ, through the lens of someone who has to run them. You will learn what each broker is good at, what it costs you in operational effort, and how to spin each one up locally in a few minutes. By the end you should know which one fits your project, or whether handing operations to a managed service is the better trade.

Why Compare Open Source MQTT Brokers at All?

Every MQTT deployment needs a broker: the server that accepts connections, authenticates clients and routes each published message to every matching subscriber. If you want a refresher on that role, read what an MQTT broker does. The protocol is standardized, so any compliant client can talk to any compliant broker. What differs between brokers is everything around the protocol: how they scale, how they store sessions, how you configure authentication, how they behave during upgrades, and how much of your time they need.

All four projects below are mature, actively used in production somewhere, and implement MQTT 3.1.1 and MQTT 5.0. None of them is "the best" in the abstract. The right choice depends on connection count, whether you need clustering, what your team already knows, and the licensing terms your organization accepts.

The Four Brokers at a Glance

Eclipse Mosquitto

Mosquitto is the reference point most people start with. It is written in C, maintained under the Eclipse Foundation, and is small enough to run on a Raspberry Pi or inside a container with a few megabytes of memory. Configuration is a single text file, authentication is handled by a password file or the dynamic security plugin, and bridging lets one Mosquitto instance forward topics to another broker.

The main architectural limit is that Mosquitto runs as a single node. There is no built-in clustering, so high availability means an external failover arrangement and a plan for session state. For a single site, a lab, an edge gateway or a few thousand devices on one well-sized server, that is often perfectly fine.

EMQX

EMQX is built on Erlang/OTP and designed around clustering from the start. Multiple nodes form one logical broker, which lets it spread very large connection counts across machines. It ships with a web dashboard, a rich authentication and authorization system, and a built-in rule engine and data integrations in its feature set. A Kubernetes operator is available for cluster deployments.

Licensing deserves attention: EMQX has changed its licensing model across releases, and the terms for the latest versions differ from older open source releases. Read the current license on the EMQX website and confirm it suits your use before you standardize on it.

VerneMQ

VerneMQ is also built on Erlang and offers masterless clustering, plugin hooks for authentication and authorization, and features such as mountpoints for separating topic spaces. The source code is published under the Apache 2.0 license. Its official prebuilt packages and container images come with their own terms (the Docker image asks you to accept an EULA through an environment variable), so check which distribution you are using. As with any project, look at recent release activity and community support channels before you commit.

NanoMQ

NanoMQ, from the EMQ team, is a lightweight broker written in C on top of the NNG messaging library. It targets edge devices and gateways: small footprint, multi-threaded performance on modest hardware, and bridging to an upstream broker. It is a natural fit when you want a local broker on an industrial PC or gateway that forwards selected topics to a central or cloud broker.

Feature and Operations Comparison Table

The table summarizes architecture and typical operational characteristics. Always confirm details against each project's current documentation, since features move between releases.

Two observations stand out. First, single-node brokers are simpler to run but force you to solve availability yourself. Second, clustered brokers solve availability and scale but add moving parts: node discovery, network partitions, rolling upgrades and cluster-aware monitoring.

Try Each Broker Locally with Docker

The fastest way to form an opinion is to run each broker and connect a client. The commands below are for local testing only, with anonymous access enabled. Do not expose these setups to the internet.

# Mosquitto 2.x needs an explicit listener to accept non-localhost connections
mkdir -p mosquitto/config
cat > mosquitto/config/mosquitto.conf <<'EOF'
listener 1883
allow_anonymous true
EOF
docker run -d --name mosquitto -p 1883:1883 \
  -v "$PWD/mosquitto/config:/mosquitto/config" eclipse-mosquitto:2

# EMQX (dashboard on http://localhost:18083)
docker run -d --name emqx -p 1884:1883 -p 18083:18083 emqx/emqx:latest

# VerneMQ (accept the image EULA and allow anonymous for a local test)
docker run -d --name vernemq -p 1885:1883 \
  -e DOCKER_VERNEMQ_ACCEPT_EULA=yes \
  -e DOCKER_VERNEMQ_ALLOW_ANONYMOUS=on vernemq/vernemq

# NanoMQ
docker run -d --name nanomq -p 1886:1883 emqx/nanomq:latest

Then run the same publish and subscribe test against each port:

for port in 1883 1884 1885 1886; do
  mosquitto_sub -h localhost -p $port -i sub-$port -t 'test/compare' -C 1 -W 5 &
  sleep 1
  mosquitto_pub -h localhost -p $port -i pub-$port -t 'test/compare' -m "hello from $port"
  wait
done

Each subscriber should print one message and exit. Once that works, the interesting part begins: enable authentication, add TLS, restart the container while a client holds a persistent session, and see what survives. That exercise tells you more about day-two operations than any feature list.

What the Feature List Does Not Tell You

TLS and Certificates

Every broker supports TLS, but someone has to obtain certificates, renew them before they expire, and reload the broker without dropping every device. Automating that with ACME tooling is very doable, and it is also a classic source of outages when a renewal job silently fails.

Upgrades and Long-Lived Connections

MQTT connections live for days or months. Restarting a single-node broker disconnects every client at once, and all of them reconnect at the same moment. Clustered brokers can roll upgrades node by node, but clients on the restarting node still reconnect. Plan for randomized reconnect backoff on the device side regardless of which broker you choose.

Monitoring and Capacity

You need to watch connection counts, message rates, dropped messages, memory and file descriptors. Mosquitto publishes statistics under $SYS/ topics; the clustered brokers expose HTTP APIs and metrics endpoints. Either way, you build the dashboards and alert rules yourself. Our guide to MQTT broker monitoring lists the metrics worth tracking.

Security Operations

Exposed MQTT ports attract scanners quickly. Hardening means disabling anonymous access, rate-limiting failed logins, keeping the broker and base image patched, and reviewing configuration after every upgrade. The MQTT security best practices article covers the client side of that picture.

How to Choose Between Them

Use these questions as a decision path:

1. How many concurrent connections do you expect in two years? If a single well-provisioned server comfortably covers it, Mosquitto keeps life simple. If not, look at clustered options.
2. Do you need the broker on the edge? For gateways and industrial PCs, Mosquitto or NanoMQ are natural choices, usually bridging to a central broker.
3. Is high availability a hard requirement? Then either run a clustered broker or design external failover for a single-node one, including what happens to persistent sessions.
4. What licensing terms can your organization accept? Read the current license of the exact version and distribution you will deploy.
5. Who will be on call? A broker is infrastructure. If nobody on the team wants to own patching, certificates and 3 a.m. pages, factor that in now.

If question five gives you pause, compare the effort with a self-hosted vs managed MQTT broker analysis before you decide.

When a Managed Service Makes More Sense

Open source brokers are excellent software. The cost of running them is mostly people's time: setting up TLS, building monitoring, handling upgrades, tuning limits and responding to incidents. For many IoT teams, that time is better spent on devices and applications.

A managed MQTT broker moves those tasks to the provider. With ConnectMQ you create a broker in the portal and receive a username, password and client ID. The endpoints are ready on TCP 1883, TLS 8883, WebSocket 8083 and Secure WebSocket 8084 (path /mqtt) with a Let's Encrypt certificate, and both MQTT 3.1.1 and MQTT 5.0 clients work unchanged. Because MQTT is a standard, the same client code you tested against Mosquitto or EMQX connects to ConnectMQ by changing host, port and credentials.

ConnectMQ also adds tools that you would otherwise assemble yourself: an in-browser MQTT client, a live topic explorer, a dashboard, a devices view organized by ISA-95 levels, and threshold alert rules with an alerts log. Plans range from a free Serverless tier on a shared cluster through Dedicated isolated clusters to BYOC in your own cloud account, so the hosting model can follow your requirements. The cloud MQTT broker guide explains how those models compare.

A sensible pattern is hybrid: keep Mosquitto or NanoMQ at the edge for local resilience, and bridge selected topics to a hosted broker that your cloud applications and dashboards use.

Test Against a Hosted Broker in Minutes

Before choosing, point your existing client at a hosted broker and compare the experience with your local containers. The free public MQTT broker at broker.connectmq.com needs no account; use a unique client ID and topic prefix, and remember that public topics are readable by anyone.

mosquitto_sub -h broker.connectmq.com -p 1883 -i cmp-sub-7f3a \
  -t 'connectmq/demo/7f3a/compare' -v &
mosquitto_pub -h broker.connectmq.com -p 1883 -i cmp-pub-7f3a \
  -t 'connectmq/demo/7f3a/compare' -m 'hello from the comparison test'

For production data, create a private broker and connect over TLS on port 8883 with your own credentials.

Get Started with ConnectMQ

If you would rather spend your time on devices and applications than on broker operations, create a free Serverless broker at app.connectmq.com. No credit card is required, and you can move to Dedicated or BYOC later without changing your MQTT client code.

Frequently Asked Questions

Which open source MQTT broker is best for beginners?

Mosquitto is usually the easiest place to start. It installs in minutes, uses one readable configuration file, and is documented in countless tutorials.

Can Mosquitto be clustered?

Not natively. Mosquitto runs as a single node; you can bridge instances or build external failover, but for a true multi-node cluster you would look at a broker designed for clustering.

Is EMQX still open source?

EMQX licensing has changed across releases, so the answer depends on the version you deploy. Check the license published with the exact release you plan to use.

Can I switch from an open source broker to a managed one later?

Yes. MQTT is a standard, so clients usually only need a new host, port and credentials. Review broker-specific features you rely on, such as rule engines or plugins, because those do not move automatically.