SQLite en production : ce que Julia Evans a appris en le faisant tourner pour de vrai

Julia Evans publie ses notes sur SQLite : rien de spectaculaire, tout de très utile pour qui hésite à faire tourner une vraie appli sur ce petit fichier.

Le cas concret

Julia Evans - dont les zines et articles ont éduqué une génération de devs sur les internals de Linux, HTTP, DNS - a publié le 17 juillet 2026 sur son blog jvns.ca un billet intitulé « Learning a few things about running SQLite ». C'est ni un tuto d'introduction, ni un plaidoyer religieux : c'est un carnet de terrain d'une personne qui a mis SQLite en production sur son propre service, et qui note ce qui l'a surprise. Un régal.

Ce qu'on y apprend

Nous ne spoilerons pas l'article - allez le lire, il est en anglais mais court -, mais quelques points reviennent régulièrement dans les débats SQLite en production et méritent qu'on les rappelle ici pour les curieux :

1. WAL mode : indispensable pour la concurrence

Par défaut, SQLite utilise le mode journal DELETE, où les écritures bloquent les lectures. En WAL (Write-Ahead Logging), les lectures ne bloquent plus les écritures et vice-versa :

PRAGMA journal_mode = WAL;
PRAGMA synchronous = NORMAL;

synchronous = NORMAL (au lieu de FULL) accepte de perdre au maximum la dernière transaction en cas de coupure d'alimentation brutale, en échange d'un gain de perf massif. C'est ce que fait notamment Litestream et la plupart des serveurs SQLite modernes.

2. Une seule connexion écrivain, plusieurs lecteurs

Contrairement à PostgreSQL, SQLite ne parallélise pas les écritures. Un pattern classique en Rust ou Go : une seule connexion réservée à l'écriture, un pool de connexions pour les lectures. C'est le modèle de la crate rusqlite conjuguée à deadpool-sqlite avec cette séparation, ou de la lib Go mattn/go-sqlite3 avec sql.DB configuré SetMaxOpenConns(1) pour l'écriture.

3. Backups vivants : Litestream ou LiteFS

Sauvegarder un fichier SQLite « à la copie » quand une transaction est en cours, c'est le meilleur moyen d'avoir un backup corrompu. Deux outils règnent :

• Litestream (par Ben Johnson, aussi auteur de BoltDB) : réplique en continu vers S3, Backblaze B2 ou GCS. Streaming du WAL, restore rapide.
• LiteFS (même auteur, désormais chez Fly.io) : va plus loin, réplication multi-nœuds avec lecture depuis n'importe quelle réplique.

4. Le vrai plafond de SQLite en 2026

SQLite tient sans broncher des dizaines de milliers de requêtes par seconde sur un seul fichier, à condition d'être en WAL et de bien indexer. Le vrai plafond n'est pas SQL, c'est le disque : NVMe local >> disque réseau, EBS gp3 >> EFS. Beaucoup d'échecs SQLite en prod viennent d'avoir mis le fichier sur un share réseau (NFS notamment - SQLite le déconseille explicitement en gras dans sa doc sqlite.org/faq.html#q5).

À retenir

Le point de vue Julia Evans, comme toujours, c'est : essayer, mesurer, écrire ce qu'on trouve. Pas de « SQLite scales » ni de « you need Postgres for anything real ». Juste : ce comportement-là m'a surprise, voilà pourquoi, voilà ce que j'ai changé.

Pour tout dev qui hésite à sortir la grosse artillerie relationnelle pour une appli mono-serveur ou un side project, ce genre d'article vaut cent benchmarks synthétiques.