Willison compresses 20MB of revision history to 80KB

Simon Willison compressed 20.4 MB of document revision history into an 80.3 KB SQLite BLOB, per a prototype he posted August 9.

That's a storage problem most apps punt on, since keeping every draft of every document usually means pruning history or shipping it off to cheaper cold storage. Willison's numbers suggest you might not have to.

The trick is redundancy. His prototype stores each document's full revision history as a Zstandard-compressed JSON array of every prior version, with timestamps kept in a separate column. Since consecutive revisions of the same document are almost identical, the compressor has almost nothing new to encode after the first version. Testing against 1,000 simulated revisions, Willison hit roughly 250:1 compression. To keep any single row from growing unbounded, he chunks the history across rows, capping each chunk at 128 revisions or 3MB uncompressed.

Yes, but: this is a synthetic benchmark on simulated revisions, not a production document set with images, formatting churn, or merge conflicts, so real-world ratios will vary.

What's easy to miss is who wrote the code. Willison didn't write the prototype by hand, he described it out loud and GPT-5.6 Sol Pro produced it. That's the same pattern as a second workflow described the same day: talk through the design, get working code back.

The compression trick is a nice hack. The bigger tell is that a working SQLite schema with chunking logic and a bounded row size came out of a spoken description on the first pass, with no revision loop mentioned. If that holds up outside toy benchmarks, the bottleneck for small utilities like this stops being typing speed.