What lightweight encoding forbids

Which properties can no lightweight encoding give you at once, and what does each escape cost?

Inside a block you cannot have maximum ratio, random access and in-place update at the same time. In practice you cannot have the third at all.

Any encoding where decoding value i depends on other values loses random access.
Any encoding whose size depends on the extremes of the block loses robustness to outliers.
Every encoding here loses updatability, permanently. You cannot change one value inside an RLE run, a bit-packed block or a delta chain without rewriting the whole block. Every mechanism here assumes an append-only base. This is why row-store transaction databases (which update records in place) use almost none of these techniques, and why these encodings arrived historically together with immutable file formats.
Encoding one column at a time cannot see redundancy between columns. Columns are encoded as if they were independent, but city and postcode, currency and country, and timestamp and sequence number are strongly dependent. Correlated-column detection is almost absent from production formats, so this redundancy sits unused in every data warehouse.

The escapes and their prices

Restart points buy back random access at block granularity. They cost ratio and an offset index.
Exception paths buy back robustness to outliers. They cost a second access path and a branch.
Compaction buys back updatability. It costs write amplification and a background cleaner. This time the cleaner is a scheduled job with a budget that somebody argues about every quarter.

Case, resolvedConstructed case · Nikhil at Tradewind

Same data, files three times larger

Tradewind's streaming job wrote Parquet files three times larger than the nightly job's, from the same data with the same codec, and a ten-value status column barely compressed. Where it started: Lightweight compression →

Sofia looks at the two jobs and asks one question: "How are the rows ordered?"

The streaming job writes rows in arrival order: a scan at depot Rotterdam, then Lyon, then Rotterdam, in random mix. In each file, status and depot change on almost every row, so RLE finds runs of length about 1 and dictionary indexes need many bits. The min/max statistics of the files overlap completely.
The nightly job sorts by (depot, event_time). Now depot has about 200 long runs per file (about 200 runs instead of millions), so RLE shrinks it to almost nothing. Within a depot, event_time is increasing, so delta-of-delta turns timestamps into almost-zero values and bit-packing stores them in a few bits. Zone maps skip whole files for a query on one depot. status still has ten values, so a dictionary with a 4-bit code works well. scanner_id is also nearly constant within a depot and event window.
Floats. lat and lon stay large. Sofia checks whether they are decimals in disguise: the scanners report six decimal places, so the values are fixed-point with 10⁶ scaling. An ALP-like codec can store them as integers; a plain XOR codec would not help much.
The fix. Nikhil adds a compaction step that re-sorts each day's small files by (depot, event_time). The sizes become equal, because the streaming job's data is now compacted into the same order. A third benefit: dashboards that filter by depot read far fewer files.

Sofia's rule: "Choose the sort order first, then the encoding. The codec on top matters least."