Willison prova a comprimere la storia dei testi in SQLite

Il 9 agosto 2026 Simon Willison ha pubblicato un prototipo: salvare tutte le versioni di un testo in SQLite come un grande array JSON di stringhe e comprimere l’intero blob con zlib o zstd¹.

L’idea nasce da un problema noto a chi tiene storie di revisione in database relazionali. Willison lo dice chiaramente: è difficile farlo in modo efficiente. Il caso “più facile”, racconta, salva una riga per ogni copia precedente del valore. Se il documento pesa 20 kilobyte, ogni modifica aggiunge altri 20 kilobyte al database. Ogni edit replica tutto il contenuto precedente, con il costo che ne consegue¹.

La proposta è semplice: prendere il testo completo di ogni versione, metterlo in un array JSON di sole stringhe e comprimere l’intero array. L’assunto è che le ripetizioni tra versioni—stringhe che si ripresentano di edit in edit—favoriscano una compressione efficace. Willison cita zlib e zstd come opzioni da applicare al blob risultante, con l’aspettativa che “funzioni davvero bene” su dati con molta ridondanza¹.

Il contesto è SQLite. Willison parla di “una colonna” del database che ospita il contenuto costantemente modificato, e della raccolta delle versioni precedenti in quell’array JSON. La compressione avviene sull’insieme, non su singole parti separate, proprio per sfruttare al massimo le ripetizioni tra versioni complete del testo¹.

Willison spiega come gli è venuta l’idea: durante una passeggiata con il cane ha pensato al prototipo. Poi lo ha discusso usando la modalità vocale GPT‑Live nell’app iPhone di ChatGPT. Sottolinea che non si possono ancora condividere URL di conversazioni vocali. Per questo nel post include ciò che ha detto, copiato dalla trascrizione, “come un vero flusso di coscienza”¹.

Dal frammento trascritto emergono punti concreti. “Ho un’idea interessante per uno schema per salvare tutte le versioni precedenti di un testo che è costantemente modificato in una colonna di un database SQLite nel modo più efficiente possibile.” Richiama l’esperienza su sistemi simili e la loro difficoltà. Ripete l’esempio pratico: “Se è un documento lungo, tipo 20 kilobyte di dati, significa che ogni singola modifica aggiunge altri 20 kilobyte di dati al database”¹.

L’aspettativa che guida il prototipo è netta: comprimere tutte le versioni insieme dovrebbe dare buoni risultati perché molte stringhe si ripetono tra una versione e l’altra. L’uso di zlib o zstd mira proprio a sfruttare quella ridondanza interna alle sequenze di testo preservate integralmente nell’array¹.

Willison aggiunge anche un dettaglio operativo sul formato della condivisione: “non si possono ancora condividere URL” delle conversazioni vocali. Nel post offre quindi il testo della discussione, utile a seguire come si è formata l’idea, in ordine cronologico e in forma discorsiva. La data del post fissa il momento: 9 agosto 2026¹.

Questo vincolo sugli URL spiega la scelta della trascrizione integrale: chi vuole capire il ragionamento trova nel testo la sequenza delle considerazioni che portano all’ipotesi di comprimere una storia di versioni in un unico blob JSON compresso, con l’obiettivo dichiarato di ridurre l’impatto dei salvataggi ripetuti di documenti lunghi¹.