P99 CONF is a virtual conference on high-performance, low-latency applications. Its 2026 event ran October 21–22. Here, we cover five of its 60-plus sessions. The recordings are available on demand at p99conf.io after registration.

Database storage design balances read amplification, write amplification, and space amplification (RUM conjecture). Improving one can increase another, depending on the workload and configuration. The five talks below show how engineers make those trade-offs across different database systems.

Gavra frames database design around read amplification (data read per result), write amplification (data written per logical write), and space amplification (storage used relative to live data). A log favors fast writes but makes reads work harder; a sorted array does the reverse. As Gavra put it, “I think about LSM trees as a mechanism for tuning between these two extremes.”

LSMs were built for local disks, but their immutable files also fit object storage. Gavra points to Amazon S3’s lower storage cost, durability, and availability, then names the trade-offs: objects must be replaced rather than edited, each GET and PUT has a price, and cold reads are slower. In his example, a local NVMe cache miss takes about 150 microseconds, versus 20–30 milliseconds for S3 Standard — roughly two orders of magnitude. LSMs batch writes into immutable files; caching helps keep object-store reads off the hot path.

Gavra’s SlateDB is an open-source, object-store-native LSM library. It exposes a key-value interface over stores such as S3, GCS, and R2, so developers can build data systems without implementing their own LSM.

Source link