--- title: "HeliosDB Full v8.0: A Native LSM, RocksDB-Free" description: "v7.9.0→v8.0.0 retired RocksDB: native LSM, custom WAL, content-addressed CAS. Editor's note: the current Full listeners and their status are on full.html, and branching and time travel for Full are planned." date: 2026-05-19 updated: 2026-10-14 tag: "Architecture" canonical: https://www.heliosdb.com/blog/full-8-0-native-lsm-14-protocols.html --- # HeliosDB Full v8.0: A Native LSM, RocksDB-Free **Editor's note — October 2026.** HeliosDB Full serves the PostgreSQL, MySQL, Oracle and Redis wire protocols plus an HTTP gateway, not the 14 protocols this post first listed; MongoDB, Cassandra and SQL Server are Planned in the [status summary of the Release and Capability Matrix](https://www.heliosdb.com/release-capability-matrix.html#annex-a-status-summary-on-the-effective-date-of-this-version), which states the best result on any version. Nano and Lite run time-travel queries (`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](https://www.heliosdb.com/release-capability-matrix.html#annex-a-status-summary-on-the-effective-date-of-this-version). ## 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 [HeliosDB sales](https://www.heliosdb.com/contact.html?subject=sales).