SQLite, la base de données sous-estimée du web

Dis « je mets SQLite en production » dans une conversation de devs et observe : y'a ceux qui sachent, et les autres. Tu risques d'entendre « c'est pour les prototypes », ou « scalabilité » avec un ton grave. Pendant ce temps, SQLite tourne dans chaque téléphone, chaque navigateur, chaque avion de ligne : c'est la base de données la plus déployée au monde. Le prototype le plus utilisé de l'histoire, en somme.

Ce que SQLite est vraiment

Une bibliothèque, pas un serveur. Ta base est un fichier, les requêtes sont des appels de fonction dans ton process. Conséquences immédiates :

• Zéro administration : pas de service à installer, configurer, superviser, redémarrer à 3 h du matin.
• Zéro latence réseau : pas d'aller-retour vers un serveur de base, même en local. Une requête SQLite coûte souvent moins cher qu'un ping vers un MySQL distant.
• Sauvegarde = copie de fichier. Ton plan de reprise d'activité tient dans un copy. Essaie ça avec un cluster.

Et côté fiabilité, on ne parle pas d'un jouet : transactions ACID, tests d'une rigueur aéronautique : SQLite est certifiée pour l'avionique. Ta base tolère mieux un crash que ton gestionnaire de paquets.

« Oui mais : la montée en charge »

Parlons-en. SQLite lit à des vitesses indécentes et en mode WAL (Write-Ahead Logging), les lectures ne bloquent plus l'écriture. Sa vraie limite : un seul écrivain à la fois. C'est un problème si tu construis le prochain réseau social. Ce n'est pas un problème pour un site vitrine, un blog, un CMS, un outil métier, un SaaS mono-serveur, c'est-à-dire l'écrasante majorité des projets web. La documentation officielle elle-même cadre les cas d'usage : en dessous de ~100 000 visites/jour, tu es très loin de la zone rouge. Soyons honnête sur notre trafic : le dashboard analytics pleure dans un coin.

Le dimensionnement pour un trafic imaginaire est le péché capital de l'architecture web : on provisionne un PostgreSQL répliqué pour un site qui accueille 200 visiteurs par jour, comme on achèterait un bus pour emmener ses enfants à l'école.

En pratique avec PHP

PHP parle SQLite nativement via PDO, sans extension exotique :

$db = new PDO('sqlite:' . __DIR__ . '/data/app.db');
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$db->exec('PRAGMA journal_mode = WAL');
$db->exec('PRAGMA foreign_keys = ON');

$stmt = $db->prepare('SELECT * FROM articles WHERE slug = ?');
$stmt->execute([$slug]);

Trois détails de métier : active WAL (concurrence), active les clés étrangères (désactivées par défaut, cadeau historique), et mets le fichier hors de la racine web ou bloque son accès : servir sa base en téléchargement est un genre d'open data involontaire.

Ce que ça change dans un workflow solo

Pour un indépendant, SQLite aligne tout : le dev local et la prod utilisent exactement la même base (fini le « pourtant ça marche chez moi » version données), une base par projet ou par client isole naturellement les données, et migrer un site = déplacer un dossier. La stack entière (PHP, fichiers, SQLite) se déploie par simple copie. Pendant que d'autres écrivent des docker-compose, toi tu as déjà livré.

Le réflexe à inverser

La bonne question : « ai-je une raison précise d'installer un serveur de base de données ? », pas « SQLite tiendra-t-elle ? ». Écritures massivement concurrentes, plusieurs serveurs applicatifs, besoins d'administration fine : oui, prends PostgreSQL, c'est un excellent outil. Sinon, tu ajoutes un service à maintenir, un mot de passe à protéger et une latence à payer, pour gagner le droit de dire « ma stack » en réunion.

La technologie ennuyeuse qui marche depuis 2000 sans réclamer d'attention, c'est un luxe. SQLite est le collègue silencieux qui fait le boulot pendant que les autres font des slides.

FAQ

SQLite est-elle fiable pour un site en production ?

Oui : transactions ACID, tests d'une rigueur extrême, déployée dans des milliards d'appareils. Sa limite est la concurrence d'écriture, pas la fiabilité.

Combien de trafic SQLite peut-elle encaisser ?

La documentation officielle évoque un ordre de grandeur d'environ 100 000 visites/jour pour un site classique, largement au-dessus de la plupart des besoins.

Quand choisir PostgreSQL plutôt que SQLite ?

Écritures fortement concurrentes, plusieurs serveurs applicatifs accédant à la même base, ou besoins d'administration avancés.