HeliosDB Full v8.0: A Native LSM, RocksDB-Free
AS OF) and Git-like branches; for HeliosDB Full both are planned (8.3.0 accepts the syntax but does not read historical snapshots or create branches), so the branch and time-travel figures first published here have been removed. HeliosDB Full 8.3.0 runs as a single server; clustering is planned.
v8.0.0 is a milestone release: HeliosDB Full no longer depends on RocksDB. The native LSM tree, custom WAL, content-addressed CAS, and branch-aware GC carry the read and write path end-to-end, under the same wire-protocol listeners. This post covers what changed, why we did it, and what it means for operators.
Why retire RocksDB
RocksDB is excellent. We used it for years. Three things made the dependency increasingly awkward:
- Branch semantics. Git-like branches with copy-on-write at the storage layer want delta SSTables and branch-aware compaction. We were layering branch metadata on top of RocksDB's column families, which works, but the planner and the GC had to round-trip through a foreign abstraction every operation.
- Time-travel reads. MVCC versions on RocksDB go through
seqnum-based snapshots. That's fine for short-lived snapshots; it's awkward for "give me this row as of timestamp T" with T anywhere in the retention window. - Compile times and binary size. RocksDB pulled in C++ build tooling. Removing it shortened clean builds and made the release binary smaller.
The native LSM
v7.9.0 ported the vector module off RocksDB first — the easiest module to migrate, and the one with the loudest performance claim. v8.0.0 finished the job: every storage-touching crate is now on the native LSM. Highlights:
- Direct-I/O WAL with single-write durability. Aligned writes via
O_DIRECT; the redundant secondary fsync the prior architecture used was retired in v7.7.3. - Content-addressed value storage. Large values are deduplicated across rows and branches by content hash. Useful for embedding-heavy workloads where the same vector recurs across many tenants.
- Branch-aware GC. Tombstones and stale versions are reclaimed only when no live branch references them; the GC scheduler consults a branch/MVCC matrix before compacting.
- Speculative filters. When a query repeatedly probes a column with a similar value distribution, the engine maintains a probabilistic filter for the next probe.
Three of these four (content-addressed storage, branch-aware GC, speculative filtering) are documented as defensive publications in the HeliosDB IP register. They are public prior art; we describe them here in the same shape.
The listeners, one storage engine
The wire-protocol listeners — PostgreSQL, MySQL, Oracle, MongoDB, Cassandra, Redis and SQL Server, plus the HTTP gateway — sit above the same query planner and the same storage engine. v8.0 doesn't change that surface; it changes what's underneath. MongoDB, Cassandra and SQL Server are Planned in the status summary of the Release and Capability Matrix.
Performance side-effects
The branch and time-travel figures first published in this section have been removed: branches and time-travel queries for HeliosDB Full are planned (see the editor's note). Dropping the C++ toolchain shortened clean builds.
Operator impact
Storage is on-disk-compatible across the v7.9 → v8.0 cut: the LSM was already shipping in v7.9 with RocksDB sidelined, so the upgrade is zero-touch. The rocksdb Cargo dep is no longer in the dependency tree at all.
What's next
v8.1 (already shipped) hardened the v8.0 implementations for end-user use. v8.2 added the agentic-ops skills repository for Claude Code & Codex. v8.3+ will continue the perf wave: HNSW-on-disk for billion-scale vector search, parallel compaction, async checkpointing.
HeliosDB Full is source-available under SSPL-1.0 and provided to licensed customers through sales@ (show).