SQLite est la base de données la plus déployée au monde — et presque personne n'en parle

Les bases de données qui attirent l'attention sont celles que vous exploitez : les clusters PostgreSQL, les répliques MySQL, les shards MongoDB, les services cloud managés d'AWS et Google. La base de données qui est présente dans plus d'endroits que toutes les autres réunies tourne en silence en arrière-plan, ne nécessite aucun administrateur, consomme moins de 1 Mo d'espace disque pour sa bibliothèque, et est un seul fichier source C que n'importe quel développeur peut lire en un après-midi.

SQLite est partout. C'est le moteur de stockage dans chaque application iOS et Android qui a besoin de données structurées. Elle est intégrée dans chaque navigateur de bureau — Chrome, Firefox, Safari et Edge utilisent tous SQLite pour l'historique, les marque-pages et les données en cache. C'est la base de données qui alimente le logiciel de gestion de vol sur les avions Airbus et Boeing. Elle est à l'intérieur des téléviseurs, des voitures, des routeurs et des dispositifs médicaux. Le projet SQLite estime à plus d'un billion les déploiements en usage actif — un nombre si grand qu'il est difficile à vérifier, mais aussi difficile à contester étant donné le nombre de piles logicielles qu'il soutient.

Le design qui le rend différent

Toute autre base de données SQL que vous avez probablement utilisée est un système client-serveur : la base de données s'exécute en tant que processus séparé, vous vous y connectez via un socket (local ou réseau), envoyez des requêtes et recevez des résultats. SQLite est sans serveur — le moteur de base de données entier est une bibliothèque qui s'exécute à l'intérieur du processus de votre application. Il n'y a pas de serveur à démarrer, pas de fichier de configuration à gérer, pas de système de permissions utilisateur, pas de port réseau à ouvrir. Vous liez la bibliothèque et vous avez une base de données SQL complète.

La base de données elle-même est un seul fichier sur le système de fichiers. C'est à la fois sa plus grande force et sa limitation clé. Déplacer une base de données SQLite est une copie de fichier. La sauvegarder est une copie de fichier. L'inspecter ne nécessite aucun outil spécial — SQLite Browser ou la CLI sqlite3 ouvriront n'importe quel fichier de base de données sur n'importe quel système d'exploitation. Quand votre application se termine, il n'y a rien à arrêter.

La limitation est la concurrence : SQLite utilise un verrouillage au niveau du fichier, ce qui signifie qu'un seul rédacteur peut modifier la base de données à la fois. Plusieurs lecteurs simultanés ne posent pas de problème ; plusieurs rédacteurs simultanés sont sérialisés. Pour les applications avec une forte concurrence d'écriture — les serveurs web à fort trafic gérant des requêtes simultanées — cette contrainte a son importance. Pour la grande majorité des applications, y compris la plupart des applications mobiles, des outils de bureau et des services web à trafic modéré, cela n'a pas d'importance.

Pourquoi SQLite est suffisamment fiable pour voler

La base de code de SQLite est l'un des logiciels les plus minutieusement testés qui existent. Le projet maintient environ 600 fois plus de code de test que de code de production — la bibliothèque elle-même compte environ 150 000 lignes de C ; la suite de tests compte environ 90 millions de lignes, incluant un fuzzer SQL complet, TH3 (un harnais de test commercial pour des tests rigoureux contre les cas limites), et des tests exhaustifs de récupération de corruption.

Le niveau de fiabilité est inhabituel pour un logiciel open source. D. Richard Hipp, le créateur de SQLite, l'a explicitement conçu pour être adapté aux systèmes critiques pour la sécurité aéronautique, et Airbus et d'autres l'ont certifié en conséquence. La base de données offre des garanties ACID — Atomicité, Cohérence, Isolation, Durabilité — via un système de journalisation anticipée (WAL). Un crash au milieu d'une transaction laisse la base de données dans un état connu et correct ; le WAL garantit que soit la transaction entière est validée, soit aucune ne l'est, même en cas de perte de courant inattendue.

Le plancher de performance surprenant

