TurtleKV: Adaptive Storage Architecture

• TurtleKV is a key/value store architecture that addresses the RUM trilemma by dynamically balancing memory, write throughput, and read performance via its unbiased TurtleTree and adaptive checkpoint distance (χ).
• The TurtleTree structure extends traditional B-tree designs by incorporating out-of-line update buffers, ensuring balanced I/O costs and reduced write amplification without reorganization during retuning.
• Empirical benchmarks demonstrate TurtleKV achieving up to 8× the write throughput and 5× the read throughput of RocksDB, while also outperforming SplinterDB on point queries and range scans.

TurtleKV is a key/value store architecture designed to address the fundamental read–update–memory (RUM) trilemma in large-scale storage systems. It enables dynamic, online rebalancing among memory usage, write throughput, and read performance through the combination of an unbiased on-disk data structure (“TurtleTree”) and a single adaptive memory control parameter (“checkpoint distance” $\chi$). TurtleKV demonstrates up to 8× the write throughput and up to 5× the read throughput of RocksDB under common YCSB workloads, with comparable or lower space amplification, and outperforms SplinterDB on point queries and range scans, while supporting rapid, runtime retuning without data reorganization (Astolfi et al., 12 Sep 2025).

1. Storage Architecture and the RUM Trilemma

The RUM trilemma formalizes the constraint that key/value stores must trade off among main-memory footprint, write performance, and read performance. Traditional storage engines commonly optimize one (or sometimes two) axis by statically tuning on-disk structures and using auxiliary mechanisms to mitigate deficiencies in the remaining dimension. For example, RocksDB favors write efficiency via an LSM-tree and consumes extra RAM for Bloom filters to compensate for reduced read efficiency, whereas B⁺-tree engines optimize reads via aggressive node caching but suffer from higher write amplification imposed by write-ahead logs or delta pages. Hybrid structures like SplinterDB’s STBᵋ-trees statically bias towards write throughput, using quotient filters to incrementally assist read operations.

TurtleKV introduces a notable deviation from this paradigm by employing an unbiased on-disk structure whose I/O operations have balanced costs for reads and writes. Dynamic, transparent memory allocation is achieved through a single control parameter, checkpoint distance ($\chi$), enabling the system to optimally span the RUM space at runtime, responsive to fluctuating workload demands (Astolfi et al., 12 Sep 2025).

2. TurtleTree: The Unbiased On-Disk Structure

Central to TurtleKV’s approach is the TurtleTree, a parameterization of the B^{ε+}-tree. Like B⁺-trees, TurtleTrees deploy interior nodes with pivots and child pointers, but add update buffers analogous to B^{ε}-trees. Unlike previous update-buffered trees, TurtleTree buffers are allocated out-of-line, housed in leaf-sized pages managed as miniature level-tiered LSMs with fanout $F=2$ per node.

Key invariants for the TurtleTree include:

• Buffer Size Invariant: The total in-node buffered bytes across all buffer levels is bounded by $L(\rho-1)$, where $L$ is the leaf page capacity and $\rho$ is the number of pivots.
• Segment Count Invariant: Total segments across levels may not exceed $\rho - 1$.
• Segment Metadata: Each segment maintains (1) a bitset activePivots for key ranges affected, and (2) a sparse array flushedPivots tracking downstream flush progress per pivot.

These design properties guarantee that flush operations never exceed the buffer budget, even in adversarial transaction orderings, thereby bounding worst-case write amplification.

The core algorithms for batch insertion, point lookups, and range scans are specified via high-level pseudocode, with batching and lazy propagation intertwined at every level to avoid forced reorganization upon dynamic retuning of $\chi$ (Astolfi et al., 12 Sep 2025).

3. Memory Tuning via Checkpoint Distance (χ)

TurtleKV unifies memory allocation and I/O cost control around a single parameter, the checkpoint distance ($\chi$), defined as the number of in-memory update batches to be aggregated before merging and flushing to disk. Adjustments to $\chi$ allow live, online tradeoffs between write throughput (mitigating write amplification) and read performance (maximizing page cache availability). Critically, $\chi$0 can be varied without affecting the layout or performance of previously persisted data—eliminating the “residual penalty” seen in systems reliant on structural reorganization.

The safe operating regime for $\chi$1 is:

$\chi$2

where $\chi$3 is total RAM, $\chi$4 is desired cache size, and $\chi$5 is the in-RAM footprint per batch (approximately leaf page size).

