SQLite : quand cela suffit

Dans quels cas SQLite sur un VPS est préférable à un serveur de base de données séparé, comment activer WAL et éviter « database is locked », et quand il est temps de passer à PostgreSQL.

Mis à jour le 23 août 2026

SQLite est une base de données contenue dans un seul fichier : pas de service, pas de port, pas de mot de passe. Pour un bot, un petit panneau ou un site avec des écritures peu fréquentes, c'est le bon choix : elle ne consomme pas de mémoire — et VDS-1 n'en a que 2 Go — et il n'y a rien à configurer.

Quand l'utiliser

Adapté :

bots Telegram et Discord, compteurs, réglages ;
sites avec des milliers de lectures et des dizaines d'écritures par minute ;
tout projet sur une seule machine sans projet de second serveur.

Non adapté :

plusieurs processus qui écrivent activement en même temps ;
une base de données de plus de quelques dizaines de gigaoctets ;
un accès réseau depuis une autre machine — SQLite ne sait tout simplement pas le faire.

Dans les deuxième et troisième cas, utilisez PostgreSQL ou MySQL.

Travailler avec le fichier

apt install -y sqlite3
sqlite3 /srv/app/data/app.db

CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT NOT NULL);
INSERT INTO users (name) VALUES ('test');
.tables
.schema users
.quit

Le fichier de base de données doit se trouver sur le disque local de la machine et appartenir à l'utilisateur de l'application :

chown appuser:appuser /srv/app/data/app.db
chmod 640 /srv/app/data/app.db

Le répertoire contenant la base de données doit également être accessible en écriture : SQLite crée à côté les fichiers temporaires -wal et -shm.

Réglages indispensables

Deux pragma éliminent la plupart des problèmes :

PRAGMA journal_mode = WAL;
PRAGMA busy_timeout = 5000;

WAL permet aux lecteurs de lire pendant qu'une écriture est en cours — sans lui, tout lecteur est bloqué par l'écrivain. busy_timeout fait attendre le client cinq secondes au lieu d'échouer immédiatement. Définissez-les à chaque ouverture de connexion dans le code, pas une seule fois dans la console.

Sauvegardes

Vous ne pouvez pas copier le fichier avec un simple cp pendant que l'application tourne — vous obtiendrez une base de données corrompue. Une commande sûre est intégrée :

sqlite3 /srv/app/data/app.db ".backup '/srv/backups/app-$(date +%F).db'"

Placez-la dans cron et déplacez la copie hors de la machine : le VPS n'a ni sauvegardes automatiques ni snapshots. L'approche générale est décrite dans sauvegardes de bases de données.

Erreurs courantes

Symptôme	Cause
`database is locked`	Pas de WAL ni de `busy_timeout`, ou un second processus détient une longue transaction
`attempt to write a readonly database`	Pas de permissions sur le fichier ou le répertoire
`disk I/O error`	Espace disque insuffisant — vérifiez l'anneau d'utilisation du disque dans « Vue d'ensemble »
La base grossit après suppression de lignes	L'espace n'est pas récupéré automatiquement : `VACUUM`
Base corrompue après copie	Vous avez copié avec `cp` pendant l'exécution — utilisez uniquement `.backup`

Quand migrer

Signes : des erreurs database is locked régulières même avec WAL activé, plusieurs workers applicatifs, des rapports qui prennent des minutes à calculer. Pour migrer, consultez migration de base de données.

Le fichier de base de données ne doit pas se trouver dans un répertoire servi par le serveur web. /var/www/app.db peut être téléchargé via un lien direct, avec tous les mots de passe et données utilisateur.