L'architecture sans serveur de SQLite signifie qu'elle évite les surcoûts des bases de données client-serveur : pas de sérialisation des données à envoyer via un socket, pas de changement de contexte entre les processus client et serveur, pas de planification de requêtes aux limites du réseau. Pour les charges de travail où les requêtes sont simples et la base de données de taille petite à moyenne, les performances de SQLite sont souvent comparables à PostgreSQL et parfois plus rapides.

L'équipe SQLite a effectué des benchmarks en 2022 montrant que pour une charge de travail à forte lecture (35 lectures pour chaque écriture), SQLite sur un SSD NVMe standard a traité 48 000 transactions par seconde contre 7 000 pour PostgreSQL — en grande partie parce que l'architecture intra-processus de SQLite élimine le surcoût de la communication inter-processus. Pour les charges de travail à forte écriture, le tableau est plus nuancé ; la gestion concurrente des écritures de PostgreSQL lui donne des avantages dans les scénarios de forte contention.

L'implication pratique : de nombreuses applications qui utilisent PostgreSQL par défaut parce qu'il est "de qualité production" fonctionneraient bien et seraient plus simples sur le plan opérationnel avec SQLite. Le service SQLite distribué D1 de Cloudflare et Turso's libSQL (un fork de SQLite avec support de réplication) construisent une infrastructure autour du pari que la simplicité de SQLite a été sous-évaluée dans les applications côté serveur.

SQLite moderne : pas la version de 2005

SQLite a considérablement évolué. Le support JSON ajouté en 2015 et étendu jusqu'en 2022 permet d'interroger et d'indexer des données JSON imbriquées avec la sémantique SQL complète — concurrentiel avec les bases de données documentaires pour de nombreux cas d'usage. L'extension Full-Text Search 5 (FTS5) fournit une recherche en texte intégral classée BM25 avec des requêtes de préfixe, sans nécessiter d'index de recherche séparé. L'extension R*Tree gère les requêtes de plage géospatiale. Les tables virtuelles permettent à SQLite d'interroger des sources de données externes (fichiers CSV, API distantes) avec la syntaxe SQL.

L'ajout le plus récent est l'extension de recherche de similarité vectorielle — sqlite-vss, construite sur la bibliothèque FAISS de Facebook — qui ajoute la recherche approximative du plus proche voisin à SQLite. Cela signifie qu'un seul fichier SQLite peut stocker des documents, leurs embeddings vectoriels, et effectuer une recherche de similarité sémantique, ce qui en fait une base de données RAG (génération augmentée de récupération) embarquée viable pour les applications d'IA locales. La combinaison de requêtes structurées, de recherche en texte intégral et de recherche vectorielle dans une seule base de données sans configuration est convaincante pour les applications qui nécessitaient auparavant trois systèmes distincts.

Quand ne pas utiliser SQLite

La réponse honnête à "devrais-je utiliser SQLite ?" nécessite de reconnaître ses véritables contraintes. Les charges de travail d'écriture à haute concurrence — pensez à une application web gérant des milliers de transactions simultanées — ont besoin de la concurrence multi-écrivains que PostgreSQL offre. Les ensembles de données substantiellement plus grands que la RAM disponible bénéficient de la gestion du pool de tampons et du planificateur de requêtes de PostgreSQL, qui est optimisé pour les scénarios de grandes données. Les applications nécessitant un contrôle d'accès fin (sécurité au niveau des lignes, permissions au niveau des colonnes) ont besoin d'une base de données basée sur un serveur.

Mais ce sont des contraintes qui affectent une minorité de déploiements. L'application web CRUD typique, l'application mobile, l'outil de bureau, le système embarqué et le script de pipeline de données sont tous bien servis par la simplicité de SQLite. Le conseil selon lequel SQLite "ne passe pas à l'échelle" ou "n'est pas prêt pour la production" est obsolète depuis une décennie — elle passe à l'échelle verticalement jusqu'à de très grandes tailles et alimente des applications de production de manière fiable depuis le début des années 2000. L'écart entre les capacités réelles de SQLite et sa réputation parmi les développeurs qui ne l'ont pas utilisée récemment est conséquent et mérite d'être corrigé.