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 I put it in a talk on Kafka operational issues, as much as I love 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.
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. Our 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 I refuse 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.
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 we surveyed the public Kafka benchmarks for our 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. Our 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.
The migration story we keep returning to in our 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.
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.