In early October 2026 I wrote two LinkedIn diary‑style posts about how large values are stored in key‑value systems. I explored the trade‑offs of inline storage versus separating large values into a dedicated value‑log, and I backed the discussion with benchmark numbers from TidesDB and analogies to PostgreSQL TOAST and MySQL InnoDB.
well‑engineered B‑Trees can efficiently handleboth in‑memory and out‑of‑memory workloads.
Most LSM engines store keys and values side by side, which makes large values a write amplification problem.
The core idea is simple: any value at or above a threshold goes into the value log at commit, and the key log stores a small ID in its place.
In a TidesDB benchmark loading 250K keys with 4 KB values and overwriting them once, separated writes ran almost 3x faster than inline writes.
while the inline configuration with 64 KB nodes still rewrote 5.1 GB.
Separated configuration rewrote 0 GB of values during compaction.
PostgreSQL can store large TEXT values out of line using TOAST when they no longer fit comfortably in a row.
MySQL with InnoDB also takes a similar approach.