Quand utiliser SQLite : cas d'usage et limites

La vraie question à se poser

SQLite, ce n'est pas une version allégée de Postgres. C'est un outil d'une autre nature. Toute la base de données tient dans un fichier sur le disque, et votre application discute avec elle via une bibliothèque liée au même processus — pas de serveur, pas de réseau, pas de comptes utilisateurs. Cette conception rend SQLite redoutable pour certains usages et carrément inadapté à d'autres.

La bonne question à se poser n'est presque jamais « est-ce que SQLite est assez rapide ? » (la réponse est oui, dans l'écrasante majorité des cas). C'est plutôt : « est-ce que la forme de mon application correspond à ce que SQLite sait bien faire ? » Deux critères tranchent en général : où vivent les données, et combien de processus écrivent dedans en même temps.

Quand utiliser SQLite : quand les données vivent avec l'app

SQLite brille quand la base appartient à une seule application qui tourne sur une seule machine. Le fichier est posé à côté de votre code, votre app l'ouvre directement, et voilà — c'est toute l'architecture.

-- Un schéma typique « les données vivent avec l'application » :
-- le stockage local d'une application de prise de notes pour ordinateur.
CREATE TABLE notes (
    id        INTEGER PRIMARY KEY,
    title     TEXT NOT NULL,
    body      TEXT,
    created   TEXT DEFAULT CURRENT_TIMESTAMP
);

INSERT INTO notes (title, body) VALUES
    ('Courses', 'lait, pain, café'),
    ('Idées',   'plan du tutoriel sqlite');

SELECT id, title, created FROM notes;

Ce mini schéma pourrait suffire à faire tourner tout le backend d'une vraie appli. Voici quelques cas où ce pattern tombe sous le sens :

• Applis desktop et mobiles. Toutes les applis iOS et Android qui ont besoin de stockage local structuré utilisent SQLite sous le capot. C'est aussi le cas de Firefox, Chrome et de la plupart des navigateurs.
• Outils en ligne de commande. git, les gestionnaires de paquets et les gestionnaires de dotfiles s'appuient tous sur des bases de données embarquées.
• Systèmes embarqués. Routeurs, voitures, avions — bref, tout ce qui doit embarquer une base en quelques centaines de kilo-octets.
• Suites de tests. Un fichier SQLite tout neuf (ou une base :memory:) par test, c'est plus rapide et mieux isolé que de lancer un Postgres à chaque fois.

Si vos données n'ont pas besoin d'être partagées entre plusieurs machines, SQLite est probablement la bonne réponse.

SQLite pour un site web orienté lecture

SQLite encaisse les lectures sans broncher. Beaucoup de lecteurs en parallèle, zéro contention, des temps de requête de l'ordre de la microseconde sur les recherches indexées. Si votre site sert surtout à lire du contenu — blogs, documentation, sites vitrines, petits dashboards SaaS — SQLite tiendra très bien la charge, souvent mieux qu'un Postgres distant puisqu'on évite l'aller-retour réseau.

-- Table des articles d'un blog.
CREATE TABLE posts (
    slug      TEXT PRIMARY KEY,
    title     TEXT NOT NULL,
    body      TEXT NOT NULL,
    published TEXT
);

CREATE INDEX idx_posts_published ON posts(published DESC);

INSERT INTO posts VALUES
    ('hello-world', 'Bonjour, le monde', 'Premier article.', '2024-01-01'),
    ('sqlite-rocks', 'Pourquoi SQLite',  'Base de données en un seul fichier.', '2024-02-15');

SELECT slug, title FROM posts ORDER BY published DESC LIMIT 10;

Le hic, ce sont les écritures. SQLite sérialise les écritures : un seul rédacteur peut détenir le verrou à la fois. Pour un blog avec quelques auteurs, ça passe complètement inaperçu. Pour une appli de chat où des milliers d'utilisateurs envoient des messages chaque seconde, ça devient un vrai problème.

