Kafka vs RabbitMQ

Quick verdict

This page is for developers and architects choosing a messaging layer for building, facilities and industrial systems: streams of BMS and meter readings, alarm events, and the work orders and notifications a CAFM or CMMS sends between services. Both products move messages; neither is a database for querying history. For how messaging fits between devices, databases and analytics, see the time-series and IoT data hub; for the device protocol question see Kafka vs MQTT.

Apache Kafka is an open source (Apache 2.0) event streaming platform. Its documentation describes publishing and subscribing to streams of events, storing them durably, and processing them as they occur or retrospectively. The latest release when checked was 4.4.0 (22 October 2026). Since 4.0, Kafka runs only in KRaft mode, without ZooKeeper. See the Apache Kafka guide.

RabbitMQ is an open source message and streaming broker licensed under the Mozilla Public License 2.0, with a commercial edition (Tanzu RabbitMQ) and support from Broadcom. It supports AMQP 0-9-1, AMQP 1.0, MQTT 3.1, 3.1.1 and 5.0, and STOMP. Its replicated data structures are quorum queues and streams; classic queue mirroring was removed in 4.0. The latest release series when checked was 4.4 (4.4.0, 20 October 2026).

Side by side

Key differences

Log versus queue: what the broker remembers

Kafka's design documentation explains the core trade-off. Most messaging systems record on the broker which messages each consumer has received and acknowledged, then delete them. Kafka instead divides a topic into totally ordered partitions, each read by exactly one consumer in a consumer group, so a consumer's position is just one number per partition: the offset. Consumers can rewind that offset and reprocess, which the documentation itself notes violates the common contract of a queue. Retention is a topic setting (retention.ms defaults to 7 days), and log compaction can keep the latest value per key instead.

RabbitMQ's queues are ordered collections of messages delivered first in, first out. Publishers send to an exchange, bindings route copies to queues, and consumers acknowledge each message, after which it is removed. That model makes per-message work distribution natural: ten worker instances can compete for jobs on one queue, a slow job does not block others, and a failed job is redelivered or dead-lettered. The trade-off is that a queue is not a history; once a message is acknowledged it is gone, and RabbitMQ's documentation notes that most queues are optimised for being close to empty.

For a CMMS the difference is concrete. "AHU-01 supply-air temperature was 13.4 at 09:00" is an event: several systems want it, and a new analytics job might want last month's events. "Create work order for AHU-01 filter change" is a task: exactly one worker should process it, with retries and an error queue if the CMMS API is down.

RabbitMQ queue types: classic, quorum and streams

Accuracy matters here because older comparisons describe RabbitMQ before 4.0.

• Classic queues are the original type and, since RabbitMQ 4.0, are not replicated. The documentation positions them for cases where data safety is not a priority, and temporary or exclusive queues.
• Quorum queues are durable, replicated queues based on the Raft consensus algorithm, and the documentation says they should be the default choice for a replicated, highly available queue. Publisher confirms are issued only after a quorum of members has the message. The quorum queue documentation states: "Starting with RabbitMQ 4.0, the delivery limit for quorum queues defaults to 20." A message that exceeds the limit is dropped unless a dead-letter target is configured, and the documentation recommends "that all quorum queues have a dead letter configuration of some sort to ensure messages aren't dropped and lost unintentionally". Quorum queues also offer consumer timeouts and delayed retry. The documentation advises against them for temporary queues, the lowest possible latency, very long backlogs (5 million messages or more) and large fan-outs, where streams fit better.
• Streams model an append-only log that consumers read without removing messages. Consumers attach at the first, last or next message, a numeric offset, or a timestamp, and retention is set by maximum age or size. Super streams partition a large stream across nodes, and single active consumer keeps one reader per partition to preserve order. Streams do not support message priority, dead-letter exchanges or per-message TTL.

// Illustrative configuration, not run here: adapted from the RabbitMQ documentation;
// check every setting against the documentation for your version before use.
Map<String, Object> arguments = new HashMap<>();
arguments.put("x-queue-type", "stream");
arguments.put("x-max-length-bytes", 20_000_000_000L); // retention by size; 20 GB is illustrative
channel.queueDeclare("bms-readings", true, false, false, arguments);

# RabbitMQ: delivery limit and dead-letter exchange for work-order queues.
# Illustrative configuration, not run here: adapted from the RabbitMQ quorum queue documentation;
# check every setting against the documentation for your version before use;
# the limit of 5 and the names are illustrative, not recommended values
rabbitmqctl set_policy cmms-overrides \
    "^cmms\." '{"delivery-limit": 5, "dead-letter-exchange": "cmms.dlx"}' \
    --priority 10 \
    --apply-to "quorum_queues"

Kafka consumer groups and share groups

In a Kafka consumer group each partition is assigned to one member, which gives ordering per partition and simple scaling up to the number of partitions. Choose the partition key carefully: keying BMS readings by point or asset keeps each point in order, but a hot key cannot be spread across consumers. Delivery is at least once by default; the idempotent producer prevents duplicates from producer retries, and transactions provide exactly-once processing for read-process-write pipelines inside Kafka. That does not extend to a database: a database sink is at-least-once with idempotent writes, and should only be described as exactly once when offsets are stored in the same transaction as the data and a fencing check rejects writes from a consumer that has lost its partitions (see Kafka consumer idempotency for sensor streams).

