SQLite n'est pas une base de données de jouet — et un nombre croissant d'applications en production le prouve

SQLite est le moteur de base de données le plus déployé au monde. Il tourne dans chaque appareil Android, chaque iPhone, chaque navigateur de bureau, chaque Mac et la plupart des systèmes Windows. On estime à plus d'un billion le nombre de bases SQLite actuellement en usage. Et pendant la majeure partie de son histoire, la règle implicite du développement web était : SQLite convient pour le développement et les tests, mais on passe à Postgres ou MySQL avant la mise en production.

Cette règle est aujourd'hui activement remise en question — non pas par provocation, mais par des développeurs qui exploitent des systèmes réels en production et en publient les résultats. Le changement est à la fois philosophique et technique.

L'objection traditionnelle

L'argument classique contre SQLite dans les applications web en production repose sur la concurrence. SQLite est une base de données fichier : toutes les lectures et écritures frappent un seul fichier sur le disque, et bien qu'elle autorise plusieurs lecteurs simultanés, un seul écrivain à la fois est permis. En mode WAL (Write-Ahead Logging), activé depuis 2010, les lecteurs et l'unique écrivain ne se bloquent pas mutuellement — mais on reste avec un seul écrivain. Pour les applications à forte concurrence d'écriture, c'est une contrainte dure.

La seconde objection est opérationnelle : si votre application tourne sur plusieurs serveurs, ils ne peuvent pas partager un fichier SQLite. Les bases de données distribuées comme Postgres via TCP/IP sont conçues pour cela ; SQLite non. Cela rendait SQLite essentiellement non viable pour les applications web scalées horizontalement.

Les deux objections sont réelles. Aucune n'est universelle.

Ce qui a changé : l'écosystème de réplication

En 2021, Ben Johnson a publié Litestream — un outil Open Source qui streame le fichier WAL de SQLite vers un stockage objet compatible S3 en quasi temps réel. Le pitch : vous obtenez une sauvegarde hors site automatique avec un RPO inférieur à la seconde, sans modifier le code de votre application ni passer à une base de données client-serveur. Litestream ne résout pas la contrainte d'un seul écrivain ; il résout le problème de sauvegarde et reprise après sinistre qui rendait SQLite risqué pour la production. Pour de nombreux cas d'usage, c'est le problème le plus pressant.

Fly.io est allé plus loin avec LiteFS, un système de fichiers distribué qui utilise FUSE pour intercepter les écritures SQLite et les répliquer vers des nœuds réplicas. LiteFS vous donne un nœud primaire qui accepte les écritures et des réplicas en lecture qui le suivent — similaire à la réplication par streaming de Postgres, mais pour SQLite. Les applications qui peuvent router les écritures vers le primaire et les lectures vers n'importe quel réplica bénéficient d'une mise à l'échelle en lecture horizontale sans changer de moteur de base de données.

L'effort le plus ambitieux est Turso, construit sur libSQL — un fork du code source de SQLite qui ajoute un protocole réseau, du multi-tenant et de la réplication en périphérie. Le pitch de Turso est « SQLite at the Edge » : chaque utilisateur obtient un shard de base de données situé géographiquement près de lui, éliminant la latence d'une base centrale. La société a levé 32 millions de dollars lors d'une série A en 2023. libSQL est Open Source ; le service managé de Turso est le produit commercial. Le service de base de données D1 de Cloudflare utilise une architecture similaire, offrant un stockage compatible SQLite en tant que primitive serverless.

L'argument performance

Pour les applications où la base de données réside sur la même machine que le serveur applicatif — ce qui est vrai pour une large part des applications auto-hébergées et de taille petite à moyenne — SQLite en mode WAL est souvent plus rapide que Postgres ou MySQL dans les Benchmark de charges OLTP à forte lecture. La raison est l'élimination de la latence réseau : une requête SQLite locale ne traverse pas de connexion TCP. Le coût d'un aller-retour réseau vers un serveur Postgres, même sur localhost, est de quelques centaines de microsecondes. À volume de requêtes élevé, cela s'accumule.

L'article COST de 2015 (« Scalability! But at what COST? ») faisait un point similaire dans le contexte du traitement distribué de graphes : une seule machine exécutant du code monothread bien optimisé surpassait souvent des systèmes distribués comme Hadoop pour des graphes tenant en RAM. La leçon se généralise : les systèmes distribués ont un surcoût, et si vos données tiennent sur une machine, vous payez ce surcoût sans bénéfice.

Le mode WAL de SQLite est aussi extrêmement bien optimisé pour une forte concurrence en lecture. Les Benchmark de Turso et de développeurs indépendants montrent systématiquement SQLite gérant des dizaines de milliers de lectures par seconde sur du matériel modeste, bien dans les limites de la plupart des applications web en production.

Qui fait ça concrètement

37signals — la société derrière Basecamp et Hey — a été le plus fervent défenseur public. L'article de blog de DHH en 2023 arguant que SQLite avec Litestream suffit pour la plupart des applications web a généré de nombreuses discussions. 37signals utilise un modèle « une base de données par client » pour une partie de son infrastructure, où la propriété d'un fichier unique par base SQLite devient un avantage : les données de chaque client sont isolées dans son propre fichier, et les sauvegardes sont d'une simplicité enfantine.

De nombreux développeurs indépendants et petites équipes ont migré vers SQLite pour des raisons similaires : modèle opérationnel plus simple, pas de processus serveur de base de données à gérer, sauvegarde triviale (copier le fichier), et performances qui répondent à leurs besoins. L'essor de plateformes comme Railway et Fly.io, qui permettent d'exécuter facilement une base SQLite persistante aux côtés d'une application web, a encore abaissé la barrière opérationnelle.

Là où ça ne tient toujours pas

La contrainte d'un seul écrivain est un vrai plafond. Les applications avec un débit d'écriture soutenu élevé — pipelines d'ingestion analytique, systèmes de trading haute fréquence, plateformes sociales avec des millions d'opérations d'écriture simultanées — ont réellement besoin d'une base de données capable de répartir les écritures sur plusieurs nœuds. SQLite ne peut pas le faire nativement, et les outils de réplication construits autour ne changent pas le modèle d'écriture fondamental.

Les très grands jeux de données posent aussi des défis. SQLite supporte théoriquement des bases jusqu'à 281 To, mais les performances pratiques sur des bases de plus de quelques centaines de Go se dégradent. Les mécanismes de Postgres comme VACUUM, autovacuum et le partitionnement sont matures et bien compris à grande échelle ; les équivalents de SQLite sont plus simples et moins éprouvés sur de gros volumes.

La règle empirique qui émerge de la communauté : si votre QPS en écriture est inférieur à quelques milliers par seconde et que votre jeu de données tient confortablement sur un seul disque, SQLite avec WAL mérite d'être sérieusement évalué. Si vous avez besoin d'écritures multi-primaires, de réplication synchrone inter-datacenter, ou de sécurité au niveau ligne avec des hiérarchies de rôles complexes, Postgres reste l'outil adapté.

Ce qui a changé, c'est le cadre. SQLite n'est pas un jouet. C'est un moteur de base de données mature, abondamment testé, avec plus de deux décennies d'utilisation en production dans des contextes bien plus exigeants que la plupart des applications web. La question n'est pas de savoir si SQLite est sérieux — c'est de savoir si les contraintes spécifiques de votre application correspondent à son modèle. Pour un nombre croissant de systèmes en production, c'est le cas.