SQLite et compression : un prototype révolutionne le stockage d’historiques

Quand la simplicité bat la complexité

« Et si on prenait juste toutes les versions d’un texte, qu’on les mettait dans un gros tableau JSON, et qu’on compressait le tout ? » L’idée, venue à Simon Willison lors d’une promenade avec son chien début août 2026, a de quoi surprendre. Dans un domaine où les systèmes de versioning sophistiqués comme Git règnent en maîtres avec leurs algorithmes de diff complexes, proposer de stocker bêtement toutes les versions complètes semble… naïf.

Sauf que les chiffres parlent d’eux-mêmes. Le prototype publié sur GitHub le 9 août démontre qu’avec Zstandard (zstd), un algorithme de compression moderne développé par Meta, 1000 révisions simulées représentant 20,4 Mo de texte brut se réduisent à 80,3 Ko. Soit un taux de compression de 99,6 %. La raison ? Les versions successives d’un même document partagent énormément de contenu identique, et les compresseurs modernes excellent précisément à éliminer ces redondances.

Deux prototypes, deux philosophies

Willison, figure reconnue de la communauté Python et SQLite, a en réalité développé deux variantes. La première, WholeBlobHistoryStore, réécrit l’intégralité de l’historique compressé à chaque modification. Simple, mais potentiellement coûteux en écriture pour de très longs historiques.

La seconde, ChunkedHistoryStore, découpe l’historique en « chunks » scellés — typiquement 128 révisions ou 3 Mo de JSON non compressé par bloc. Quand un chunk atteint sa limite, il est figé et un nouveau commence. Résultat : seul le dernier chunk est réécrit à chaque modification, ce qui améliore drastiquement le passage à l’échelle.

Les deux approches partagent des caractéristiques communes : elles préservent le texte complet et les timestamps de chaque version, ignorent les remplacements identiques par défaut, et utilisent BEGIN IMMEDIATE pour sérialiser les écritures et garantir l’atomicité des mises à jour.

L’IA comme partenaire de brainstorming

L’anecdote la plus révélatrice ne concerne pas la technique, mais la méthode. Willison a affiné son prototype en discutant vocalement avec GPT-Live, le nouveau mode conversationnel de ChatGPT, pendant sa promenade. « Le nouveau mode vocal GPT-Live dans l’app iPhone de ChatGPT est devenu vraiment bon », note-t-il, avant de partager la transcription de cette session de « stream of consciousness » technique.

Ce détail illustre un changement qualitatif dans l’intégration de l’IA : elle passe d’outil de productivité devant l’écran à partenaire de réflexion créative dans des contextes informels — marche, sport, trajets. Pour les développeurs en 2026, brainstormer avec une IA vocale devient aussi naturel que de discuter avec un collègue.

Inverser le paradigme du versioning

L’approche de Willison inverse le paradigme dominant. Depuis des décennies, les systèmes de versioning (Git, Mercurial, SVN) stockent les différences entre versions (diffs) et reconstruisent les états complets à la demande. C’est conceptuellement élégant mais techniquement complexe : il faut calculer les diffs, les stocker, gérer les branches, les merges, reconstruire les versions…

Ici, on stocke les versions complètes et on compte sur la compression pour l’efficacité. C’est conceptuellement trivial : un tableau JSON de strings. Pas de diff, pas de reconstruction, pas d’algorithme de merge sophistiqué. Juste : compresser, stocker, décompresser. Dans un contexte où la complexité logicielle est un problème majeur, cette simplicité a une valeur disproportionnée.

Selon les recherches multi-sources, cette approche s’inscrit dans une tendance plus large : les algorithmes de compression modernes sont devenus si efficaces qu’ils changent les compromis architecturaux fondamentaux. Ce qui était vrai il y a dix ans — « la compression coûte cher, l’espace disque est limité » — ne l’est plus. La compression est rapide, le stockage abondant, et zstd peut atteindre des ratios que zlib ne pouvait qu’envier.

