When to pick Kafka
Millions of messages per second with millisecond latency, transactions/exactly-once, Kafka Connect and Schema Registry, built-in HA replication — and a team ready to run all of it.
Kafka is the de facto standard, and Roxa does not pretend to be “Kafka but better at everything”. The difference is the storage architecture and the cost of ownership. The protocol is shared: your applications work with both without a rewrite.
| Roxa | Apache Kafka | |
|---|---|---|
| Data storage | S3/MinIO or local FS (diskless) | Broker disks + ×3 replication |
| Loss on node failure | None — data is already in storage | Possible before replication completes |
| Runtime | Rust, a single binary | JVM + ZooKeeper or a KRaft quorum |
| Deployment | One container / docker compose | A cluster: brokers + coordination |
| Operations | Minimal: no quorums, no disk rebalancing | A dedicated engineer: JVM/GC tuning, disks, partitions |
| Clients | The same Kafka clients (librdkafka etc.) | All Kafka clients |
| Web console | Built in | Third-party UIs, separately |
| Price | Community free; Pro — a perpetual license | Free + the cost of operations |
The key difference: Kafka keeps data on broker disks and protects it with replication — you pay for that with a cluster and an operations team. Roxa puts data into object storage and acknowledges a write only after it is committed — the node becomes disposable, and operations boil down to “restart the container”.
Millions of messages per second with millisecond latency, transactions/exactly-once, Kafka Connect and Schema Registry, built-in HA replication — and a team ready to run all of it.
Reliable messaging between services without maintaining a cluster: one container, data in your S3, the same clients. The typical case is a team that needs 10% of Kafka but has to operate 100% of it.