What maintenance forbids
What the layer forbids
You cannot have, at once, cheap small writes, read-optimal file sizes, immediate freshness, and no background compute. Pick three.
You cannot delete a row in bounded time from an immutable store without rewriting everything stored next to it, unless you arranged a key for it in advance.
You cannot keep deep history and compact aggressively without paying storage for both.
You cannot safely reclaim files without either coordinating with readers or bounding their lifetime.
And you cannot make maintenance free. You can only move it.Escapes and their prices
| Escape | Buys | Pays |
|---|---|---|
| Merge-on-read (delete vectors) | cheap writes, cheap deletes | every reader, until compaction settles it |
| Copy-on-write | clean reads, no merge cost | write amplification proportional to file size |
| Auto-compaction | consistent read performance | background compute, conflicts with writers, inflates history storage |
| Time-window GC | no reader coordination | queries longer than the window fail mid-scan |
| Spec evolution in metadata | free repartitioning going forward | heterogeneous planning; old data stays in the old layout |
| Crypto-shredding | O(1) deletion | key granularity fixed at design time, forever |