Back

Fonctionnalités modernes de SQLite que vous pourriez ignorer

Fonctionnalités modernes de SQLite que vous pourriez ignorer

Si vous considérez encore SQLite comme une base de données légère réservée aux applications mobiles ou aux prototypes rapides, vous avez manqué plusieurs années de développements significatifs. SQLite est activement maintenu, propose des capacités qui rivalisent avec celles de bases de données plus lourdes pour de nombreuses charges de travail, et fonctionne désormais directement dans le navigateur. Voici ce qu’il faut savoir.

Points clés à retenir

  • Le stockage JSONB offre un format binaire compact qui s’analyse plus rapidement que le JSON texte, et les expressions JSON peuvent être indexées directement.
  • Les tables STRICT apportent une véritable application des types à SQLite, comblant un écart de longue date avec des bases de données comme PostgreSQL.
  • La clause RETURNING élimine le besoin d’un SELECT de suivi après les opérations INSERT, UPDATE ou DELETE.
  • La build officielle SQLite WASM avec persistance OPFS fait des bases de données résidentes dans le navigateur un choix architectural pratique.
  • Le mode WAL améliore la concurrence lecture/écriture grâce à une simple instruction PRAGMA.

Support JSON et JSONB : bien plus qu’un simple stockage de texte

SQLite dispose de fonctions JSON depuis des années, mais un ajout plus récent est le support JSONB, un format binaire qui stocke les documents de manière plus compacte et les analyse plus rapidement que le JSON en texte brut.

Lorsque vous utilisez jsonb() pour stocker des données, SQLite évite de réanalyser le texte à chaque lecture. Pour les charges de travail à forte intensité de lecture avec des charges utiles JSON volumineuses, cela compte.

CREATE TABLE events (
  id      INTEGER PRIMARY KEY,
  payload BLOB NOT NULL  -- store as JSONB
);

-- Insert using jsonb()
INSERT INTO events (payload)
VALUES (jsonb('{"user": {"id": 42}, "action": "login"}'));

-- Query with standard json_extract — works on JSONB columns too
SELECT json_extract(payload, '$.user.id') AS user_id
FROM events
WHERE json_extract(payload, '$.action') = 'login';

Les fonctions JSON de SQLite acceptent de manière transparente à la fois les valeurs JSON texte et JSONB, vous pouvez donc continuer à utiliser des fonctions comme json_extract() indépendamment du format de stockage.

Vous pouvez également indexer directement les expressions JSON, ce qui rend le filtrage sur les champs imbriqués rapide sans dénormaliser votre schéma :

CREATE INDEX idx_action ON events (json_extract(payload, '$.action'));

Quand utiliser JSONB plutôt que TEXT : Utilisez BLOB + jsonb() lorsque SQLite doit fréquemment traiter ou interroger la valeur JSON. Utilisez TEXT lorsque vous avez besoin de conserver la chaîne brute exactement telle qu’insérée.

⚠️ Note de version : Le support de JSONB a été introduit dans SQLite 3.45 (janvier 2024). Confirmez la version de votre runtime avant de vous en remettre à cette fonctionnalité.

Tables STRICT de SQLite : une vraie application des types

Le typage flexible de SQLite est utile mais peut introduire des bugs subtils lorsqu’une colonne accepte silencieusement un type incorrect. Les tables STRICT corrigent cela en imposant les types de colonnes au moment de l’insertion, à la manière de PostgreSQL.

CREATE TABLE users (
  id        INTEGER PRIMARY KEY,
  email     TEXT    NOT NULL,
  age       INTEGER NOT NULL
) STRICT;

Essayez d’insérer 'twenty-five' dans age et SQLite le rejettera. Les tables STRICT prennent en charge cinq types de colonnes autorisés : INT, INTEGER, REAL, TEXT, BLOB, ainsi que le type spécial ANY. Le type ANY réinscrit cette colonne dans le comportement flexible normal de SQLite, ce qui permet de mélanger des colonnes strictes et flexibles dans la même table.

⚠️ Vérifiez d’abord votre version : Les tables STRICT nécessitent SQLite 3.37 ou une version ultérieure. Exécutez SELECT sqlite_version(); pour confirmer.

La clause RETURNING : des requêtes de mutation plus propres

Si vous avez déjà inséré une ligne et l’avez immédiatement interrogée pour obtenir l’ID généré, RETURNING élimine cet aller-retour :

INSERT INTO orders (user_id, total)
VALUES (42, 99.99)
RETURNING id, created_at;

