SQLite en production : WAL, concurrence et VFS
Original : SQLite in Production: Optimizing WAL Mode, Concurrency, and VFS Layers
Pourquoi c'est important
SQLite en production représente une alternative crédible aux SGBD client-serveur pour les architectures edge.
Un article technique de Micrologics détaille comment optimiser SQLite pour les serveurs applicatifs en production en configurant le mode WAL, les stratégies de checkpointing et les couches VFS personnalisées afin d'atteindre une latence ultra-faible.
Historiquement relégué aux applications mobiles et environnements de développement local, SQLite gagne du terrain en production grâce à la généralisation des SSD NVMe et des déploiements edge mono-tenant. En exécutant SQLite directement dans le processus applicatif, on élimine la latence réseau des bases client-serveur comme PostgreSQL ou MySQL, permettant des requêtes en dessous de la milliseconde.
Par défaut, SQLite utilise un journal de rollback qui bloque lectures et écritures simultanées. L'activation du mode WAL (`PRAGMA journal_mode = WAL`) résout ce problème : les nouvelles transactions sont ajoutées dans un fichier `.sqlite-wal` séparé, permettant des lectures et écritures concurrentes sans blocage mutuel.
L'article détaille quatre stratégies de checkpointing — PASSIVE, FULL, RESTART et TRUNCATE — qui contrôlent la fusion du fichier WAL vers la base principale. Le mode PASSIVE n'interrompt aucune opération mais peut laisser le WAL croître ; FULL et RESTART garantissent une fusion complète au prix d'un blocage temporaire des nouvelles transactions. Le choix de la stratégie est déterminant pour éviter des pics de latence en production.