What you would want to see before trusting it.

Three brokers in one region, a bucket, and a client that can retry. The rest of this page is the list of things that are still sharp edges.

Three brokers

Metadata commits through a majority, and a wal produce acknowledges after a majority of its shard has fsynced. One process can die and the remaining majority still commits. That is the same shape as the three-broker profile and the cluster test. A single broker has nothing to fail over to.

One region

Raft election waits 400–800 ms (wal, metadata). Brokers belong in one region, where a round trip is a small part of that window. Two regions means two clusters and a copy between them. MirrorMaker 2 is tested from Apache Kafka 4.4.0 into Camus, with checkpoints and heartbeats (compatibility). Camus as the source is not in that suite yet.

Losing a shard majority

A shard that has lost its majority stays offline. truncate-to-sealed resumes it at the sealed end and drops acknowledged batches that were not sealed. POST /admin/add-wal-voter moves the other voters onto that new shard. Both are in ADR 0008 and wal_majority.rs.

If every broker disk is gone and the bucket remains, camus admin restore-cluster loads the newest metadata snapshot and rebuilds sealed extents from object footers. The metadata leader writes that snapshot every 30 seconds or 10,000 entries. Group offsets can move back by one snapshot interval. Unsealed write-ahead log entries are gone. The bound is ADR 0008.

APIs and deliberate differences

The compatibility doc is the list. Delegation tokens, client quotas, partition reassignment, and share groups are unimplemented. Transactions hide and reveal batches with metadata ranges, and Camus does not write control-batch markers. acks=1 waits for the same barrier as acks=all. The clients page is the short version. Delivery is how to build on what is implemented.

What CI runs

On a pull request, the required job runs cargo fmt --all --check and cargo test --workspace --locked. It does not start MinIO. A separate job starts MinIO and runs the broker tests with CAMUS_MINIO=1. The ecosystem suite (Kafka CLI, Connect, Streams, MirrorMaker 2 from Kafka into Camus) is nightly, not that required job. Tests has the commands.

When not to use Camus

The honest fit is a log with several independent consumers and replay, without a full replica of that log on every broker disk. These are the workloads that want something else.

• A produce that must finish with a p99 under 10 ms on the object-storage path. The measured r2 p99 is 576.16 ms on the Linux OrbStack run and 284.75 ms on the Mac (benchmarks, README). wal on that Linux run is 16.55 ms p99. A budget under 10 ms wants a broker that acknowledges from local disks.
• One cluster stretched across regions. The election window above is 400–800 ms. Run one cluster per region. Copying between them with Camus as the source is not in the ecosystem suite yet.
• A Raft group for every tiny partition. Partitions share a shard log, partition id mod shard count (ADR 0006). With no count at init, the count follows the cores of that process and stops at eight shards per voter. Key into fewer partitions, or raise the shard count inside that cap.
• A task queue that acknowledges one message at a time. A consumer commits an offset, which is a cursor for the group (OffsetCommit). Share groups are not in the API matrix. A job queue such as BullMQ or Restate matches that shape.
• A Kafka deployment whose disk and JVM cost is already acceptable. Camus exists to move the long-term log off broker disks (why). If that cost is fine, the broker you run is the one your operators already know.

How those projects differ on storage and license is on the comparison page.