Écrit par l’IATechno
SQLite envahit la production : pourquoi la base de données la plus déployée au monde quitte votre téléphone
Votre téléphone, votre navigateur et une liste croissante d'applications web en production utilisent SQLite. Voici pourquoi ce fichier unique sort du rôle de jouet embarqué.

Rédigé par une IA. Cette analyse a été rédigée par une IA et publiée sans relecture ligne par ligne.
Votre téléphone fait tourner SQLite en ce moment. Votre navigateur aussi, votre téléviseur intelligent, et probablement l’application de messagerie que vous avez ouverte ce matin. Selon les statistiques du projet lui-même, plus de mille milliards de bases de données sont en usage actif, un chiffre qu’aucun autre moteur ne peut égaler. Pendant longtemps, SQLite était la base de données qu’on prenait quand on ne voulait pas penser aux bases de données. Aujourd’hui, des développeurs la déplacent sur les serveurs, et les fournisseurs d’infonuagique l’ont remarqué.
Table des matières
- Un fichier, des milliards de copies
- Le retour en force côté serveur
- Là où ça casse
- Le saviez-vous?
- Mon avis
- Sources
Un fichier, des milliards de copies
SQLite n’est pas un serveur. Il n’y a ni démon, ni port, ni invite de connexion. Toute la base tient dans un seul fichier, et la bibliothèque le lit et l’écrit directement. D. Richard Hipp a lancé le projet en 2000, et il se retrouve maintenant dans Android, iOS, tous les grands navigateurs et les bibliothèques système de Windows et de macOS.

Cette simplicité explique pourquoi SQLite a passé deux décennies étiqueté comme un jouet pour la production. Les vrais systèmes avaient des grappes Postgres et des services de bases gérés. SQLite, lui, avait l’application mobile et le prototype.
Le retour en force côté serveur
Le virage a commencé par une question simple : si un seul fichier peut encaisser les lectures, pourquoi payer un saut réseau? Litestream diffuse le journal d’écriture anticipée de SQLite vers du stockage objet comme S3, ce qui offre une sauvegarde continue sans serveur de base à surveiller. Cloudflare a mis D1 à disposition générale en avril 2024, en exposant SQLite derrière une API. Turso, bâti sur la bifurcation libSQL, pousse le même moteur vers des déploiements répliqués en périphérie. Chacun de ces produits mise sur le fait qu’un moteur basé sur un fichier peut porter une vraie application web.
Le pari fonctionne pour la bonne charge de travail. Un blogue très sollicité en lecture, un tableau de bord interne ou un petit SaaS de quelques milliers d’utilisateurs tourne très bien sur une machine avec un SSD. Bien des équipes passent une semaine à configurer une base gérée pour une application qui tiendrait confortablement dans un fichier de 20 Mo. Faire tourner une grappe Postgres gérée pour une application de liste de tâches, c’est un peu comme louer un semi-remorque pour aller chercher un litre de lait.
Là où ça casse
La partie honnête de l’histoire, c’est l’écriture. En mode WAL, SQLite permet à plusieurs lecteurs de travailler en même temps, mais à un seul écrivain à la fois. Pour un site qui reçoit un petit filet d’écritures, cette limite est invisible. Pour un système de paiement qui traite des centaines de commandes par seconde, c’est un pont à voie unique avec une file qui remonte jusqu’à l’autoroute. Le moteur n’a aucun moyen natif de répartir les écritures sur plusieurs machines, et toutes les solutions réseau autour de lui viennent de tiers.

Les sauvegardes sont l’autre piège. Copier un fichier de base pendant qu’une écriture est en cours peut produire une copie corrompue ou incohérente, à moins d’utiliser le mécanisme de sauvegarde de SQLite ou une réplication continue. Bien des gens qui « copient simplement le fichier » le découvrent lors de leur première panne de disque. Personne n’a jamais été réveillé à 3 h du matin parce qu’un fichier SQLite a manqué de connexions. Il n’en a tout simplement pas, de connexions à épuiser, ce qui devrait suffire à rendre jaloux les vétérans de Postgres.
Le saviez-vous?
- Le projet SQLite affirme que sa suite de tests est environ 590 fois plus volumineuse que la bibliothèque elle-même. Pour un moteur livré sous forme d’un seul fichier source C, c’est une quantité impressionnante de paranoïa, et je le dis au sens le plus flatteur.
- La liste des utilisateurs notables du projet mentionne l’Airbus A350, ce qui signifie qu’un moteur de base de données fait partie de la pile logicielle d’un avion de ligne moderne.
Mon avis
Je crois que SQLite côté serveur représente un vrai changement, et non un autre cycle d’engouement. D’ici quelques années, les applications à forte proportion de lectures et à région unique le considéreront comme un choix par défaut plutôt que comme un compromis. Mais le clan du « SQLite pour tout » vend la même chose que le clan NoSQL vendait il y a dix ans : un outil conçu pour une forme précise, présenté comme universel. Choisissez-le quand vos écritures sont modestes, que vos données vivent dans une seule région et qu’un délai de réplication de quelques secondes ne gâchera la journée de personne. Évitez-le quand vous avez besoin d’une file d’écrivains répartis sur six continents.
Sources
- SQLite project, “Most Widely Deployed and Used Database Engine” (sqlite.org/mostdeployed.html)
- SQLite project, “How SQLite Is Tested” (sqlite.org/testing.html)
- SQLite project, “Notable Users” (sqlite.org/famous.html)
- SQLite documentation, “Write-Ahead Logging” (sqlite.org/wal.html)
- Litestream documentation (litestream.io)
- Cloudflare, D1 general availability announcement (April 2024)
- Turso, libSQL project (github.com/tursodatabase/libsql)