Cela fonctionne avec INSERT, UPDATE et DELETE, et c’est particulièrement utile en JavaScript côté serveur avec des bibliothèques comme better-sqlite3 ou le SQLite intégré de Bun. RETURNING a été ajouté dans SQLite 3.35.

SQLite WASM : exécuter SQLite directement dans le navigateur

Le projet SQLite propose une build WebAssembly officielle qui exécute le moteur SQLite complet dans un onglet de navigateur. Contrairement à sql.js, qui l’a précédée, la build officielle SQLite WASM prend en charge l’API Origin Private File System (OPFS) pour un stockage persistant basé sur des fichiers, ce qui signifie que votre base de données survit aux rafraîchissements de page sans serveur.

Cela ouvre la voie à une véritable architecture pour le développement frontend SQLite :

  • Applications offline-first qui interrogent localement et synchronisent ultérieurement
  • Outils d’analyse ou de reporting côté client
  • Applications Electron et Tauri souhaitant une abstraction unique de base de données entre les environnements
  • Outils de développement basés sur le navigateur dotés de véritables capacités de requêtage

OPFS est documenté par MDN dans le cadre de l’API File System, et le guide web.dev de Google indique qu’il est pris en charge par tous les principaux navigateurs. Certaines configurations SQLite WASM basées sur OPFS nécessitent également un contexte sécurisé (HTTPS), le support de SharedArrayBuffer, et des en-têtes COOP/COEP appropriés selon l’implémentation VFS choisie.

Mode WAL : une meilleure concurrence sans surcharge de configuration

Le journal en écriture anticipée (write-ahead logging) permet aux lecteurs et aux rédacteurs de travailler simultanément sans se bloquer mutuellement. Pour les applications avec des lectures et écritures concurrentes, ou lorsque la latence perçue compte, le mode WAL vaut souvent la peine d’être activé :

PRAGMA journal_mode = WAL;

Ce simple pragma peut améliorer significativement les performances des applications local-first, des applications Electron et des services backend légers où SQLite gère un trafic réel. Notez que le mode WAL nécessite que le fichier de base de données réside sur un disque local, car il ne fonctionne pas de manière fiable sur des systèmes de fichiers réseau.

Conclusion

Les fonctionnalités modernes de SQLite comme JSONB, les tables STRICT, RETURNING, WASM avec OPFS et le mode WAL font collectivement de SQLite un choix crédible pour un éventail d’applications bien plus large que sa réputation ne le laisse penser. Le projet est activement développé, et l’écart entre SQLite et les bases de données plus lourdes s’est considérablement réduit pour les charges de travail qui ne nécessitent pas une concurrence multi-rédacteurs à grande échelle. Si vous n’avez pas réexaminé récemment ce que SQLite peut faire, c’est le bon moment.

FAQ

Oui, pour de nombreuses charges de travail. SQLite gère bien le trafic à forte intensité de lecture et les volumes d'écriture petits à moyens, en particulier avec le mode WAL activé. Il fonctionne mieux pour les déploiements sur un seul serveur ou les applications local-first. Pour les applications nécessitant plusieurs rédacteurs concurrents répartis sur des serveurs distribués, une base de données client-serveur comme PostgreSQL reste mieux adaptée.

Choisissez JSONB lorsque SQLite doit fréquemment traiter ou interroger la valeur JSON, car cela évite la réanalyse à chaque lecture et stocke les données de manière plus compacte. Restez sur TEXT lorsque vous devez préserver la chaîne d'origine exactement telle qu'écrite, y compris les espaces et l'ordre des clés, ce qui importe pour les signatures cryptographiques ou les journaux d'audit.

Non. STRICT est optionnel par table, donc les tables existantes continuent à utiliser le typage flexible de SQLite. Vous pouvez introduire des tables STRICT dans de nouveaux schémas ou migrer progressivement des tables spécifiques. Confirmez simplement que vous exécutez SQLite 3.37 ou une version ultérieure avant d'ajouter le mot-clé STRICT à toute instruction CREATE TABLE.

Les performances sont proches mais pas identiques. La build WASM s'exécute plus lentement que SQLite natif en raison de la surcharge de WebAssembly et de l'accès aux fichiers OPFS qui est moins direct que les E/S disque natives. Pour de nombreuses charges de travail modestes côté client, la différence est acceptable, mais les grands ensembles de données et les requêtes analytiques lourdes peuvent encore montrer des ralentissements notables.

Complete picture for complete understanding

Capture every clue your frontend is leaving so you can instantly get to the root cause of any issue with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data.

Check our GitHub repo and join the thousands of developers in our community.

OpenReplay