20,4 MB revisjonstekst ble til 80,3 kB i én SQLite-kolonne

20,4 MB rå revisjonstekst ble til 80,3 kB. Det er resultatet Simon Willison fikk da han testet en idé han fikk på hundetur: i stedet for én databaserad per tidligere versjon av et dokument, legg alle versjonene i en JSON-array av strenger og komprimer hele arrayet med zlib eller Zstandard.

Problemet med den vanlige løsningen er at hver redigering av et dokument på 20 kB legger nye 20 kB i basen. Siden versjonene er nesten like, spiser en komprimeringsalgoritme opp gjentakelsene. Skjemaet består av to kolonner: en BLOB med det komprimerte arrayet av tidligere tekster, og en ukomprimert JSON-array med Unix-tidsstempler, som ikke har noe å hente på komprimering.

Willison beskrev ideen muntlig i talemodus i ChatGPT-appen, limte transkripsjonen inn som prompt til GPT-5.6 Sol Pro og ba den bygge eksperimentelle prototyper i Python. Modellen jobbet i 38 minutter. Den pekte samtidig på den åpenbare svakheten: hver redigering krever at hele arrayet pakkes ut og pakkes inn igjen. Løsningen den foreslo, var å dele historikken over flere rader, med maks 128 revisjoner eller 3 MB ukomprimert JSON per rad.

For deg som lagrer redigerbar tekst i SQLite, er dette et alternativ til å dra inn et diff-bibliotek. Du bytter presisjon mot enkelhet: du kan ikke spørre på en enkelt gammel versjon uten å dekomprimere, men du slipper å vedlikeholde en patch-kjede som må spilles av for å rekonstruere teksten slik den så ut.

Hva bør du gjøre?

1. Mål på dine egne data før du velger: gevinsten kommer av at versjonene ligner hverandre, og et dokument som skrives om fra bunnen hver gang komprimerer dårlig.
2. Sett et tak per rad, for eksempel 128 revisjoner eller 3 MB ukomprimert, hvis dokumentene dine skrives ofte.