Qu'est-ce que SQLite

SQLite tourne sur votre téléphone, dans votre navigateur, dans vos applications de bureau — et presque personne qui l’utilise ne sait qu’il est là. C’est précisément le but.

Cet article explique ce qu’est SQLite, pourquoi le choisir plutôt qu’une base de données serveur, et ce que les projets NoSQL du créateur ont apporté ou non. Pour ceux qui envisagent d’utiliser SQLite, ou qui veulent simplement comprendre ce qu’il y a sous le capot.

Prérequis

• SQLite 3.x — la version qui est la norme depuis 2004. La version actuelle est la 3.53.x.
• L’outil en ligne de commande `sqlite3`. Sur Debian/Ubuntu, vous l’installez avec `sudo apt install sqlite3`.
• Des connaissances de base en SQL. Ceux qui n’ont jamais vu de tables ni de requêtes lisent d’abord une introduction ailleurs.

Ce qu’est SQLite

SQLite est un moteur de base de données relationnelle qui ne fait pas tourner de serveur. Pas de processus séparé, pas de port réseau, pas de dossier de configuration. Toute la base de données est un seul fichier sur le disque, et votre application lui parle directement via une bibliothèque intégrée.

Cela diffère fondamentalement de MySQL ou PostgreSQL. Ceux-ci tournent comme des processus serveur autonomes auxquels vos applications clientes se connectent. SQLite n’est pas un système client-serveur — c’est une bibliothèque que vous liez à votre programme. Le moteur de base de données tourne dans le même processus que votre application.

L’origine remonte à D. Richard Hipp, qui a conçu le moteur au printemps 2000 alors qu’il travaillait sous contrat pour la United States Navy. La première version, SQLite 1.0, est sortie le 17 août 2000 comme extension pour le langage de script Tcl. La première version de la ligne 3.x a suivi le 18 juin 2004 avec un format de fichier révisé, un meilleur support d’Unicode et un stockage plus efficace. Depuis lors, 3.x est la seule version qui compte encore.

Il est écrit en C et tourne sur pratiquement toutes les plateformes — des microcontrôleurs aux serveurs. Vous n’avez rien à installer ni à configurer. Vous liez la bibliothèque et vous avez une base de données SQL fonctionnelle.

Pourquoi vous voudriez SQLite

Le grand avantage, c’est l’absence de gestion. Pas de serveur de base de données à faire tourner, pas de comptes utilisateurs, pas de configuration réseau, pas de procédure de sauvegarde pour un service séparé. La base de données est un seul fichier. Copiez ce fichier et vous avez une sauvegarde. Déplacez-le et vous avez déplacé votre base de données.

Cela fait de SQLite le bon choix pour le stockage local : applications de bureau, applications mobiles, systèmes embarqués, outils de développement. Partout où un seul processus a besoin d’accéder aux données à la fois, et où vous ne voulez pas maintenir un serveur.

Ce n’est pas le bon choix pour les applications web avec beaucoup d’écritures simultanées. SQLite supporte bien plusieurs lecteurs à la fois, mais l’écriture est verrouillée globalement — un seul écrivain à la fois. Pour une application web chargée avec beaucoup d’écritures concurrentes, il vous faut une base de données serveur. Pour une application de bureau mono-utilisateur, SQLite est plus rapide et plus simple que n’importe quelle base de données serveur.

Une règle empirique souvent entendue : si votre application tourne sur une seule machine et qu’un seul processus utilise la base de données, SQLite est souvent le meilleur choix. Si plusieurs machines ou processus doivent écrire en même temps, alors non.

Travailler avec sqlite3

L’outil `sqlite3` vous donne une session interactive. Ouvrez ou créez une base de données avec :

sqlite3 mydata.db

Cette commande crée `mydata.db` si le fichier n’existe pas encore, et l’ouvre sinon. Vous êtes maintenant dans une session SQL. Créez une table et ajoutez des données :

CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT NOT NULL);
INSERT INTO users (name) VALUES ('alice'), ('bob');
SELECT * FROM users;

Pas de serveur qui tourne, pas de chaîne de connexion, pas de port. Le fichier est la base de données.

Vous pouvez aussi exécuter directement une requête sans session interactive :

sqlite3 mydata.db "SELECT * FROM users;"

C’est pratique pour les scripts et les cronjobs.

ACID sans serveur

SQLite supporte le cœur de SQL : tables, index, transactions, déclencheurs, vues. Et il garantit ACID — atomicité, cohérence, isolation et durabilité. Même si le courant coupe au milieu d’une transaction, la base de données reste cohérente. C’est intégré dans le moteur lui-même, pas dépendant d’un serveur qui serait arrêté proprement.

Cette fiabilité est la raison pour laquelle SQLite se trouve dans des logiciels financiers et médicaux. Un exemple : AloxBook, une application de bureau Linux pour la comptabilité financière personnelle, stocke tout dans SQLite. Sans mot de passe, le livre est un fichier SQLite non chiffré. Avec mot de passe, AloxBook utilise SQLCipher — une variante chiffrée de SQLite avec chiffrement AES-256. Le même moteur, deux niveaux de sécurité.