Des cas d’usage concrets

Où cette approche pourrait-elle briller ? Partout où l’on gère des historiques textuels volumineux : CMS (systèmes de gestion de contenu), wikis d’entreprise, applications de prise de notes, éditeurs collaboratifs, systèmes de documentation technique, ou encore les audit trails réglementaires qui doivent conserver toutes les modifications.

Le projet hermes-lcm, cité dans les sources, s’en inspire déjà pour implémenter une gestion de contexte « lossless » pour agents IA : il utilise SQLite avec FTS5 (recherche plein texte) et compression pour maintenir un historique de conversation complet tout en gardant le prompt actif borné. « Bounded context, unbounded memory. Nothing is ever lost », résume sa documentation.

Autre exemple : le système @Voice, une application de lecture vocale, a récemment amélioré sa détection de chapitres et sa gestion des mots en majuscules — des fonctionnalités qui bénéficieraient d’un historique robuste pour le debugging et l’analyse utilisateur.

Les questions qui restent ouvertes

Le prototype soulève autant de questions qu’il n’apporte de réponses. Performance de décompression : accéder à une version ancienne nécessite de décompresser tout l’historique — est-ce acceptable pour des milliers de versions ? Concurrence : comment gérer les modifications simultanées ? Limite de taille : existe-t-il un point de bascule où une autre approche devient plus efficace ?

Et surtout : comment cette approche se compare-t-elle, chiffres à l’appui, avec Git, les systèmes de diff traditionnels, ou les solutions commerciales ? Willison n’a pas encore publié de benchmarks détaillés comparant zlib et zstd sur différents types de contenus (code source, markdown, HTML, texte brut).

Selon les discussions sur le forum SQLite et les projets connexes, certains développeurs explorent déjà des variantes : stockage par chunks avec compression LZ4 pour PostgreSQL 19, utilisation de OPFS (Origin-Private FileSystem) pour SQLite en WebAssembly, ou encore intégration de compression Brotli pour les API JSON.

Un signal pour l’écosystème tech

Au-delà de la technique, ce prototype envoie trois signaux forts. Premièrement, SQLite n’est plus une « petite » base de données — c’est une infrastructure critique pour le edge computing, défiant les solutions cloud centralisées. Deuxièmement, l’IA s’intègre naturellement dans les processus créatifs des développeurs, pas seulement comme outil de productivité mais comme partenaire de réflexion. Troisièmement, les hypothèses sur les compromis espace/complexité doivent être réévaluées : ce qui semblait gaspilleur il y a dix ans est devenu viable grâce aux progrès de la compression.

Pour les investisseurs, cela valide plusieurs paris : l’écosystème SQLite (Turso, Cloudflare D1), les outils de développement intégrant l’IA (GitHub Copilot, Cursor), et le mouvement local-first (Linear, applications Notion-like mais locales). Pour les développeurs, c’est une invitation à expérimenter : le prototype est sur GitHub, ouvert aux contributions.

Et maintenant ?

À court terme (1-3 mois), attendez-vous à des benchmarks détaillés, des tests sur différents types de contenus, et des premières implémentations par des early adopters. À moyen terme (6-12 mois), plusieurs scénarios se dessinent : adoption par des frameworks populaires (Rails, Django) comme option de versioning intégrée, utilisation de niche pour des cas spécifiques (wikis, notes, documentation), ou découverte de limitations qui cantonnent l’approche aux prototypes.

Le scénario le plus disruptif ? Une intégration native dans SQLite lui-même comme extension officielle, démocratisant l’approche auprès de millions de développeurs. Après tout, SQLite est déjà la base de données la plus déployée au monde — présente dans chaque smartphone, navigateur, et système d’exploitation.

Une chose est sûre : dans un monde où la complexité logicielle explose, les solutions simples qui fonctionnent ont une valeur disproportionnée. Et parfois, la meilleure innovation consiste à se demander, lors d’une promenade avec son chien : « Et si on faisait juste… ça ? »