SQLite est en train de manger le monde

La Base de Données la Plus Déployée Que Vous N'avez Jamais Déployée

SQLite est installé sur plus d'un billion d'appareils. Votre téléphone l'a. Votre navigateur l'a. Chaque installation macOS en est livrée. Il alimente la base de données SMS sur Android, le stockage des marque-pages dans Firefox et les métadonnées photo sur votre iPhone. Et pourtant, jusqu'à récemment, la plupart des développeurs backend le traitaient comme un jouet — quelque chose pour les prototypes, les applications mobiles et les scripts locaux, pas pour faire fonctionner un véritable service web.

Cela change rapidement.

Ce Qu'est Réellement SQLite

SQLite n'est pas un serveur de base de données. Il n'a pas de couche réseau, pas de système d'authentification, pas de démon à gérer. C'est une bibliothèque C qui lit et écrit un seul fichier sur le disque. Vous la liez à votre application et l'appelez directement — pas de chaînes de connexion, pas de numéros de port, pas de fichiers de configuration à gérer.

Ce qu'il a : une conformité ACID complète, une implémentation SQL complète (fonctions de fenêtrage, CTE, support JSON, recherche en texte intégral), des performances de requête inférieures à la milliseconde pour les charges de travail typiques, et un format de fichier si stable que l'équipe SQLite garantit la rétrocompatibilité jusqu'en 2050. La base de données entière est un seul fichier que vous pouvez copier, envoyer par e-mail ou mettre dans un système de contrôle de version.

Pendant 30 ans, cette combinaison en a fait la base de données dominante pour les cas d'utilisation embarqués — le genre où vous avez besoin de persistance sans infrastructure. Mais "embarqué" est en train d'être redéfini.

Pourquoi l'Utilisation en Production N'était Pas Évidente

La critique traditionnelle de SQLite pour les charges de travail serveur se résume à deux limitations réelles :

• Concurrence : SQLite utilise un verrouillage au niveau du fichier. En mode WAL (WAL = Write-Ahead Log), les lecteurs ne bloquent pas les écrivains et vice versa, mais vous n'avez toujours qu'un seul écrivain à la fois. Les charges de travail d'écriture à haute concurrence vont faire la queue.
• Machine unique : La base de données vit sur un système de fichiers. Pas de réplication intégrée, pas de basculement vers un serveur de secours, pas d'écritures multi-régions. Si votre serveur meurt, votre base de données aussi.

Ce sont de vraies contraintes. Mais pour la plupart des applications web, elles sont sans importance. L'application CRUD moyenne a un ratio lecture/écriture qui est de 90 % de lectures. La concurrence d'écriture au-delà de quelques dizaines de requêtes par seconde est un problème que la plupart des applications n'auront jamais. La complexité de Postgres — regroupement de connexions, latence de réplication, basculement de secours, migrations de schéma entre réplicas — existe pour résoudre des problèmes qui n'existent pas à l'échelle à laquelle la plupart des développeurs opèrent réellement.

La Vague SQLite Distribué

L'écosystème qui a émergé autour de SQLite pour une utilisation serveur a directement abordé les limitations restantes. Trois projets sont à l'origine de ce changement.

Turso et LibSQL

LibSQL est un fork open-source de SQLite maintenu par Turso. Il ajoute les fonctionnalités qui rendaient SQLite peu pratique pour les déploiements serveur : réplication en mode WAL via HTTP, accès à distance via un protocole natif, extensions chargeables activées par défaut, et prise en charge des réplicas embarqués — ce qui signifie que votre application peut conserver une copie SQLite locale qui se synchronise à partir d'un serveur primaire distant. Vous obtenez une latence de lecture locale avec une durabilité à distance.

Le résultat est quelque chose qui ressemble à une base de données serverless mais qui fonctionne comme un fichier local. Le service hébergé de Turso vous permet de créer des bases de données en quelques secondes et de les répliquer entre régions sans toucher à un fichier de configuration. Leur niveau gratuit est suffisamment généreux pour que les petites applications ne dépensent jamais un centime.

Cloudflare D1

Cloudflare D1 exécute SQLite à l'intérieur de Cloudflare Workers en périphérie. Lorsqu'un Worker à Francfort interroge D1, il accède à une instance SQLite fonctionnant dans le même centre de données, sans traverser un océan pour atteindre un cluster Postgres en Virginie. La latence des requêtes, qui se mesurait en centaines de millisecondes, tombe à un seul chiffre.

