← All posts
Benchmarks & Comparisons

Holt 0.7.0: a historical metadata-engine design note

Eric (Guocheng) Song NoKV team

Editor’s note (2026-08-21). This article is now a qualitative, historical design note for Holt 0.7.0. The original page quoted engine timings for which the repository does not contain matching raw telemetry, so those numbers have been removed. The pinned benches/RESULTS.md identifies its published tables as older v0.3.0 Linux and v0.3.1 macOS snapshots; they must not be relabeled as v0.7.0 results. This page is not a current NoKV product benchmark, a performance promise, or release qualification. Use the current NoKV benchmark evidence levels for product claims.

The workload Holt was designed around

Holt is an embedded Rust metadata engine built around a persistent Adaptive Radix Tree. Its narrow design target is path-shaped keys: object names, artifact paths, tenant namespaces, and other metadata in which point lookup and prefix listing are common.

That shape differs from random opaque-key workloads. Many metadata questions begin with a shared prefix and need either the records beneath it or a delimiter rollup at the next path component. Holt keeps that hierarchy in the index instead of requiring every caller to reconstruct it from a generic range scan.

The design in the pinned source

The fixed Holt 0.7.0 source snapshot documents four mechanisms that matter to this metadata shape:

  • Persistent Adaptive Radix Tree. Path compression and byte-wise routing preserve shared prefixes while supporting point lookups and ordered traversal.
  • Metadata-native scans. Prefix ranges, pagination through start_after, key-only scans, and delimiter rollup are engine operations rather than application conventions.
  • Conditional mutation. Version-aware put and delete operations, rename, and small atomic batches give a metadata caller explicit conflict boundaries.
  • Recovery machinery. A logical write-ahead log, group commit, checkpoints, manifest replay, and reopen recovery separate acknowledged mutation from later data-file consolidation.

These are source-level capabilities, not an end-to-end performance result. Hardware, durability mode, cache state, dataset shape, process topology, and the surrounding NoKV path all affect observed latency and throughput.

Holt’s bounded role inside NoKV

Holt is one local TxnStore adapter behind NoKV’s metadata contract. The current NoKV request path also includes root placement, logical-shard routing, owner epochs, fencing, protocol handling, object publication, and product-level recovery rules. An embedded-engine experiment does not measure those layers.

That boundary matters in both directions:

  • Holt can optimize local path-aware metadata operations without becoming the NoKV product API or the authority for distributed placement.
  • NoKV can qualify routing, publication, recovery, and multi-machine behavior without pretending that a local engine benchmark proves the full system.

Holt is also intentionally not a universal storage engine. Random opaque keys, large-value streaming, analytics, full-text search, and vector search belong to systems designed for those workloads.

Evidence boundary

The durable references for this historical note are:

No number from that benchmark document is promoted here as a current Holt or NoKV claim. Any future quantitative article should bind the quoted result to immutable raw telemetry, the exact harness and source revision, the test environment, and a declared evidence level.