SQLite : une base de données embarquée dans votre programme
La plupart des bases de données dont vous avez entendu parler — MySQL, Postgres, SQL Server — tournent comme un programme à part. Vous démarrez un serveur, il écoute sur un port, et votre application s'y connecte via le réseau pour lui poser ses questions. SQLite, lui, balaie complètement ce modèle.
SQLite est une bibliothèque. Vous la liez à votre programme, et vous obtenez une base de données SQL qui tient dans un seul fichier sur le disque. Pas de serveur, pas de port, pas de démon, pas de pg_ctl start. Votre application ouvre un fichier, et ce fichier est la base de données.
sqlite3 mydata.db
Cette commande ouvre (ou crée) un fichier nommé mydata.db et vous donne un prompt SQL. Tout ce que vous faites — tables, lignes, index — se retrouve stocké dans ce seul fichier. Copiez-le sur une autre machine et la base de données suit. Supprimez-le et la base disparaît avec.
Petit tour d'horizon du SQL
Le SQL en lui-même ressemble à n'importe quel autre dialecte SQL. Si vous avez déjà touché à une autre base de données, vous serez en terrain connu sur la quasi-totalité des points :
SQL standard — CREATE TABLE, INSERT, SELECT, ORDER BY. SQLite couvre les morceaux du standard SQL dont on se sert vraiment au quotidien, avec en bonus quelques fonctionnalités modernes comme les CTE, les window functions et les fonctions JSON. Les différences avec Postgres ou MySQL tournent surtout autour des types et de quelques bizarreries de syntaxe — on y reviendra plus tard.
SQLite base embarquée et sans serveur : ça veut dire quoi ?
Deux mots reviennent en boucle quand on parle de SQLite. Autant les clarifier tout de suite.
Embarquée veut dire que SQLite tourne dans le même processus que votre application. Aucun processus séparé pour la base de données. Quand votre script Python appelle sqlite3.connect("data.db"), le moteur SQL tourne à l'intérieur de votre processus Python et lit/écrit directement dans le fichier.
Sans serveur veut dire qu'il n'y a aucun serveur à installer, configurer, lancer, sécuriser ou sauvegarder. Comparez ce qu'il faut faire pour commencer à utiliser une base de données :
- Postgres : installer Postgres, démarrer le service, créer un utilisateur, créer une base, configurer
pg_hba.conf, se connecter en TCP. - SQLite : ouvrir un fichier.
Voilà toute la différence. Moins puissant, mais beaucoup moins de tralala.
Toute la base tient dans un seul fichier
C'est le détail qui surprend tout le monde. Le format de fichier est documenté et stable — un fichier .db (ou .sqlite, ou .sqlite3, l'extension n'est qu'une convention) que vous pouvez :
- Envoyer par mail à un collègue.
- Versionner dans git (les petits, du moins).
- Copier avec
cppour une sauvegarde instantanée. - Ouvrir avec n'importe quel outil SQLite, sur n'importe quel OS.
ls -lh mydata.db
# -rw-r--r-- 1 you staff 28K 23 avr. 14:02 mydata.db
Ce fichier unique contient vos tables, vos index, votre schéma et vos données. Sur disque, une base SQLite est identique octet pour octet sous Windows, macOS, Linux, iOS et Android. Le format est tellement stable que la Bibliothèque du Congrès américaine le recommande pour la conservation des données sur le long terme.
SQLite, vous l'utilisez déjà partout
Il y a quasi certainement des centaines de bases SQLite sur l'appareil avec lequel vous lisez ces lignes. SQLite fait tourner :
- Le stockage système d'iOS et Android, ainsi que de nombreuses applis sur ces deux plateformes.
- Firefox, Chrome et Safari (historique, marque-pages, cookies).
- macOS (Mail, Photos, le dock).
- La plupart des applis de bureau Linux qui ont besoin d'un stockage local.
- Skype, WhatsApp, Signal — l'historique des conversations.
- Les catalogues Adobe Lightroom, les métadonnées de Dropbox, les bibliothèques Steam.
On dit souvent que c'est le moteur de base de données le plus déployé au monde, et c'est sans doute vrai. La raison est simple : dès qu'une application a besoin d'un stockage local structuré, SQLite est la solution la plus directe.
Ce que SQLite n'est pas
Ce n'est pas une base client-serveur. Deux programmes tournant sur des machines différentes ne peuvent pas se connecter à la même base SQLite via le réseau — il n'y a tout simplement pas de couche réseau à laquelle se connecter. Si c'est ce qu'il vous faut, tournez-vous vers Postgres ou MySQL.
Ce n'est pas conçu pour encaisser une forte concurrence en écriture. SQLite verrouille au niveau du fichier (avec quelques optimisations astucieuses en mode WAL) : plusieurs lecteurs peuvent donc travailler en parallèle, mais un seul écrivain à la fois peut valider une transaction. Pour une appli mono-utilisateur ou un site à faible trafic, ce n'est pas un souci. Pour un SaaS multi-tenant qui encaisse des milliers d'écritures par seconde, c'est clairement le mauvais outil.
SQLite ne gère ni utilisateurs ni permissions. L'accès à la base, c'est l'accès au fichier — quiconque peut lire le fichier peut lire les données. C'est très bien pour une appli qui possède son propre fichier de base. C'est moins bien pour un environnement partagé multi-tenant.
Les avantages de SQLite, et pourquoi le choisir
Le compromis ? Vous gagnez en simplicité contre une marge de mise à l'échelle dont vous n'aurez peut-être jamais besoin :
- Zéro configuration. Aucun service à lancer. Aucun écart de version entre dev et prod. Pas de « la base est down » puisqu'il n'y a aucun serveur de base de données.
- Rapide. Pour la plupart des charges, surtout celles à dominante lecture, SQLite est plus rapide qu'une base accessible via le réseau — pas d'aller-retour réseau à chaque requête.
- Fiable. Le projet est testé de façon quasi obsessionnelle. SQLite contient bien plus de code de test que de code source, et le format est stable depuis 2004.
- Domaine public. Libre pour tout usage, y compris commercial. Aucune licence à éplucher.
- Portable. Un seul fichier, toutes les plateformes.
Pour les applis locales, les prototypes, les systèmes embarqués, les outils en ligne de commande, les suites de tests, les scripts d'analyse de données et les sites de taille petite à moyenne, SQLite est souvent le choix par défaut correct — pas un tremplin vers une « vraie » base de données.
La suite : SQLite vs MySQL
La question qui vient naturellement, c'est de savoir comment SQLite se compare aux serveurs de bases de données dont vous avez sans doute davantage entendu parler. On commence par MySQL — les points forts de chacun, et comment trancher selon le projet que vous avez devant vous.
Questions fréquentes
C'est quoi SQLite, concrètement ?
SQLite est un moteur de base de données SQL qui tourne comme une bibliothèque à l'intérieur de votre application, au lieu de fonctionner comme un serveur séparé. Toute la base — tables, index, schéma, données — tient dans un seul fichier sur le disque. On dialogue avec elle via une bibliothèque C (ou un binding pour votre langage) en SQL classique.
À quoi sert SQLite ?
Partout où vous avez besoin d'une vraie base SQL sans avoir à lancer un serveur : applications mobiles (iOS et Android l'embarquent nativement), applis desktop, navigateurs, objets connectés, petits sites web, caches locaux, suites de tests, scripts d'analyse… Si vos données tiennent sur une seule machine et qu'un seul processus écrit à la fois, SQLite fait généralement le job.
SQLite, c'est une vraie base de données ?
Oui, sans hésiter. Elle gère les transactions, les garanties ACID, les clés étrangères, les jointures, les sous-requêtes, les fonctions de fenêtrage, les CTE, les triggers, les vues et même le JSON. Il lui manque certaines choses qu'on trouve dans une base serveur — l'accès réseau, l'écriture concurrente multi-utilisateurs, la gestion des comptes — parce que ce n'est tout simplement pas son rôle. Pour une appli mono-processus, elle est aussi « vraie » que PostgreSQL.
SQLite est-il gratuit ?
Oui. SQLite est dans le domaine public, ce qui est encore plus permissif que l'open source. Vous pouvez l'utiliser dans des produits commerciaux, le modifier et le distribuer sans attribution ni redevance. C'est d'ailleurs pour ça qu'il fait partie des logiciels les plus déployés au monde.