D1 gère la réplication de manière transparente. Vous écrivez sur un serveur primaire, Cloudflare réplique les lectures vers les emplacements périphériques. L'API est du SQL standard — vous pouvez utiliser drizzle-orm, kysely ou des requêtes brutes. C'est SQLite avec une couche de lecture globale que vous n'avez pas eu à construire.

Le SQLite Intégré de Bun

Bun est livré avec une liaison SQLite native depuis la v1.1 — pas d'installation npm, pas de compilation de module natif, pas de dépendance better-sqlite3 à gérer. Vous importez bun:sqlite et ouvrez une base de données. C'est tout. Pour les développeurs JavaScript construisant des services légers ou des outils CLI, la friction pour adopter SQLite vient de tomber à zéro.

Rails 8 en a Fait la Valeur par Défaut

Le signal le plus important que SQLite a franchi un seuil : Rails 8, sorti fin 2024, livre SQLite comme base de données par défaut pour les nouvelles applications. Ce n'est pas une commodité de prototype — DHH et l'équipe principale de Rails ont été explicites sur le fait que SQLite est le bon choix pour la plupart des applications, et ils ont investi dans des outils pour le rendre prêt pour la production : solid_queue pour les tâches d'arrière-plan sur SQLite, solid_cache pour la mise en cache, et l'intégration de sauvegarde basée sur Litestream.

Lorsque le framework qui a défini le modèle d'application web moderne utilise par défaut une base de données basée sur un fichier, la conversation dans l'industrie a changé.

L'Argument "SQLite pour Tout"

L'argument n'est pas subtil : pour 80 % des applications web, vous n'avez pas besoin de Postgres. Vous n'avez pas besoin d'un pool de connexions. Vous n'avez pas besoin d'un réplica. Vous avez besoin d'une base de données rapide, fiable et qui ne nécessite pas d'administrateur système pour fonctionner.

SQLite vous donne :

• Zéro configuration — pas de serveur à démarrer, pas d'utilisateur à créer, pas de port à ouvrir
• Configuration instantanée — créez un fichier, commencez à écrire du SQL
• Sauvegardes triviales — copiez le fichier, ou utilisez Litestream pour une réplication continue vers S3
• Excellentes performances en lecture — inférieures à la milliseconde pour les requêtes indexées sur des bases de données allant jusqu'à des dizaines de gigaoctets
• Garanties ACID — le mode WAL vous donne des lectures concurrentes et une sécurité en cas de crash sans réglage

La simplicité opérationnelle se cumule. Lorsque votre base de données est un fichier, votre déploiement est plus simple. Votre environnement de développement correspond exactement à la production. Le débogage est plus facile. Vous pouvez ouvrir la base de données dans DB Browser for SQLite et regarder les données directement.

Là Où Cela Ne Convient Toujours Pas

SQLite ne remplacera pas Postgres partout. Les scénarios d'écriture multi-régions — où vous avez besoin d'écritures à faible latence depuis plusieurs emplacements géographiques simultanément — sont vraiment difficiles avec SQLite. Vous pouvez contourner le problème avec des réplicas embarqués LibSQL et un routage d'écriture minutieux, mais ce n'est pas natif. Les charges de travail d'écriture à haute concurrence (pensez : un flux social avec des millions d'écrivains simultanés) rencontreront le goulot d'étranglement de l'écrivain unique.

L'écosystème Postgres est également plus profond : de meilleures extensions (pgvector, PostGIS, TimescaleDB), des outils d'observabilité plus matures, des décennies de connaissances opérationnelles, et un contrôle de concurrence multi-version qui gère la contention d'écriture plus élégamment. Si vous construisez un système où le débit d'écriture est le goulot d'étranglement, Postgres est toujours le bon choix.

Le Changement Est Réel

Le schéma ici n'est pas nouveau. SQLite est passé de "jouet" à "option sérieuse" en résolvant les problèmes qui le maintenaient dans le monde embarqué — et il l'a fait non pas en devenant plus complexe, mais en inspirant un écosystème qui a ajouté les pièces manquantes autour de lui. LibSQL a ajouté la réplication. D1 a ajouté la couche périphérique. Litestream a ajouté la sauvegarde continue. Bun a supprimé la friction d'installation.

Le résultat est un moteur de base de données qui a fait ses preuves en production sur un trillion d'appareils, ne nécessite aucune infrastructure pour fonctionner, et a maintenant des réponses crédibles aux deux objections qui le disqualifiaient auparavant. La question n'est pas de savoir si SQLite peut gérer votre application — c'est de savoir si votre application a réellement besoin de ce que Postgres fournit.

Pour la plupart des applications, la réponse honnête est non.