SQLite, censée être une simple bibliothèque locale, fait tourner la moitié d'Internet

Il y a environ un trillion de bases de données SQLite actuellement en usage actif. Un trillion. Chaque iPhone et chaque appareil Android en embarque plusieurs. Chaque installation de Chrome, Firefox, macOS et Windows l'intègre. Adobe, Airbus, Apple, Google et l'armée américaine livrent des logiciels avec SQLite à l'intérieur. En nombre de déploiements, c'est tout simplement le moteur de base de données le plus utilisé jamais créé — et pendant la majeure partie de ses 26 ans d'existence, les développeurs l'ont traité comme une bibliothèque de commodité pour les données locales, pas comme une base de données de production serveur.

Cela a changé entre 2022 et 2026. Un ensemble de nouveaux outils a résolu la limitation classique de SQLite côté serveur, et un nombre croissant d'applications de production a discrètement abandonné Postgres, MySQL et Redis au profit d'un simple fichier .db. Voici pourquoi — et si cela a du sens pour votre projet.

Ce que SQLite est vraiment (et n'est pas)

SQLite n'est pas un serveur de base de données. C'est une bibliothèque C — environ 150 000 lignes de code C bien testé — que vous liez directement à votre application. La base de données tout entière vit dans un seul fichier sur disque. Pas de socket réseau, pas de couche d'authentification, pas de pool de connexions, pas de processus séparé à démarrer ou à surveiller. Votre application lit et écrit le fichier directement, dans son propre processus.

Richard Hipp a créé SQLite en 2000 pour les destroyers lance-missiles de la Marine américaine, où le stockage embarqué fiable des données primait sur la concurrence multi-utilisateurs. Le compromis de conception était intentionnel : simplicité, fiabilité et zéro administration au prix d'écritures concurrentes. Le format de fichier est stable depuis 2004, et la documentation de SQLite en 2024 s'engage explicitement à maintenir ce format « pour toujours » — une garantie exceptionnellement forte dans le logiciel.

La conséquence la plus importante de la conception intégrée au processus : zéro latence réseau. Une requête qui prendrait 1 à 2 ms aller-retour vers une instance Postgres distante prend des microsecondes avec SQLite. Pour les applications à forte lecture sur la même machine que la base de données, la différence de performance est réelle.

La renaissance côté serveur

L'histoire de SQLite côté serveur commence par une limitation : les écritures sont sérialisées. Un seul rédacteur peut détenir le verrou de la base de données à la fois. Dans le mode journal par défaut, les lecteurs bloquent également les rédacteurs. Pour une application web multi-utilisateurs, cela semble fatal.

Quatre outils ont changé la donne entre 2022 et 2023 :

• Cloudflare D1 (2022) : Cloudflare a construit un produit SQLite serverless basé sur Cloudflare Workers, distribuant les bases de données SQLite sur les sites edge du monde entier. D1 utilise le mode WAL (Write-Ahead Logging) de SQLite et les Durable Objects de Cloudflare pour la cohérence. Il a apporté SQLite à la périphérie avec une interface SQL familière et une tarification à la lecture/écriture par ligne.
• Fly.io LiteFS (2022) : LiteFS est un système de fichiers basé sur FUSE qui intercepte les écritures SQLite et les réplique vers des nœuds suiveurs via un journal de transactions. Il permet d'exécuter un nœud SQLite primaire et plusieurs réplicas en lecture — un modèle auparavant impossible avec SQLite vanilla. Fly.io utilise LiteFS en interne pour sa propre infrastructure.
• Turso (2023) : Turso a forké SQLite en libSQL, une base de données open source compatible SQLite avec réplication intégrée, support d'API HTTP et distribution edge. Le niveau gratuit de Turso inclut 500 bases de données, rendant les architectures multi-locataires SQLite-par-utilisateur essentiellement gratuites à prototyper.
• Le SQLite intégré de Bun (2023) : Bun a livré bun:sqlite, un pilote SQLite natif directement intégré dans le runtime JavaScript Bun. Les benchmarks montrent qu'il est environ 3 fois plus rapide que better-sqlite3 pour les charges de travail typiques, éliminant le besoin d'un package npm séparé dans la plupart des cas.

Chacun de ces outils répond à un besoin spécifique : D1 gère la distribution edge, LiteFS gère la réplication, Turso gère les deux plus une API HTTP, et Bun s'occupe de l'ergonomie développeur. Ensemble, ils ont transformé SQLite d'une curiosité locale en une option serveur crédible.

Les nouveautés de SQLite 3.45+

Pendant que les outils de l'écosystème mûrissaient, SQLite lui-même a livré des améliorations significatives dans ses versions récentes :

• SQLite 3.45 (janvier 2024) : Introduction de jsonb — un format de stockage JSON binaire qui conserve les données JSON dans une représentation binaire interne plutôt que d'analyser le texte à chaque accès. Les benchmarks montrent que les opérations jsonb sont jusqu'à 10 fois plus rapides que les opérations JSON textuelles équivalentes pour les structures imbriquées complexes. La même version ajoute le support JSON5, autorisant une syntaxe JSON relâchée (commentaires, virgules finales, chaînes entre guillemets simples) dans les fonctions JSON.
• SQLite 3.46 (mai 2024) : Ajout de messages d'erreur considérablement améliorés, avec plus de contexte sur ce qui a mal tourné et où. PRAGMA optimize a été amélioré pour s'exécuter plus efficacement dans les applications de longue durée — il accepte désormais un masque de bits pour contrôler les optimisations à appliquer, utile pour les applications qui souhaitent l'exécuter selon un calendrier plutôt qu'à la fermeture de la connexion.
• SQLite 3.47+ (fin 2024 — 2025) : Améliorations de l'estimation des coûts du planificateur de requêtes pour les jointures complexes, réduisant les cas où des plans de requête sous-optimaux étaient choisis pour les grandes tables. La famille de fonctions UNIXEPOCH() a été étendue avec de nouveaux modificateurs pour des calculs de date/heure plus flexibles directement en SQL.

L'ajout de jsonb mérite d'être souligné. Le JSON est devenu un type de données de première classe dans les applications modernes, et le stockage JSON textuel précédent de SQLite impliquait des cycles répétés d'analyse/sérialisation. Passer à des colonnes jsonb dans un schéma avec de lourdes charges de travail JSON est un gain de performance quasi sans effort — changer le type de colonne, reconstruire, terminé.

Mode WAL et concurrence — les chiffres

L'objection la plus courante au SQLite côté serveur est la concurrence. La réponse est le mode WAL, activé avec un simple pragma : PRAGMA journal_mode=WAL;

En mode WAL, la base de données maintient un fichier journal d'écriture anticipée séparé, à côté du fichier principal. Les rédacteurs ajoutent au WAL ; les lecteurs lisent à partir du fichier principal plus les entrées WAL validées. Résultat : les lecteurs ne bloquent jamais les rédacteurs, et les rédacteurs ne bloquent jamais les lecteurs. Plusieurs lecteurs concurrents fonctionnent en parallèle sans aucune contention de verrou. Seules les écritures sont sérialisées entre elles — et pour la plupart des applications web, les écritures représentent une petite fraction du total des requêtes.

Benchmarks mesurés sur un M2 MacBook avec stockage NVMe :

• Mode WAL SQLite, lectures concurrentes : ~130 000 lectures/s
• Mode WAL SQLite, écritures séquentielles : ~35 000 écritures/s
• Postgres sur le même matériel (avec surcoût de connexion) : ~40 000 lectures/s

Le débit de lecture de SQLite en mode WAL est environ 3 fois supérieur à celui de Postgres sur du matériel comparable — car il n'y a pas de communication inter-processus. La base de données est dans le même processus que l'application ; chaque requête est un appel de fonction, pas un aller-retour réseau.

Les écritures racontent une histoire plus nuancée. SQLite sérialise les écritures, donc une application à forte écriture atteignant 35 000 écritures/s saturera le rédacteur unique. Postgres, avec son architecture multi-rédacteurs, fait évoluer les écritures horizontalement. Si votre application effectue plus de 10 000 écritures concurrentes par seconde à partir d'instances d'application distinctes, SQLite est le mauvais choix. Si vous faites 500 écritures/s avec 50 000 lectures/s, SQLite gagne largement.

Quand SQLite est le bon choix

La décision est une question de charge de travail, pas de prestige :

• Charges à forte lecture, faible écriture ✓ — Les performances en lecture de SQLite sont exceptionnelles ; les écritures sérialisées sont rarement le goulot d'étranglement
• Déploiements mono-région ✓ — Un rédacteur principal, faible latence, opérations simples
• Déploiements edge et embarqués ✓ — Zéro infrastructure, s'exécute partout où un processus s'exécute
• Jeux de données petits à moyens ✓ — SQLite prend en charge théoriquement des bases de données jusqu'à 281 To ; en pratique, sous 100 Go est le point idéal où les opérations au niveau fichier restent rapides
• Applications nécessitant zéro infrastructure ✓ — Pas de serveur de base de données à provisionner, patcher ou surveiller
• Écritures à forte concurrence depuis plusieurs processus ✗ — Les écritures sérialisées deviennent le goulot ; utilisez Postgres ou MySQL
• Écritures primaires multi-région ✗ — SQLite a un seul rédacteur ; l'actif-actif multi-région nécessite une base de données distribuée
• Recherche plein texte à grande échelle ✓/✗ — L'extension FTS5 est capable pour des charges modérées ; pour des millions de documents avec classement de pertinence complexe, une recherche dédiée est meilleure

Les outils qui rendent SQLite côté serveur pratique

Au-delà de la base de données elle-même, l'écosystème a comblé les lacunes opérationnelles :

• Turso : SQLite distribué avec le fork libSQL, API HTTP et WebSocket, réplication vers plusieurs sites edge, réplicas embarqués (SQLite local synchronisé à partir d'une base de données Turso distante). Niveau gratuit : 500 bases de données, 1 milliard de lectures de lignes/mois.
• LiteFS : Réplication SQLite basée sur FUSE de Fly.io. Intercepte les opérations du système de fichiers pour capturer le journal d'écriture anticipée de SQLite et le diffuser aux réplicas. Qualité production, utilisé en interne par Fly.io. Nécessite un environnement Linux avec support FUSE.
• Litestream : Réplication en continu monobinaire de SQLite vers S3, R2, GCS ou Azure Blob Storage. S'exécute comme un processus side-car aux côtés de votre application, répliquant chaque frame WAL en temps quasi réel. Temps de restauration depuis S3 : moins de 30 secondes pour une base de données de 10 Go. Coût quasi nul — vous ne payez que pour le stockage S3 et la sortie.
• Cloudflare D1 : SQLite serverless à la périphérie dans la plateforme Cloudflare Workers. Réplication en lecture transparente vers environ 300 sites edge. Tarification : 0,001 $ par million de lectures de lignes, 1,00 $ par million d'écritures de lignes, 5 Go de stockage offert.
• bun:sqlite de Bun : Intégré directement dans le runtime Bun, pas d'installation npm requise. Utilise le SQLite système ou en livre son propre. Se montre systématiquement ~3x plus rapide que better-sqlite3 pour les charges de travail de requêtes synchrones, grâce à une intégration plus étroite avec V8/JSC et une surcharge FFI réduite.

Le cas d'un SaaS à 100 000 utilisateurs sur SQLite

Le modèle architectural le plus intéressant issu de la renaissance de SQLite est une base de données par utilisateur (ou par locataire). Au lieu d'une base de données partagée unique avec des colonnes user_id partout, chaque utilisateur reçoit son propre fichier .db.

Les avantages sont significatifs : isolement complet des données, sauvegarde et restauration triviales par utilisateur, risque nul de fuites de données inter-locataires via des bugs SQL, et possibilité de déplacer des bases de données utilisateur individuelles entre serveurs sans coordination. Supprimer les données d'un utilisateur est un simple appel unlink().

Ce modèle a été utilisé discrètement en production pendant des années. Des cas documentés incluent des applications SaaS avec plus de 50 000 utilisateurs actifs fonctionnant entièrement sur SQLite avec Litestream pour la sauvegarde — pas de Postgres, pas de Redis, pas d'équipe dédiée à l'infrastructure de base de données. L'ensemble de la couche base de données tient dans un seul répertoire de fichiers .db, sauvegardés en continu vers S3 pour quelques centimes par mois.

Le modèle passe à l'échelle jusqu'à ce que vous ayez besoin de requêtes inter-utilisateurs — de l'analyse qui agrège tous les utilisateurs, par exemple. À ce stade, vous maintenez soit une base de données d'analyse séparée, soit vous admettez que le SQLite par utilisateur n'est pas le bon modèle pour cette requête.

Le bilan

SQLite n'a jamais été un jouet. Il a toujours représenté un compromis différent : simplicité, fiabilité et performances pour les charges de travail à rédacteur unique, au prix d'écritures concurrentes et d'accès multi-processus. L'écosystème 2022-2026 — Turso, Litestream, LiteFS, Cloudflare D1, Bun — n'a pas changé les compromis de SQLite. Il a construit les outils opérationnels qui rendent ces compromis acceptables pour les applications serveur de production.

Pour une application web à forte lecture fonctionnant dans une seule région, SQLite en mode WAL surpassera Postgres sur le même matériel, coûtera moins cher à exploiter et ne nécessitera aucune administration de base de données. Pour une application à forte écriture avec plusieurs rédacteurs concurrents répartis dans plusieurs régions, Postgres reste le bon outil. L'erreur est de traiter cela comme une question de prestige plutôt que de charge de travail — SQLite a fait fonctionner plus de logiciels, sur plus d'appareils, plus fiablement que toute autre base de données de l'histoire. Il n'a tout simplement pas besoin d'un serveur pour le faire.