Kafka and RabbitMQ perform differently because their storage models differ. Kafka appends messages to a partitioned log and serves reads sequentially, which favours sustained throughput on small messages. RabbitMQ routes each message individually through exchanges into queues, which favours flexible delivery over raw volume.
The performance question is usually a fit question in disguise. Kafka handles millions of small messages a second extremely well and handles large messages poorly, so the honest first step is characterising your workload, not reading benchmark charts. As Chad Harris put it in a talk on Kafka operational issues, as much as he loves Kafka, if it is taking you more than five minutes to process a message, Kafka is not the right tool for that particular use case. A comparison page that starts anywhere other than message size and processing time is answering the wrong question.
A RabbitMQ message-rate panel and a Kafka throughput panel from the same workload.
At a glance
Apache Kafka and RabbitMQ are scored here on the same six criteria, 60 points in all: Apache Kafka 39 out of 60, RabbitMQ 37 out of 60. Apache Kafka takes its best score on Sustained throughput (9 out of 10) and its lowest on Large messages (3 out of 10). Run cost a year, estimate: $11,520 in operator time. RabbitMQ takes its best score on Routing (10 out of 10) and its lowest on Large messages (3 out of 10). Run cost a year, estimate: $11,520 in operator time.
Hard throughput and latency metrics
Kafka throughput scales with partition count and the network, not with a single queue process. Published tuning guides put single-partition producer throughput on modern hardware with LZ4 compression and acks=all at: 10-50 MB/s, with consumer throughput higher. Brokers are I/O bound and the network is usually the first bottleneck, with more RAM extending the page cache. The guide to Kafka cluster management covers these tuning levers in full.
RabbitMQ’s replicated queue type trades latency for throughput by design. The RabbitMQ quorum queue documentation states the underlying Raft consensus algorithm carries inherently higher latency due to its data safety features, and that throughput decreases as message sizes and node counts grow.
Message size dominates both systems, and RabbitMQ’s quorum queues degrade the same way Kafka does as payload sizes grow. Kafka message size best practice covers where the limits sit and why raising them costs throughput.
No published throughput number pairs Kafka and RabbitMQ on identical hardware from a neutral primary source, so treat any comparative figure as unproven unless it links a benchmark methodology you can read.
Production edge cases and trade-offs
Durability settings are the biggest performance lever on both systems. In Kafka, replication factor and acks=all add inter-broker round trips per batch. In RabbitMQ, publisher confirms on a quorum queue wait for a Raft majority to persist to disk.
Ordering has a cost in Kafka. Strict ordering exists only within one partition, so an order-dependent workload cannot spread across partitions for throughput. Partition rigidity and rebalancing overhead are the operational price of the log model.
Consumer bottlenecks differ in kind. A slow RabbitMQ consumer holds up its queue’s competing consumers. A slow Kafka consumer builds lag on its partitions without blocking other groups, and backpressure shows up as consumer lag rather than as queue depth.
Producer compression combined with sensible batching is the highest-leverage Kafka tuning available without architectural changes.
The edge case Chad Harris refuses to budge on is max.message.bytes. Teams ask for exceptions constantly. The pitch is always the same: we understand the risk, it is a low throughput topic, it will be fine. Then six months later the topic becomes popular, the messages are still big, and the throughput problems arrive exactly where the exception was granted. Message size limits are a performance guardrail for the whole cluster, not a per-team preference. If a payload does not fit, the answer is claim-check references or chunking, not a bigger limit.
You're introducing unbounded queues everywhere effectively called topics. They've got no limit to their capacity. And so immediately you have a potential issue with back pressure.
Derek Troy-West, Co-founder and CEO of Factor House
Benchmark methodology validation
A credible comparison states its tools, hardware and configuration. Kafka ships kafka-producer-perf-test.sh and kafka-consumer-perf-test.sh in the bin/ directory of the official distribution. The OpenMessaging Benchmark is the cross-system framework that runs the same workload definitions against Kafka and RabbitMQ on declared cloud instance types.
Vendor benchmarks typically use 1 KB messages, so results do not transfer to workloads with larger payloads without re-testing. Identical instance types, disk classes and replication settings on both systems are the minimum for a comparison to mean anything.
When Factor House surveyed the public Kafka benchmarks for the message-size research, the representative message sizes ran from 100 bytes to 10 KB. That range is the tell. If your production payloads sit outside it, every published number you are comparing against was measured on a different workload from yours, and the only benchmark that will answer your question is one you run yourself with the perf-test tools above on your own instance types.
Architectural justification data
Cost per unit of throughput, not peak throughput, is the number that decides migrations. Kafka’s storage-compute coupling becomes expensive at high throughput because partition data lives on specific brokers, and cloud block storage and inter-availability-zone traffic dominate the bill at scale, the problem KIP-1150 diskless topics exists to address.
Queue semantics arrived in Kafka itself. Share groups (KIP-932) allow more consumers than partitions with per-message acknowledgement, which removes a structural reason to run RabbitMQ alongside Kafka for competing-consumer workloads. The KIP-932 explainer walks through the share-group model in detail.
Use-case alignment stays the honest test. Log aggregation, event sourcing and replayable streams fit the log model. Complex per-message routing, priority queues and request-reply fit the broker model.
Both systems are marked out of 10 on six criteria, 60 points in all, with no criterion weighted above another. Sustained throughput is volume held over time on small messages, and large messages is how each copes as payloads grow. Ordering, routing and parallelism carry the same marks as in the difference between Kafka and RabbitMQ, so each system scores the same on them on both pages. Slow-consumer isolation asks whether one slow consumer holds up anyone else.
The migration story that keeps coming up in the production-architecture research is DoorDash, which first adopted Kafka in mid-2019 after repeated RabbitMQ failures caused order checkout and dispatch outages under peak load, and now runs around six billion messages a day. The instructive part is not that Kafka won. It is that the failure mode was workload shape: a task-processing system pushed to streaming volumes. Teams that hit RabbitMQ limits at sustained high volume are usually discovering the storage-model boundary, not a tuning problem, and no amount of queue tuning moves that boundary. How the two systems differ structurally is covered in the difference between Kafka and RabbitMQ, part of the complete Kafka guide.
Rank 1 Apache Kafka
39 out of 60 Total
- Storage model
- Partitioned append-only log
- Throughput scales with
- Partition count and the network
- Run cost a year, estimate
- $11,520 in operator time
- Sustained throughput
- 9 out of 10
- Large messages
- 3 out of 10
- Ordering
- 9 out of 10
- Slow-consumer isolation
- 8 out of 10
- Routing
- 5 out of 10
- Parallelism
- 5 out of 10
Why these scores for Apache Kafka
- Sustained throughput 9 out of 10
- Sequential reads from a partitioned log favour sustained throughput on small messages, with published tuning guides at 10 to 50 MB/s for a single partition producer, and throughput scales with partition count.
- Large messages 3 out of 10
- It handles millions of small messages a second well and large messages poorly, and raising the size limit costs throughput for the whole cluster.
- Ordering 9 out of 10
- Ordering holds within a partition, and a keyed producer keeps one entity’s records together, short of 10 because the guarantee is per partition, not across a topic.
- Slow-consumer isolation 8 out of 10
- A slow consumer builds lag on its own partitions without blocking other consumer groups.
- Routing 5 out of 10
- Keys map records to partitions and routing is producer-side, so dynamic rules need new topics or a filtering consumer.
- Parallelism 5 out of 10
- The partition count sets the ceiling on consumers in a group, and share groups under KIP-932 lift it only on Kafka 4.0 or newer.
Where it fits. A partitioned log read sequentially, built for volume held over time: log aggregation, event sourcing and streams that consumers replay.
Compare Difference between Kafka and RabbitMQKafka message size best practice
Rank 2 RabbitMQ
rabbitmq.com
37 out of 60 Total
- Storage model
- Queues fed by exchanges
- Replicated queue type
- Quorum queues on Raft
- Run cost a year, estimate
- $11,520 in operator time
- Sustained throughput
- 5 out of 10
- Large messages
- 3 out of 10
- Ordering
- 5 out of 10
- Slow-consumer isolation
- 4 out of 10
- Routing
- 10 out of 10
- Parallelism
- 10 out of 10
Why these scores for RabbitMQ
- Sustained throughput 5 out of 10
- Each message is routed individually through exchanges, which favours flexible delivery over raw volume, and quorum queues trade throughput for data safety by design.
- Large messages 3 out of 10
- The RabbitMQ quorum queue documentation states that throughput decreases as message sizes grow, the same way Kafka degrades.
- Ordering 5 out of 10
- FIFO holds per queue until consumers compete, so end-to-end order is not preserved under parallelism.
- Slow-consumer isolation 4 out of 10
- A slow consumer holds up its queue’s competing consumers.
- Routing 10 out of 10
- Exchanges route inside the broker by direct, fanout, topic and headers rules, and complex per-message routing is the case this page gives to the broker model.
- Parallelism 10 out of 10
- Any number of competing consumers can read one queue, the model KIP-932 exists to bring to Kafka.
Where it fits. A broker that routes each message to a queue and hands it to whichever consumer takes it next, built for per-message routing, priority queues and request-reply.
Compare What is RabbitMQ?Difference between Kafka and RabbitMQ
FAQ
Which is better, RabbitMQ or Kafka?
Neither is better outright, because the two store messages differently. Kafka’s partitioned log favours sustained throughput on small messages and replayable streams. RabbitMQ’s routed queues favour complex per-message routing, priority queues and request-reply. Message size and processing time per message are the two workload facts that decide the fit.
Is Kafka still relevant?
Yes. Queue semantics are arriving in Kafka itself through share groups (KIP-932), which lets competing-consumer workloads run on Kafka without a second broker, and large production migrations from RabbitMQ to Kafka continue where workloads reach sustained streaming volumes.
How these options were scored
Every option is scored from 0 to 10 on each criterion, from the evidence and sources this page cites, and the reason for each score is on its card. Each criterion counts once, for a total out of 60. The options are listed by total.