Le mode WAL (write-ahead logging, qu'on verra plus loin) repousse nettement ce plafond en permettant aux lecteurs et au rédacteur de travailler en parallèle. Beaucoup de sites en production servent des millions de requêtes par jour avec SQLite + WAL.

SQLite pour les caches locaux et les données temporaires

Dès que vous avez besoin de stockage local structuré — un cran au-dessus d'un simple fichier JSON, mais sans aller jusqu'au serveur de base de données complet —, SQLite est difficile à battre.

-- Une table de cache pour un client HTTP.
CREATE TABLE http_cache (
    url        TEXT PRIMARY KEY,
    body       BLOB NOT NULL,
    expires_at INTEGER NOT NULL
);

INSERT INTO http_cache (url, body, expires_at)
    VALUES ('https://api.example.com/users/1', x'7b2269...', 1735689600);

DELETE FROM http_cache WHERE expires_at < strftime('%s', 'now');
SELECT count(*) FROM http_cache;

Les logs, les buffers d'analytics, le staging ETL, les feature stores pour le machine learning, les index d'IDE — tout ça, c'est le terrain de jeu naturel de SQLite. Le fichier est portable, on a tout SQL à disposition, et aucun serveur à materner.

Quand ne pas utiliser SQLite : les écritures concurrentes

C'est LA limite qui prend les gens au dépourvu. SQLite pose un verrou d'écriture au niveau de la base entière : un seul writer à la fois, point. Si deux processus tentent d'insérer au même instant, l'un des deux patiente.

Pour la majorité des applis, ça ne pose aucun souci — les écritures sont rares et rapides. En revanche, si votre charge de travail ressemble à ça :

• une SaaS multi-tenant avec des milliers d'utilisateurs qui écrivent en même temps,
• une file de messages ou un journal d'événements à fort débit,
• le backend d'un jeu temps réel ou d'un chat où l'état change en permanence,

alors SQLite va devenir votre goulot d'étranglement. PostgreSQL et MySQL, eux, utilisent un verrouillage au niveau de la ligne et ont été pensés précisément pour ces scénarios. C'est vers eux qu'il faut se tourner.

-- L'erreur que vous verrez lorsque les écrivains s'accumulent :
Error: database is locked

Si vous observez ça sous une charge normale, c'est que SQLite n'est pas le bon outil — ce n'est pas un bug à contourner.

Éviter SQLite sur plusieurs machines

SQLite est une bibliothèque embarquée dans le processus. L'application lit et écrit directement dans le fichier, ce qui veut dire que ce fichier doit se trouver sur un disque accessible via les appels système classiques read() et write().

Ça exclut donc :

• Plusieurs serveurs applicatifs derrière un load balancer, qui voudraient partager une seule base. (Les systèmes de fichiers réseau type NFS fonctionnent en théorie, mais corrompent le fichier sous charge. À proscrire.)
• Les fonctions serverless, où chaque invocation tourne sur une machine différente.
• Les pods Kubernetes qui veulent partager une base — sauf si vous déployez un seul pod avec un volume persistant.

Dès que votre architecture comporte plus d'un processus, sur plus d'une machine, qui écrivent dans la base, il te faut une base client-serveur. C'est la ligne à ne pas franchir.

Éviter SQLite quand vous avez besoin d'utilisateurs au niveau base

SQLite n'a aucune notion d'utilisateurs, de rôles ou de permissions. La base est un fichier : qui peut lire le fichier lit tout, qui peut l'écrire écrit tout. Le contrôle d'accès, c'est le boulot du système d'exploitation.

Pour une appli desktop mono-utilisateur, ça suffit largement. Pour un système multi-tenant où plusieurs personnes ont besoin de privilèges différents à l'intérieur de la base, il faut passer sur PostgreSQL ou MySQL.

Petite checklist de décision

Parcours cette liste. Si vous répondez « oui » à tout, SQLite est probablement un excellent choix :

• La base vit sur la même machine que l'application.
• Un seul processus (ou une poignée, surtout en lecture) discute avec elle.
• Le volume total tient confortablement sur un disque — plusieurs To, ça passe, mais ça reste un seul disque.
• Vous n'avez pas besoin de permissions utilisateurs au niveau de la base.
• Les écritures concurrentes sont occasionnelles, pas la charge dominante.

Si l'une des réponses est « non », regarde plutôt du côté de PostgreSQL ou MySQL. Les deux pages suivantes les comparent directement.

Ce qu'il faut retenir

• SQLite est le bon choix quand la base est locale à l'application : desktop, mobile, embarqué, outils CLI, suites de tests, sites à dominante lecture, caches locaux.
• C'est du niveau production — des milliards d'appareils l'embarquent. Les limites de SQLite sont d'ordre architectural, pas une question de qualité.
• À éviter dès que vous avez besoin de nombreuses écritures concurrentes, d'un accès multi-machines ou de permissions par utilisateur au niveau base.

La suite : installer SQLite

Assez de théorie. La page suivante détaille comment installer SQLite sur votre machine — il est déjà présent sur macOS et la plupart des distributions Linux, et il suffit d'un téléchargement sous Windows — puis comment vérifier l'installation en ligne de commande.