A feedback algorithm regularly measures write I/O saturation ($\chi$6) and read latency ($\chi$7). If writes are bottlenecked, $\chi$8 is doubled up to a maximum; if read latency exceeds target, $\chi$9 is halved down to a minimum of 1. When $F=2$0 is changed, the in-flight checkpoint is flushed, and the new configuration takes effect. Retuning via this mechanism occurs within seconds and does not induce major data shuffling or migration (Astolfi et al., 12 Sep 2025).

4. Analytical I/O Cost Model

The amortized I/O costs in TurtleKV are governed by the interaction among $F=2$1 (number of key-value pairs), $F=2$2 (page size), $F=2$3 (leaf-page capacity), and $F=2$4 (checkpoint distance):

• Write cost per update:

$F=2$5

Increasing $F=2$6 reduces the effective write amplification by $F=2$7 as early levels of the TurtleTree are maintained in-memory.

• Point lookup in Disk Access Model (DAM):

$F=2$8

• Point lookup in Parallel DAM (PDAM):

$F=2$9

• Short range scan of length $L(\rho-1)$0:

$L(\rho-1)$1

These results demonstrate that TurtleKV can smoothly interpolate between the operational regimes of LSM-trees and in-place B-trees, while dynamically adjusting to workload requirements (Astolfi et al., 12 Sep 2025).

5. Empirical Performance Evaluation

Comprehensive benchmarking using YCSB on an AMD Threadripper 7970x (32c/64t), 128 GiB DDR5, Intel P4800x Optane SSD, and varying page cache configurations demonstrated TurtleKV’s performance under both write- and read-intensive scenarios:

System	Write Throughput	Read Throughput	Space Amplification
RocksDB	baseline	baseline	~1.2×
SplinterDB	81–147% of peak	–	higher
TurtleKV	up to 8× RocksDB	up to 5× RocksDB<br>up to 40% ↑ SplinterDB (point queries)<br\>2–6× ↑ SplinterDB (range scans)	similar (vs RocksDB)<br\>50% ↓ (vs SplinterDB)

Key results included:

• Writes: Up to 800 K ops/s (compared with RocksDB’s 100 K ops/s on 128 B records), with write amplification dropping from ≈12 to 4 at maximum $L(\rho-1)$2.
• Reads: Up to 5× faster point lookup throughput than RocksDB, 40% faster than SplinterDB under matching memory budgets; 2–6× higher throughput than SplinterDB for range scans of length <100.
• Page cache utilization: In-cache scan throughput exceeded RocksDB by ~2×; under constraint, TurtleKV maintained ~84% of RocksDB’s single-thread scan rate due to a sharded-view cache.
• Retuning cost: Flushing the in-flight checkpoint during $L(\rho-1)$3 changes took under 10 seconds, enabling responsive adaptation to workload shifts.

6. Operational Guidelines and Limitations

For predominantly write-intensive workloads (updates >50%), empirical evidence supports maximizing $L(\rho-1)$4 within available memory, with $L(\rho-1)$5–16 batches saturating SSD bandwidth while minimizing write amplification. For read-dominant phases (reads >90%), reducing $L(\rho-1)$6 to 1–2 maximizes cache allocation and lookup efficiency. Mixed or shifting workloads are managed with an automatic feedback controller, typically requiring only seconds to steer $L(\rho-1)$7 following workload transitions, thereby avoiding extract–transform–load operations or reformatting of on-disk data.

Noted limitations include increased RAM requirements for large $L(\rho-1)$8 during in-flight checkpointing, as well as some degradation in small-record read latency under extreme cache pressure with large (16 MiB) leaf pages. Prospective directions include streaming in-memory buffer compaction, adaptive leaf sizing, and machine-learned tuning of $L(\rho-1)$9 alongside filter bit rates (Astolfi et al., 12 Sep 2025).

7. Significance and Future Prospects

TurtleKV’s integration of a balanced-IO on-disk structure (TurtleTree) and runtime-adaptive memory management (via $L$0) provides a mechanism to relocate the RUM trade-off boundary dynamically. The ability to re-tune core performance characteristics on-demand, without persistent data migration, broadens deployment flexibility and workload adaptability. A plausible implication is the wider applicability of TurtleKV-style techniques (especially unbiased on-disk organization plus online memory retuning) to other classes of write-optimized and hybrid data structures. Further refinements in sub-leaf partitioning, buffer compression, and data-driven autotuning are indicated routes for advancing the state of memory-efficient, high-performance key/value databases (Astolfi et al., 12 Sep 2025).