Share groups (Queues for Kafka, KIP-932) are documented as production-ready since Kafka 4.2. Consumers in a share group cooperatively consume records from the same partitions, the number of consumers can exceed the number of partitions, records are acknowledged individually, and delivery attempts are counted so that unprocessable records can be rejected. A fetched record is locked for 30 seconds by default (share.record.lock.duration.ms). The documentation recommends share groups where records are processed one at a time rather than as an ordered stream. The Kafka 4.4.0 upgrade notes add: "Share groups now support dead-letter queue functionality as outlined in KIP-1191." Records released beyond the maximum delivery count or rejected by the consumer become eligible; the feature is enabled when the cluster feature share.version is upgraded to 2, and a DLQ topic is named per share group with the dynamic config errors.deadletterqueue.topic.name. Because this arrived only in 4.4.0 (October 2026), check your broker version and test it before relying on it. In our view, routing by exchange and binding and message priorities remain RabbitMQ strengths that share groups do not replace.

Routing, protocols and the IoT edge

RabbitMQ routes on the broker. A topic exchange can send site.hq.alarm.critical to the on-call notification queue and site.*.alarm.# to an audit queue without the publisher knowing either. Because RabbitMQ also speaks MQTT through a plugin that ships with the distribution, devices can publish over MQTT and AMQP consumers can read the same messages; the MQTT plugin maps topics onto a topic exchange and supports QoS 0 and 1. That makes RabbitMQ a reasonable single broker for a small IoT estate with both device messages and back-end tasks.

Kafka does no broker-side routing: producers choose a topic and a key, and consumers subscribe to topics and filter in code or with Kafka Streams. Integration with databases and other systems is through Kafka Connect, and devices normally reach Kafka through an MQTT bridge rather than directly. See designing an IoT data pipeline with Kafka.

Operations, sizing and security

Kafka sizing is driven by write rate times retention times replication factor, and by partition count; tiered storage can move older segments to remote storage. A Kafka 4.x cluster runs brokers and KRaft controllers, and clusters still using ZooKeeper must migrate through the 3.9 bridge release. RabbitMQ sizing depends on queue type: quorum queues keep data on disk on every member and are not meant for very large backlogs, while streams persist everything to disk and are designed for larger amounts of data. In both, monitor consumer lag or queue depth: in a building portfolio, a growing backlog usually means a database sink or CMMS integration has stalled.

Kafka supports TLS, SASL authentication and ACLs on topics and groups. RabbitMQ has users, virtual hosts for multi-tenancy, per-vhost permissions, TLS and OAuth 2.0. Either way, keep devices on their own credentials and topics, and keep consumer services idempotent, because both systems deliver at least once in normal operation. See Kafka consumer idempotency for sensor streams.

Pricing and licensing

Apache Kafka is distributed under the Apache License, Version 2.0, whose copyright grant reads in part: "each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license", subject to the licence's terms and conditions. Self-managed cost is the infrastructure (brokers, controllers, disks, cross-zone network) and operations staff. Kafka's documentation notes that fully managed services are offered by a variety of vendors; their pricing models differ (cluster size, throughput, partitions, storage), so compare them on your own workload. We did not check individual vendors' price lists for this page.

RabbitMQ is licensed under the Mozilla Public License 2.0: the project home page states "Free under the Mozilla Public License 2.0", and the licence grants each recipient "a world-wide, royalty-free, non-exclusive license" on the terms it sets out. Broadcom sells Tanzu RabbitMQ, a commercial edition with 24/7 support, longer lifecycle and extra features, on quotation; no public price list was found on rabbitmq.com. Several cloud providers and specialist hosts offer managed RabbitMQ; we did not check their price lists for this page. Community support for a release series is time-limited, which the release information page lists per series.

Licence descriptions here are factual summaries with quotes from the official licence texts and vendor pages; they are not legal advice. Read the licence and take advice for your situation.

Pricing checked on the vendors' official pages on 27 October 2026. Prices change; confirm before buying.

Where each one leads

Limitations

When to choose each

When neither is right

• A few hundred jobs a day inside one application (an illustrative volume): a PostgreSQL table used as a queue with SELECT ... FOR UPDATE SKIP LOCKED may be enough, and keeps jobs in the same transaction as the data. We have not run this pattern under concurrent workers here; the PostgreSQL documentation describes SKIP LOCKED as a way to avoid lock contention with multiple consumers of a queue-like table, at the cost of an inconsistent view of the data.
• Devices on constrained networks need a protocol, not a back-end platform: see Kafka vs MQTT.
• You need to query readings by time and asset: that is a database job; see TimescaleDB vs InfluxDB and ClickHouse vs TimescaleDB.
• Data moves in nightly batches between systems: an ETL or ELT tool is simpler; see ETL vs data pipeline.

Final recommendation

Frequently asked questions

Sources

• Apache Kafka: introduction
• Apache Kafka 4.4: design (consumer position, delivery semantics, share consumers)
• Apache Kafka 4.4: upgrade notes
• Apache Kafka 4.4: topic configuration
• Apache Kafka 4.4: KRaft operations
• Apache Kafka downloads (releases)
• RabbitMQ home page
• RabbitMQ: queues
• RabbitMQ: classic queues
• RabbitMQ: quorum queues
• RabbitMQ: streams and super streams
• RabbitMQ: consumers
• RabbitMQ: MQTT plugin
• RabbitMQ: release information
• RabbitMQ server GitHub repository (licence)
• PostgreSQL documentation: SELECT (locking clause, SKIP LOCKED)
• Apache Software Foundation: Apache License, Version 2.0
• Mozilla: Mozilla Public License 2.0
• Apache Kafka 4.4 javadoc: ConsumerRebalanceListener (partitions reassigned before revocation)

Checked October 2026.

How we research comparisons: our editorial method.