Release notes

Current release · 26 October 2026

0.1.0-beta.5

Beta.5 focuses on steady operation under large, sustained workloads.

What beta.5 improves

• More predictable memory use. Nodes plan memory at startup and apply clear backpressure when pressure rises.
• Lower disk growth for overwrite-heavy workloads. Old values are reclaimed during normal storage maintenance. In the measured one-billion-write run, disk use was about 70% lower than on the earlier build; a second billion overwrites added little.
• Stronger follower recovery. A bounded history window helps lagging replicas resume by replay, while snapshot builds that cannot safely fit before starting wait and retry.
• Security and packaging updates. The TLS, runtime and compression dependencies were updated, and release packages include the required native-library notices.

Measured on three NVMe nodes

On three AWS c6id.2xlarge servers with local NVMe and full TLS, one observed run completed 1 billion writes at 51,551 per second (p99 16.90 ms), and another completed 2 billion at 52,193 per second (p99 18.00 ms). Both used a 300 million-key range, and every possible key was checked after a full restart. These are workload-specific observations, not performance guarantees; the performance page gives the full setup.

What to know

Nexir remains beta software. Memory settings are targets rather than a hard ceiling, follower recovery time is not guaranteed, and large per-node capacities have not been validated. Although beta.5 changes no storage-format marker, an in-place beta.4 upgrade was not validated; a fresh cluster remains the conservative path. See the limitations page.

Downloads

Each archive has an immutable same-name .sha256 sidecar under https://releases.nexir.com/v0.1.0-beta.5/. See the release file layout and the download page.

Previous release · 20 September 2026

0.1.0-beta.4

A proof release. Beta.4 adds little surface on purpose; its work was to make the behaviour Nexir already had correct under stress and demonstrated at scale — a node rejoining after falling far behind, garbage collection keeping up with a large backlog, the storage engine staying out of write stalls, the cluster holding its leader under load with TLS on — and to say precisely what remains open. The storage layout changes from 9 to 10 in this release: a beta.3 data directory is refused at startup by name, and there is no migration — beta.4 is a fresh cluster, with data preserved and reloaded at the application level. Beta data should be replaceable; this is the case the warning exists for.

What this release established

• Rejoining at scale. A node that had missed more history than the cluster still held rejoined by snapshot transfer at 7.5, 25 and 73 GiB — one attempt each, no leadership change, no discarded work. The 73 GiB rejoin took about an hour on the measured hardware, which makes recovery time, not disk, the practical limit on dataset size today; shortening it is the next release's focus.
• Stability under load with TLS. With mutual TLS on both the client and the cluster listener, a load run held its leader throughout: no leadership change, no cluster-down replies.
• Garbage collection proven. The collector that reclaims overwritten versions was reviewed against its design and drained a backlog of 31 million items to zero while the cluster kept serving, removing exactly one stored version per item.
• Storage defaults measured. The storage engine's compaction settings are now configurable and were chosen from a matched comparison; on the measured hardware they produced higher throughput, lower tail latency and no write stall.

What changed for operators

• Rejoins can no longer livelock. A long snapshot transfer used to let the receiving node start an election and throw its own transfer away. Elections are now held off for the duration of a transfer, every transfer has a total deadline proportional to its size, and the node reserves disk for it before accepting a byte.
• A failed transfer leaves the node intact. Incoming snapshots are validated and prepared before the cluster accepts them, so a rejected or interrupted transfer never touches the node's existing data.
• Better visibility. New metrics for the true on-disk footprint of both databases (including the replication log, which had none), per-family compaction pressure, snapshot transfer bytes and timeouts, and discarded installs; three gauges that had silently reported zero on populated nodes now report real values.
• Counters. INCR, DECR, INCRBY and DECRBY join the command set.
• Snapshots are directories, not archives. A node's durable snapshot is now a checkpoint directory that shares files with the live database, so keeping one costs a fraction of what a tar copy did, and a transfer is packaged only while it is being sent. This is the storage-layout change above.
• Documentation rewritten for beta.4, including a getting-started guide, the full cluster-administration and command-line reference, an operating model with the metrics and client errors that matter, and majority-loss recovery.

Fixed

• A leader could crash when a follower installed a snapshot newer than the one the leader had selected; fixed in the consensus library Nexir ships.
• Security updates to the TLS stack (rustls, webpki); dependency advisories are clean.

Deferred, deliberately

A disk-capacity governor that stops accepting writes when a disk fills, shorter rejoin times at large sizes, key iteration (SCAN), version-conditioned writes, token-based authentication and backup/export tooling were planned and not in this release.

Artifacts

Binaries for 0.1.0-beta.4 remain published and immutable at https://releases.nexir.com/v0.1.0-beta.4/, each with a same-name .sha256 sidecar; container ghcr.io/nexirdb/nexir:v0.1.0-beta.4.

Previous release · 11 August 2026

0.1.0-beta.3

A consolidation release that made Nexir's background work predictable and its client handling exact.

• Garbage collection that scales with work, not with data. Reclaiming overwritten versions now costs in proportion to how much has been overwritten, not to how many keys exist. Cold start no longer scans every row; a resumable, low-priority deep validation is available on demand instead.
• Exact resource accounting for clients. Buffer and response budgets are charged and released precisely, a slow client can no longer hold budget that others need, and large responses are written in bounded slices so one stalled reader cannot block the rest.
• Tighter Redis client compatibility. The command table is generated from the real registry so client libraries initialise correctly; protocol negotiation and pipelining semantics are documented precisely, including the one deliberate deviation from Redis ordering.

Binaries for 0.1.0-beta.3 remain published and immutable at https://releases.nexir.com/v0.1.0-beta.3/; container ghcr.io/nexirdb/nexir:v0.1.0-beta.3.

Previous release · 12 July 2026

0.1.0-beta.2

The first public beta: a Raft-replicated key/value server with Redis-compatible access, durable local storage with MVCC versioning, leader-driven expiry, snapshot-based catch-up with integrity verification, admission controls on the client and cluster paths, Prometheus metrics, and fail-fast configuration validation.

Binaries for 0.1.0-beta.2 remain published and immutable at https://releases.nexir.com/v0.1.0-beta.2/.