Public beta · 0.1.0-beta.5

Performance

Two fully specified write runs on a three-node cluster, published with their method, their hardware and the parts they do not cover. Each is one observed run. These numbers are evidence about this configuration, not a performance guarantee for yours.

What bounds Nexir

Read these numbers against the shape of the system, or they will mislead you.

Writes are bounded by the leader. Every acknowledged write is a Raft round trip: the leader appends the entry, a majority of nodes make it durable, and only then does Nexir answer OK. That path runs on one node, so write throughput is set by the leader's CPU, its disk and the round trip to its followers. Adding voters does not raise it — it raises the durability bar the same write has to clear.

Reads are bounded by the node serving them. Reads are linearizable by default, which costs a round trip to confirm the leader is still the leader before the value is returned. Nexir keeps one replicated dataset rather than sharding, so read throughput scales with the hardware under a node, not with the number of nodes.

Throughput and latency trade against each other. Offering more concurrency raises requests per second and raises the latency of each one. A single figure from either end of that curve describes a choice, not a capability, which is why the concurrency is stated beside every number below.

What was measured

Both runs used the same cluster shape and settings. The only difference was the number of writes.

Results

Every SET is acknowledged only after it is durable on a majority of nodes. Latency is measured by the client and includes TLS and the network.

Measured on 18 and 19 October 2026 on two freshly provisioned clusters, one redis-benchmark run each, from the tool's own CSV output. Server binary sha256 05987403…41fef. The always-on replica catch-up and the snapshot retry behaviour in 0.1.0-beta.5 were added after these runs and were not in the measured binary.

Memory, disk and data

Memory is the highest of the per-node samples taken every five seconds during the load. Disk figures are single samples taken as each load ended; disk use moves by a gigabyte or more within seconds while background compaction finishes, so read them as points, not as stable values. Disk is in decimal gigabytes.

The second billion writes were almost all overwrites of keys that already existed. Disk usage did not grow in proportion to them: the stored database grew from about 16.8 GB at one billion writes to 17.6–18.3 GB at two billion, while the number of live keys grew by 3.3%.

After each run, all three servers were stopped and restarted, and every one of the 300 million possible keys was read back. After the 1-billion run, 290,185,884 keys held the expected value and 9,814,116 never-written keys were correctly absent; after the 2-billion run, 299,638,589 and 361,411. There were no missing, wrong or unexpected keys and no errors. These checks include a short additional burst of writes made after the main load.

What this measurement does not tell you

Said here rather than left for someone to find out after they have sized a deployment on it.

• Each figure is one run. One run per workload, one value size, one connection count, one pipeline depth. It is an observation, not a universal throughput promise or a statistically established result.
• It is a single availability zone. All three voters shared one zone, so the round trip between them is best case and the cluster had no zone fault tolerance. A cluster spread across zones will commit more slowly.
• Every connection hit one node. The leader terminated all 400 connections and the followers none, so any asymmetry between them is the load pattern, not Raft.
• The values compress very well. Every key held the same 256-byte value. Real data with varied values will use more disk and may write more slowly.
• Writes only. No read latency is reported. The rate at which keys were read back after the restart was a verification step, not a read benchmark.
• Not a capacity statement. Each node held about 18 GB of stored data on a disk of about 474 GB. Nothing here validates a much larger dataset per node, and the total bytes written are not a measure of capacity.
• The restart check is not a crash test. It validates the final value of every key after an orderly restart. It says nothing about intermediate values that were overwritten, or about a crash or power loss at an arbitrary moment.
• It is beta software. Defaults, the storage format and the code all move between releases, and the measured build predates the last changes in 0.1.0-beta.5, as noted under the results.

The constraints that apply to Nexir generally, rather than to this measurement, are in the public-beta limitations.

Measure it yourself

Cluster latency and throughput are sensitive to small differences in hardware, placement and kernel, so a number measured on your own machines is worth more than this page. Against a running cluster, with redis-benchmark from a separate host:

redis-benchmark -h NODE_HOST -p 6379 \
  -t set -d 256 -r 300000000 \
  -n 1000000000 -c 400 -P 1 -q --csv

Add the TLS arguments your deployment requires; see secure deployment. Point the tool at the leader rather than round-robin, so you know which node produced the number. At these rates a billion writes takes about five and a half hours.