The 2026 P99 CONF highlighted four engineering approaches that change how databases handle read, write, and space amplification. Each approach targets a different bottleneck—disk I/O, memory indexing, single‑threaded command execution, or bandwidth‑limited vector retrieval—offering new latency and throughput characteristics that directly affect AI, cloud, and DevOps workloads.
Object‑Store‑Native LSM with SlateDB
Almog Gavra framed database design around the RUM conjecture (read, write, space amplification). Traditional LSM trees favor write speed at the cost of read work, while sorted arrays do the opposite. Gavra demonstrated that immutable LSM files map well onto object storage such as Amazon S3, which provides lower storage cost and high durability. The trade‑offs are explicit: objects must be replaced rather than edited, each GET/PUT incurs a charge, and cold reads are slower (local NVMe cache miss ~150 µs vs. S3 Standard 20‑30 ms). SlateDB, an open‑source library, exposes a key‑value API over S3, GCS, and R2, allowing developers to build systems without implementing their own LSM logic. Implication: Deployments can offload long‑term storage to cheap object stores, but must provision sufficient cache to keep hot reads off the object‑store path and account for higher per‑operation costs.
ScyllaDB Logstor: RAM‑Indexed Log‑Based Reads
ScyllaDB introduced Logstor as an opt‑in engine for read‑intensive workloads. An in‑memory index stores a hash and flash location for each key, enabling a single disk I/O to satisfy a read and bypassing the LSM search stack (SSTables, Bloom filters, etc.). Preliminary benchmarks reported 1.1 M reads / s with p99.9 latency under 1 ms for 2 KB values, and similar performance in an 80 % read / 20 % write mix. The design trades space for speed: a larger RAM index and full‑value writes increase write amplification and dead space, reclaimed later by compaction. Mendes described the trade‑off as “optimized for time at the sacrifice of space.” Implication: Suitable for bounded key sets with frequent overwrites, but operators must monitor RAM consumption and plan for compaction cycles to avoid uncontrolled storage growth.
Valkey’s Lockless I/O Threads and Atomic Slot Migration
Madelyn Olson identified a vertical scaling wall where Valkey’s single execution thread became the bottleneck despite idle I/O threads. By moving network I/O and command parsing to lockless queues on auxiliary threads, the system lifted the ceiling to ~1.2 M requests / s (an eight‑fold increase) for an unpipelined GET benchmark. Horizontal scaling was enhanced in Valkey 9.0 with atomic slot migration: the source shard streams a snapshot and incremental changes to a target shard, then transfers ownership once the target catches up. A 40 GB, three‑to‑four‑shard test completed roughly ten times faster without load and five times faster under heavy GET traffic. Migration can be aborted without data loss if it fails before handoff. Olson’s guiding principle—“Efficiency trumps headline numbers”—suggests using horizontal scaling for baseline capacity and vertical scaling for short bursts while keeping command execution single‑threaded. Implication: Operators can improve throughput by enabling I/O threads and leveraging atomic migration, but must retain single‑threaded command execution semantics and monitor migration health to avoid split‑brain scenarios.
Quantized Vector Search on Object Storage (turbopuffer)
Nathan VanBenschoten described a 100 billion‑vector index (>200 TiB) that achieves 200 ms p99 latency at >1 k QPS with 92 % recall. The system stores the durable backing data in object storage but pins active data in local SSD caches. Hierarchical clustering groups vectors, and RaBitQ binary quantization reduces a shadow index to one bit per dimension, allowing a coarse candidate set to be filtered before reranking with full‑precision vectors. Uncompressed search was bandwidth‑limited; quantization shifts work to higher‑cache tiers and increases arithmetic intensity, making the workload CPU‑bound. Implication: Practitioners must balance cache sizing, quantization level, and CPU capacity to avoid new bottlenecks when optimizing for latency.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
Each talk underscores a common theme: alleviating one amplification factor inevitably stresses another. When adopting an object‑store‑native LSM, provision aggressive caching and monitor GET/PUT costs. For Logstor, size the RAM index for the expected key set and schedule compaction to control space waste. Enable Valkey’s lockless I/O threads and test atomic slot migration in staging before production roll‑out, keeping an eye on migration state. In vector search, experiment with quantization granularity and cache allocation to keep the pipeline CPU‑bound rather than I/O‑bound. Overall, evaluate the memory‑vs‑storage trade‑offs, instrument latency at the p99 level, and design operational processes (compaction, migration abort handling, cache warm‑up) that align with the chosen trade‑off.
