★ 32,799JavaApache-2.0updated Jun 2026
best for teams that need the deepest connector ecosystem and can run real Kafka ops
Kafka is still the default if you're building a serious event pipeline. The connector ecosystem — Kafka Connect, Debezium, every data platform shipping a Kafka sink — is bigger than anything else on this list, and KRaft mode finally killed the ZooKeeper dependency that made clusters miserable to run for a decade. Streams processing lives in the same repo as the broker, so you're not chasing version drift between two separate projects.
The cost is that it's still the heaviest thing here to operate. A consumer group rebalance under load is still the kind of event that pages someone, and getting session timeouts and heartbeat intervals right takes real tuning, not defaults. There's no schema registry built in either — you're adding Confluent's or rolling your own, and every team learns that the hard way when a producer ships a breaking change.
If you want Kafka's API without the JVM and the ops tax, that's Redpanda. If you actually need the connector ecosystem Kafka has no equal for, stay here.
Our full take →GitHub ↗
★ 13,733JavaScriptNOASSERTIONupdated Jun 2026
best for complex routing and classic task-queue workloads, not just streaming
RabbitMQ is the one built for task queues and routing, not just streaming. If you're sending work to the right one of twenty consumers based on a routing key, AMQP's exchange model handles that in a way pub/sub topics on NATS or Kafka don't. Quorum queues gave it real durability guarantees for the first time, and Streams added Kafka-style replay without standing up a second system.
Erlang is both the reason it's reliable and the reason it's occasionally a pain — when a node hits a memory alarm or the cluster partitions, you're reading BEAM crash dumps, not a stack trace you can search for in five minutes. The jump from one node to a cluster is a bigger step than the docs suggest, and AMQP 1.0 still feels bolted on; the management UI treats it like a second-class citizen next to 0-9-1.
Pick this over Kafka or Pulsar when the problem is routing and queueing, not firehose event streaming.
Our full take →GitHub ↗
★ 12,200C++updated Jun 2026
best for teams who want the Kafka API without running ZooKeeper or a JVM
Redpanda is what you reach for when you want Kafka's wire protocol without running a JVM or a ZooKeeper ensemble. It's one binary with Raft consensus built in, and the Seastar thread-per-core architecture — the same engine under ScyllaDB — gets predictable tail latency without GC pauses eating into it. Tiered storage to object storage comes standard, so keeping everything forever doesn't mean a linearly growing disk bill.
The license is the thing to know going in: it's BSL, not Apache 2.0, so running a competing streaming service rather than just using it internally means a commercial license. Kafka compatibility is close but not perfect — specific producer configs and transactional edge cases differ enough that porting a non-trivial Kafka workload will surface surprises. Building from source is also a real undertaking; budget for the prebuilt packages instead.
Against Kafka, it's the same API with far less operational weight. Against NATS, it's a heavier tool for people who specifically want that Kafka compatibility.
Our full take →GitHub ↗
★ 15,269JavaApache-2.0updated Jun 2026
best for multi-tenant platforms needing built-in geo-replication and tiered storage
Pulsar's pitch is pub/sub and classic queue semantics on the same topic, with geo-replication and multi-tenancy built in rather than bolted on. If different teams need isolated namespaces and quotas, and you need to replicate across regions without adding MirrorMaker on top of Kafka, Pulsar does it natively.
The price is running three distributed systems — brokers, BookKeeper for storage, and ZooKeeper — before a single message gets through, where RabbitMQ or NATS gets you there with one. The non-Java clients lag noticeably behind the Java one, and the connector ecosystem is nowhere near Kafka's, so coming from Kafka means rebuilding integrations rather than reusing them. broker.conf has hundreds of knobs, and the defaults aren't the ones you want in production.
Choose Pulsar over Kafka specifically for multi-tenant, geo-replicated workloads. For anything simpler, the extra moving parts aren't worth it.
Our full take →GitHub ↗
★ 20,018GoApache-2.0updated Jun 2026
best for cloud-native microservices that want one tiny, fast binary
NATS is the answer when Kafka feels like too much and Redis pub/sub feels too thin. It's one small Go binary, the subject-based routing with wildcards is genuinely fast, and JetStream gets you durable streams and replay without Kafka's operational weight. A third-party security audit from Trail of Bits is also more scrutiny than most brokers on this list have had.
JetStream's cluster failure recovery is the rough edge — the test suite has dedicated files for jetstream cluster edge cases and race conditions, which tells you these aren't fully solved problems yet. The config format is its own syntax, not YAML or TOML, so new team members hit a real onboarding wall. The MQTT bridge is a convenience, not a dedicated broker — if IoT is the actual job, EMQX or Mosquitto will serve you better.
Pick NATS over RabbitMQ or Kafka when the system is cloud-native microservices and you want the smallest thing that still does durable delivery.
Our full take →GitHub ↗
★ 16,396ErlangNOASSERTIONupdated Jun 2026
best for IoT fleets needing an MQTT broker that scales to millions of devices
EMQX is built for scale Mosquitto can't touch — millions of concurrent MQTT connections, MQTT over QUIC for clients that move between networks mid-session, and a rule engine with dozens of sink integrations that replaces a whole bridge-service layer you'd otherwise run yourself. For connected vehicles or large IoT fleets, it's the only broker here actually built for that scale.
Read the license carefully: since the BSL change in v5.9.0, clustering beyond a single node needs a license from EMQ, so open source really only covers single-node use, and any real HA deployment is commercial. Erlang expertise is scarce, so debugging a performance issue or writing a plugin means either your team already knows OTP or you're stuck. The "100M concurrent connections" number is a best-case benchmark with minimal per-connection state; real workloads with persistent sessions and an active rule engine hit hardware limits well before that.
Mosquitto is the better default if you don't actually need that scale — EMQX earns its complexity only once you do.
Our full take →GitHub ↗
★ 10,973CNOASSERTIONupdated May 2026
best for small or resource-constrained MQTT deployments
Mosquitto is the smallest, simplest option here — a single C binary that runs comfortably on a Raspberry Pi, with complete MQTT 5.0 support and a dynamic security plugin that handles ACLs at runtime without a restart. It's had serious fuzzing attention through OSS-Fuzz, which matters more for a broker that's often sitting on the open internet talking to devices you don't fully control.
What it doesn't do is scale past one node. There's no clustering story at all, so once you outgrow a single instance you're building a bridge topology yourself or moving to EMQX. The C client API is callback-heavy and genuinely awkward until you've read the source, and the dashboard is a Chart.js page good for spot-checks, not something you'd monitor production with.
If EMQX is the broker for a fleet, Mosquitto is the broker for a device or a small deployment that's going to stay small.
Our full take →GitHub ↗
// questions people ask
Before you choose
Kafka or Redpanda — which one should I actually run?
If you need Kafka's broader ecosystem — Connect, Streams, the whole Confluent universe of integrations — or you already have Kafka ops expertise, stay with Kafka. If you just want the protocol without the JVM and can live with the BSL license, Redpanda gets you there with far less operational overhead.
Is RabbitMQ or NATS better for microservices?
NATS is lighter and faster to stand up for simple pub/sub or request/reply between services. RabbitMQ wins once you need real routing logic — exchanges, topic matching, dead-letter queues — rather than just getting a message from A to B.
EMQX or Mosquitto for an IoT project?
Mosquitto is the right default for a single deployment or a modest device count — small, well-tested, and free of license strings. EMQX is built for scale into the millions of connections, but clustering for HA is commercial since the BSL change in v5.9.0, so plan for that cost before you commit.
Does Pulsar make sense if I'm already on Kafka?
Usually not. Pulsar's native multi-tenancy and geo-replication are real advantages, but Kafka's connector ecosystem is much bigger, and moving off Kafka means rebuilding most of your integrations. It's worth it only if multi-tenant isolation or built-in geo-replication is the actual requirement, not a nice-to-have.
These are the brokers we'd actually run, not a popularity ranking — if you want the same kind of honest read on whatever you're building next, the weekly email covers one new repo at a time.