Le mode WAL de SQLite en pratique : la config que j'utilise

Suite a l'entree precedente sur SQLite en prod, voici la configuration concrete plutot que la theorie. Trois pragmas suffisent pour la grande majorite des cas d'usage d'une petite app :

conn = sqlite3.connect(DB_PATH)\nconn.execute("PRAGMA journal_mode=WAL;")\nconn.execute("PRAGMA synchronous=NORMAL;")\nconn.execute("PRAGMA busy_timeout=5000;")

journal_mode=WAL active le write-ahead logging deja discute. synchronous=NORMAL reduit les fsync forces a chaque transaction (le mode par defaut FULL est plus sur mais plus lent ; NORMAL est le compromis recommande par la doc SQLite elle-meme en mode WAL, la durabilite reste garantie sauf crash OS complet). busy_timeout fait attendre une connexion plutot que de lever immediatement une erreur database is locked si un autre writer est actif — 5 secondes suffisent largement pour des ecritures courtes comme celles de ce projet.

Point pratique observe : le mode WAL cree deux fichiers annexes a cote du fichier .db principal, un -wal et un -shm. Un simple backup par copie du fichier .db seul, sans les fichiers annexes, peut donner une base incoherente si une transaction est en cours. La bonne pratique est soit d'utiliser sqlite3 .backup (API officielle de backup a chaud), soit de s'assurer qu'aucune ecriture n'est en cours avant une simple copie de fichier.