[austin-barrington]

Version bump to 0.9.4-beta, with release notes (docs/user-guide/release-notes-0.9.4-beta.md).

One fix, #130: a quiet node could not restart after a few days of uptime. Range deletes from WAL truncation piled up in an unfilled memtable, and replaying them costs time and memory quadratic in their number. n3's shared tenant pool was OOM-killed for 19 hours after 5 days of uptime.

Operator v0.3.3 runs 0.9.4-beta. Clients are unchanged.

[cursor]

PR Summary

Low Risk
This diff is versioning and documentation only; operational risk from the WAL fix applies at deploy/upgrade time (documented in release notes), not from these file changes.

Overview
Release 0.9.4-beta bumps hyperbytedb, hyperbytedb-cli, and hyperbytedb-proxy from 0.9.3-beta (including Cargo.lock) and documents the release for operators and users.

New release-notes-0.9.4-beta.md describes fix #130: low-write nodes could fail restart after long uptime because WAL flush truncation stacked range deletes in an unfilled memtable, making replay time and memory quadratic in delete count (e.g. OOM at 4 GiB after ~5 days). The notes explain the new behavior (targeted point deletes, flush before range deletes pile up) and upgrade caveats—first boot on 0.9.4 may still replay existing range deletes, so quiet long-lived nodes may need extra memory or a restart on the prior version before upgrading.

Operator examples in cluster.md use version: "0.9.4-beta"; mkdocs.yml links the new release notes. Operator v0.3.3 is called out as shipping this version; clients are unchanged per the PR description.

^{Reviewed by Cursor Bugbot for commit 49bea55. Configure here.}

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: 58060de6-6d71-4470-9350-b3638a47635c)