Message Broker Throughput

RabbitMQ 4.2 vs Kafka 4.2 (KRaft) vs NATS 2.12 (JetStream)

I started using NATS in one of my projects and was generally happy with it, but I wanted to verify the performance claims for myself. Is it really as fast as people say, or is that just marketing and cherry-picked benchmarks? The best way to find out was to write my own tests and compare NATS against the two most common alternatives: RabbitMQ and Kafka.

This post covers throughput testing of all three brokers on two messaging patterns: async producer-consumer queue, and request-reply. Request-reply is not the typical use case for message brokers, but NATS supports it natively, so it was worth measuring how the others perform when forced into that pattern.

Test Environment

All three brokers ran in Docker containers on the same host. No custom tuning was applied to any broker: default configurations only.

Broker Versions

Idle RAM (Cold Start)

Measured via docker stats on freshly started containers with no accumulated data or active connections.

Kafka's JVM-based architecture is immediately visible: 54x the memory of NATS and 2.7x of RabbitMQ on cold start. NATS is the lightest at 6 MiB.

BenchmarkDotNet Configuration

• 3 warmup iterations, 10 measured iterations per scenario
• InvocationCount = 1, UnrollFactor = 1 (each iteration is a single benchmark call)
• RunStrategy = Monitoring
• GC: non-concurrent, forced collections, non-server mode
• ThreadPool: minimum 100 worker + 100 I/O completion port threads

Test Parameters

The message counts and payload sizes were chosen to cover two dimensions: the number of concurrent messages the broker must route, and the size of individual payloads. Counts are inversely proportional to payload size to keep total benchmark runtime within a few minutes per scenario while still loading the broker enough to reveal its throughput characteristics.

Async Queue (250 concurrent publishers, 1 consumer)

Request-Reply (150 concurrent publishers)

The async pattern uses more publishers (250 vs 150) and reaches larger payloads because bulk throughput is the primary concern. Request-reply uses fewer messages and smaller payloads reflecting the typical RPC use case where latency matters more than volume.

Implementation Details

Async Queue (Producer-Consumer)

All three implementations follow the same structure: N publishers concurrently push messages into a queue/topic/stream, one consumer reads everything. The benchmark measures wall-clock time from the first publish to the last received message.

RabbitMQ (RabbitMQ.Client v7.2.1): persistent messages, QoS prefetch = 100, manual ACK, separate connections for publisher and consumer.

Kafka (Confluent.Kafka v2.13.2): idempotent producer, 1 GB write buffer, manual offset commit, single partition, consumer group ID randomized per iteration.

NATS JetStream (NATS.Net v2.7.3): file-backed stream, workqueue retention, async persistence, explicit ACK, 1 GB writer buffer.

Request-Reply

NATS has native request-reply: RequestAsync sends a message and returns a response in a single call. The broker handles response routing internally.

RabbitMQ and Kafka lack this primitive. For both, request-reply was implemented via correlation IDs:

1. Requester generates a UUID, attaches it to the message, stores a TaskCompletionSource in a ConcurrentDictionary
2. Responder receives the message, echoes the correlation ID back on a dedicated reply queue/topic
3. Requester's reply listener matches the ID and completes the corresponding task

Each "request" in RabbitMQ/Kafka involves 4 broker operations (publish request, consume request, publish reply, consume reply) vs 1 round-trip in NATS.

Results: Async Queue

All values are P95 (95th percentile) completion time in milliseconds. Lower is better. Ratio columns show time relative to NATS JetStream (baseline).

P95 Completion Time (ms)

Messages per Second (at P95)

On small to medium payloads (up to 4 KB), NATS JetStream processes messages 1.6-1.8x faster than RabbitMQ at P95. On large payloads (64 KB+), RabbitMQ takes the lead at 61-94% of NATS's time. RabbitMQ allocates 7-12 MB managed memory for large payloads, while NATS allocates 368-401 MB. AMQP framing is more efficient for large contiguous payloads.

Kafka is 9-38x slower than NATS at P95. This is expected: Kafka's commit log architecture adds overhead that only pays off with horizontal scaling across multiple partitions and nodes.

Managed Heap Allocation

RabbitMQ consistently uses the least managed memory. NATS allocates significantly more due to the 1 GB writer buffer configuration. Kafka's allocations spike with large payloads (318-323 MB) due to its own producer buffer (QueueBufferingMaxKbytes = 1 GB).

Results: Request-Reply

All values are P95 completion time. Ratio columns show time relative to NATS (baseline).

Messages per Second (Request-Reply, at P95)

NATS is 46-92x faster than Kafka and 77-104x faster than RabbitMQ at P95. This is the difference between a native protocol primitive (one network round-trip) and an application-level emulation (four broker operations per request).

RabbitMQ is the slowest in all request-reply scenarios, with P95 degrading linearly: 12.2s for 5K messages, 21.4s for 10K, 41.4s for 25K. The per-message overhead is roughly constant at ~1.7 ms, dominated by the ACK cycle on both request and reply queues.

Kafka also shows high tail latency: P95 reaches 36.6s on the 25K scenario (Mean is 23.3s), indicating consumer group coordination and offset management overhead amplified in what is effectively a synchronous request pattern.

Broker Comparison

RabbitMQ 4.2

Apache Kafka 4.2

NATS 2.12 with JetStream

Conclusion

For new projects that need a general-purpose message broker, NATS is the most practical starting point.

It provides a feature set comparable to Kafka: persistence with replay, exactly-once delivery, stream processing primitives, key-value and object stores. At the same time, its throughput on small-to-medium payloads matches or exceeds RabbitMQ, and it handles request-reply 46-105x faster than either alternative at P95 thanks to native protocol support.

The operational cost is also lower. A single binary with one flag gives you a persistent, JetStream-enabled broker consuming 6 MiB of RAM on cold start. Compare that to Kafka's 327 MiB.

RabbitMQ remains a strong choice when the workload is primarily large payloads (64 KB+) or when the team has deep AMQP expertise. Kafka is still the right tool for large-scale event streaming, CDC pipelines, and scenarios where partition-based parallelism and the Connect/Streams ecosystem matter.

But as a default choice for a new distributed system? NATS delivers Kafka-class features at RabbitMQ-class speed, with less operational overhead than either.