Skip to main content

Open-source streaming · Apache 2.0

Keep your Kafka clients. Measure a different broker.

krabka implements supported Kafka APIs in safe Rust, with its own KRaft quorum. Inspect its throughput, tail latency and CPU use before you decide where it fits.

Get started Explore the measurements

Latest measured release: 1.0.5. Published OMB results, with source files and test conditions. Try krabka in your browser

Latest full OMB run · krabka 1.0.5

What the measurements show

Read the source results

Shared page cache

krabka and Kafka use the Linux page cache in this suite. Compare all max-rate workloads, then inspect the differences.

14 workload / replication-factor pairs. 1 measured round per workload. 1 omitted trial across the full suite.

103%of Kafka’s publish rateMedian; workload range 53% to 165%
1.17×Kafka’s CPU efficiency indexHigher in 10 of 14 pairs

CPU efficiency index = publish rate ÷ total broker CPU time, relative to Kafka. CPU capture includes startup, warm-up and shutdown. This is a proxy, not CPU cost per delivered message.

Across published releases

See where the gap changed

The replicated 1 KiB workloads improved relative to Kafka across these runs. Check the full set alongside this group.

Disk preparation can change between runs; each row records SSD trim. These results do not isolate the effect of code changes.

krabka relative to Kafka in the same run
Version1 KiB, RF3All max-rateCPU index
1.0.1Uncontrolled trim75%98%1.24×
1.0.3Uncontrolled trim97%99%1.12×
1.0.5Trimmed SSD103%103%1.17×

100% = Kafka’s rate. 1× = Kafka’s CPU index. Values are medians of workload ratios, not pooled throughput.

Direct I/O: within 3% of Redpanda’s rate in 2 reported rounds

This separate experiment used main with #1373 and #1376 with preallocate=true, against Redpanda 26.2.2.

One RF1, 16-partition, 1 KiB max-rate workload. Trials ran interleaved after SSD trim on ext4 and mirrored NVMe drives. Figures are rounded in the source.

Redpanda had lower tail latency and disk utilization. CPU efficiency was not established for this experiment.

Read the direct I/O investigation
Reported rounds, not a full release qualification
RoundkrabkaRedpanda
1931k/s81 ms E2E p99926k/s53 ms E2E p99
2818k/s95 ms E2E p99838k/s75 ms E2E p99

Results apply to this host and these workloads. Similar throughput does not establish equal latency or crash durability.

Just change one line: the broker address

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");

Producer<String, String> producer = new KafkaProducer<>(props);
producer.send(new ProducerRecord<>("quickstart-events", "user-1", "Hello Krabka from Java!"));

Each example runs against krabka nightly in CI.

Run the complete examples

Memory-safe, proved, and model-checked

  • forbid(unsafe_code)

    the lint every workspace crate builds under

    No unsafe Rust. The compiler enforces it across the workspace.

  • 258

    kernel functions proved

    Creusot proofs. Vote admission, quorum size, ISR and leader failover, and other decision kernels are proved against their contracts.

  • 8.2M

    states checked across 31 models

    Stateright models. Consensus, failover, transactions, and group coordination are checked for every reachable state within each model’s bounds.

Read how krabka is verified