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.1.5. Published OMB results, with source files and test conditions. Try krabka in your browser

Latest full OMB run · krabka 1.1.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. 0 omitted trial across the full suite.

131%of Kafka’s throughputMedian; workload range 99% to 755%
2.01×Kafka’s CPU efficiency indexHigher in 14 of 14 pairs

Throughput = the lower of a workload’s publish and consume rates, so a consumer that falls behind does not raise it. CPU efficiency index = throughput ÷ 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

Compare the replicated 1 KiB workloads with the full max-rate set. 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×
1.1.4Trimmed SSD105%131%1.99×
1.1.5Trimmed SSD104%131%2.01×

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

Direct I/O: median 153% of Redpanda’s throughput on max-rate workloads

A separate full OMB run used Krabka 1.1.5 with preallocate=true, so Krabka wrote its segments with O_DIRECT, as Redpanda does. Redpanda ran as Redpanda 26.2.2.

14 max-rate workload / replication-factor pairs; workload range 116% to 748%. One measured round per workload.

Throughput is the lower of each workload’s publish and consume rates. It does not show tail latency. The benchmarks page lists end-to-end p99 for each workload.

Compare Krabka's direct I/O results with Redpanda
Krabka relative to Redpanda in the direct I/O run
Replication factorMedian throughput
RF1151%7 max-rate workloads
RF3156%7 max-rate workloads

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

Use your existing Kafka clients

Trying your clients takes one line. Moving a production cluster takes more: read what changes when you migrate a cluster.

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!"
)).get();

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.

  • 259

    kernel functions proved

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

  • 12M

    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