TL;DR — Résumé Rapide
SQLite comme base de données en production est de plus en plus viable pour les applications web. Apprenez quand utiliser SQLite et les stratégies de backup.
SQLite a évolué d’une base de données embarquée légère vers une base de données de production légitime. Ce guide couvre quand SQLite est le bon choix, comment le configurer pour des performances optimales et comment gérer les sauvegardes.
Prérequis
- Connaissances SQL de base
- Serveur Linux (Ubuntu/Debian recommandé)
- SQLite 3.35+
Quand Utiliser SQLite en Production
SQLite est excellent quand votre application tourne sur un seul serveur, votre charge est dominée par les lectures (90%+) et vos données tiennent dans 1 To ou moins. Il n’est pas adapté pour plusieurs serveurs d’écriture ou les transactions distribuées.
Configuration pour la Production
Activez WAL avec PRAGMA journal_mode = WAL, configurez busy_timeout = 5000, cache_size = -64000 et synchronous = NORMAL.
Stratégies de Sauvegarde
Utilisez Litestream pour la réplication continue vers S3. Exécutez-le comme service systemd pour des sauvegardes automatiques continues.
Comparaison
| Fonctionnalité | SQLite | PostgreSQL | MySQL |
|---|---|---|---|
| Complexité setup | Aucune | Moyenne | Moyenne |
| Écrivains concurrents | 1 (WAL) | Illimités | Illimités |
| Coût opérationnel | 0 $ | 50-500 $/mois | 50-500 $/mois |
Pièges et Cas Particuliers
- Le fichier WAL peut grossir pendant les périodes d’écriture intensive
- Ne placez jamais une base SQLite sur un système de fichiers réseau (NFS)
Résumé
- SQLite est une base de données légitime pour les applications mono-serveur avec lectures dominantes
- Activez WAL, configurez busy_timeout et synchronous = NORMAL
- Litestream fournit une sauvegarde continue vers le stockage cloud