208 BKuttiDB / message
9 BRabbitMQ / message
KuttiDB writes delivery and acknowledgement records per message. Consume-side write volume remains an open issue.
← Back to the numbersThe numbers.
KUTTIDB / BENCHMARK NOTEBOOK
The numbers.
And the whole story.
Recorded workloads, explicit durability settings, and the tradeoffs behind each result. Reproducible evidence for one small server.
Published reference results · source retrieved 13 September 2026Original report ↗
1 shared vCPUAMD EPYC 9354P
3.8 GiB RAMUbuntu 26.04.1 · ext4
256 per batch100-byte payloads
3 trialsMedians reported
01 / EXPLORE THE RESULTSSame workload.
Same workload.
See the difference.
All recorded metrics
↑ Higher is better ↓ Lower is betterClient and server share one vCPU over loopback, without TLS or compression. The host also serves a website. These measurements are not guarantees for other hardware.
02 / THE HONEST PARTWhere KuttiDB
Where KuttiDB
doesn't win.
Keeping the slower results visible is part
of making the faster results useful.
~1,414KuttiDB / messages per sec
~1,651RabbitMQ / messages per sec
At one durable message at a time, KuttiDB does not lead. The storage barrier becomes the limiting factor.
03 / READ THE CONDITIONSContext is part
Context is part
of the result.
One workload per engine. Single-node comparisons. Maintained client libraries. The configurations matter as much as the rates.
Reproduce the measurements ↗Cache: a one-second durability window
200,000 keys and 100-byte values, in batches of 256. KuttiDB uses put_many/get_many with --fsync-ms 1000. Redis 8.0.5 uses MSET/MGET with appendfsync everysec. These are periodic-durability cache results, not fsync-confirmed results for every write.
Queues: replies covered by a durability barrier
100,000 messages, batches of 256, one durable queue. Publish, drain, acknowledge, and verify payloads and the exact count. KuttiDB groups records under a barrier; NATS and RabbitMQ do not group-commit at these settings. This affects the published throughput gap.
Streams: eight partitions, explicit commits
100,000 records, 100-byte payloads, eight partitions, batches of 256. Read from offset zero and commit the group offset after each batch. KuttiDB appends wait for fsync coverage; Redis Streams uses appendfsync always; Kafka 4.1.2 uses acks=all and log.flush.interval.messages=1.
What these comparisons don't cover
No replication, clustering, multi-consumer fan-out or rebalancing under load, compaction, retention under write load, or crash consistency under power loss. RSS excludes the kernel page cache, so it measures process footprint, not total machine memory.
Kafka and RabbitMQ usually serve workloads and deployment topologies beyond this single-node comparison; their numbers here describe one fsync-per-record node each, not their usual distributed modes.
Keep the evidence with the result.
Download tables ↓These tables reproduce the current cross-server comparisons from the repository's benchmark report, including every recorded metric and the cases where KuttiDB loses. Older withdrawn scorecards are excluded.