Utilitaires

En plus de `sqlite3`, SQLite fournit `sqldiff`. Celui-ci montre les différences entre deux bases de données SQLite et génère un script SQL qui transforme une base de données en l’autre. Pratique pour les migrations ou pour vérifier les changements entre environnements de développement et de production.

sqldiff --changeset file1.db file2.db

Les projets NoSQL qui ne sont pas devenus réalité

En 2011, D. Richard Hipp a annoncé une interface NoSQL pour SQLite. En même temps, il a introduit UnQL, un sur-ensemble fonctionnel de SQL pour les bases de données orientées documents. Le contexte était clair : les bases de données NoSQL comme MongoDB et CouchDB gagnaient du terrain, et celles-ci conviennent mieux aux données semi-structurées ou hiérarchiques qu’un modèle relationnel rigide.

Il est important de souligner ce qui ne s’est pas produit. SQLite n’est pas devenu une base de données NoSQL. Rien ne prouve que l’interface NoSQL annoncée ait jamais été entièrement implémentée ou publiée dans la base de code officielle. UnQL est resté un concept. Les sources évoquent des plans et des idées, pas une version NoSQL fonctionnelle.

Ce qui est bien arrivé : l’extension `json1`. Elle permet de stocker, rechercher et manipuler des données JSON dans le contexte relationnel de SQLite. Au lieu de construire un moteur NoSQL, SQLite a intégré des fonctionnalités documentaires dans le modèle relationnel.

Un exemple d’utilisation de JSON dans SQLite :

CREATE TABLE events (id INTEGER PRIMARY KEY, payload JSON);
INSERT INTO events (payload) VALUES ('{"type": "click", "page": "/home"}');
SELECT payload ->> '$.type' FROM events WHERE payload ->> '$.page' = '/home';

Vous obtenez la flexibilité des documents sans renoncer aux fondations relationnelles. Cela a toutefois un coût : vous perdez la possibilité d’indexer les champs JSON imbriqués comme vous le feriez sur des colonnes. Ceux qui exécutent beaucoup de requêtes sur des champs JSON le remarquent.

Maintenance et outils

SQLite n’est pas un projet endormi. Les versions sont publiquement datées et paraissent régulièrement. La version 3.53.0 date du 9 avril 2026, la 3.53.1 du 5 mai 2026, la 3.53.2 du 3 juin 2026 et la 3.53.4 du 24 juillet 2026. Les développeurs continuent d’améliorer le moteur, même si de l’extérieur, tout semble souvent identique.

Pour ceux qui ne veulent pas travailler en ligne de commande, il existe des outils graphiques. Air SQLite Manager, développé par gesturedevelop, permet de parcourir les tables, modifier les lignes et exécuter des requêtes sans terminal. Il est disponible via Flatpak, ce qui simplifie l’installation sur diverses distributions Linux :

flatpak install flathub io.github.gesturedevelop.AirSQLiteManager

Ces outils abaissent la barrière d’entrée, mais ils ne changent rien à ce qu’est SQLite : une base de données embarquée qui n’a pas besoin de serveur.

Vérification

Vérifiez que SQLite fonctionne correctement et quelle version vous avez :

sqlite3 --version

Cela affiche le numéro de version, par exemple `3.53.4 2026-07-24`. Vous savez ainsi avec certitude que l’outil est installé et quelles fonctionnalités sont à votre disposition.

Problèmes fréquents

Base de données verrouillée (database is locked)

SQLite n’autorise qu’un seul rédacteur à la fois. Si un autre processus tient la base pour une écriture, vous obtenez cette erreur. Solution : veillez à ce que votre application garde des transactions courtes, utilisez `busy_timeout` pour attendre une libération, ou repensez l’usage de SQLite si vous prévoyez beaucoup d’écritures concurrentes.

Fichier de base de données corrompu après un crash

SQLite est conçu pour survivre aux crashes, mais une base sur un disque défectueux ou une copie interrompue peut être endommagée. Vérifiez avec :

sqlite3 mydata.db "PRAGMA integrity_check;"

Cette commande renvoie `ok` si la base est intacte. En cas de dommage, vous pouvez souvent récupérer les données avec `.dump` et reconstruire une nouvelle base — mais cela ne fonctionne que si les dégâts sont limités.

Les requêtes JSON ne fonctionnent pas

L’extension `json1` est activée par défaut dans la plupart des builds de SQLite, mais pas dans tous. Vérifiez avec :

sqlite3 mydata.db "SELECT json_valid('{}');"

Si cela renvoie `1`, l’extension est disponible. Si cela renvoie une erreur, vous devez utiliser un build avec `json1` activé.

Le choix entre SQLite et une base de données serveur n’est pas une question de mieux ou de moins bien. C’est la question de savoir si vous voulez gérer un serveur. SQLite vous permet d’éviter cette question — jusqu’au moment où votre application grandit et où vous avez finalement besoin d’un serveur. D’ici là, vous aurez un fichier de base de données que vous pourrez exporter directement vers PostgreSQL ou MySQL. Ce n’est pas un hasard, c’est une conception.