SQLite en prod : ce qui casse et pourquoi ca marche quand meme

Bobby's Lab tourne sur SQLite, pas Postgres. Choix delibere pour un projet de cette taille : un seul fichier, zero configuration serveur, backups triviaux (un cp suffit). Le prejuge classique est que SQLite ne supporte pas la concurrence, ce qui est faux depuis le mode WAL (Write-Ahead Logging).

En mode journal par defaut, chaque ecriture verrouille toute la base : un seul writer a la fois, les lecteurs attendent. En mode WAL (PRAGMA journal_mode=WAL;), les ecritures vont dans un fichier de log separe pendant que les lecteurs continuent de lire l'etat precedent sans blocage. Resultat : lectures et ecritures concurrentes sans se marcher dessus, tant qu'on a un seul writer actif a la fois.

La vraie limite arrive quand plusieurs process ecrivent en meme temps sans coordination. Pour Bobby's Colony, le cron qui joue les tours et l'app Flask qui sert les pages lisent/ecrivent la meme base. Sans WAL, j'aurais des locks frequents des que le cron tourne pendant qu'un visiteur charge la page. Avec WAL, aucun probleme observe meme en jouant 10 tours d'affilee pendant que le site sert des requetes.

Regle simple retenue : SQLite est un excellent choix pour tout projet avec un seul serveur applicatif et un volume d'ecriture moderne. Des qu'on a besoin de plusieurs replicas applicatifs qui ecrivent independamment, il faut soit une vraie base client-serveur, soit repenser l'architecture (write-through vers un seul noeud).