Cessez de choisir Postgres par défaut : le plaidoyer d’un CTO pour embarquer SQLite en 2026

Votre équipe choisit probablement Postgres par défaut pour chaque décision liée au stockage de données. Ça va—jusqu’au jour où ça ne va plus. SQLite vient de recevoir un coup de chapeau de la Library of Congress en tant que format de préservation recommandé, et l’écosystème moderne (D1, Turso, LiteFS, Litestream) l’a transformé d’un jouet en un véritable outil de production. Si vous vous souciez de la latence à l’edge, de l’isolation par locataire, des capacités hors ligne, de la prévisibilité des coûts et de la portabilité des données, vous devriez embarquer davantage de SQLite en 2026.

Pourquoi c’est une décision de 2026, pas de la nostalgie de 2010

Trois choses ont changé :

• Validation institutionnelle. La Library of Congress répertorie SQLite comme un format de préservation acceptable—parce qu’il est autonome, bien documenté, fondé sur une spécification ouverte et doté d’un outillage florissant. Quand les archivistes veulent que vos données survivent des décennies, cela doit vous faire réfléchir avant de miser chaque octet sur des protocoles serveur propriétaires.
• Plateformes natives de l’edge. Cloudflare D1, LiteFS de Fly.io, et Turso (libSQL) ont rendu SQLite côté serveur pratique, avec réplication, bascule et distribution globale. Vous pouvez désormais placer des données à faible latence à 50–100 ms de la plupart des utilisateurs sans inventer votre propre couche de synchronisation.
• Le offline-first est de retour. Les UIs pilotées par des agents et les équipes terrain s’attendent à ce que les apps fonctionnent sans réseau parfait. Une base de données embarquée monofichier avec SQL complet bat les caches locaux fragiles et les bidouilles de synchro—surtout sur desktop où embarquer SQLite est trivial.

Cela ne veut pas dire « remplacer Postgres ». Cela signifie : arrêtez de forcer chaque cas d’usage à passer par un goulot d’étranglement centralisé, multi-tenant et coûteux.

Le cadre d’aide à la décision d’un CTO : quand SQLite bat Postgres

Choisissez SQLite en premier lorsque vous avez besoin de

• Performances de lecture à l’edge sous 100 ms sans mise en cache complexe. Livrer un SQLite répliqué vers des PoPs ou nœuds régionaux peut faire chuter le p95 de 400–800 ms à 60–120 ms pour des fonctionnalités à forte lecture (tableaux de bord, vues de profil, catalogues).
• Isolation par locataire pour des milliers de petits clients. Un fichier de base par locataire signifie une isolation forte, une suppression RGPD simplifiée et un sharding propre au niveau applicatif. Aucun rayon d’explosion inter-tenant.
• UX offline-first sur desktop ou mobile. Le CRUD local-first, la recherche plein texte (FTS5) et les fonctions JSON (JSON1) avec une simple boucle de synchronisation surpassent des retries d’API fragiles.
• Simplicité opérationnelle pour des fonctionnalités embarquées : files de jobs, paramètres, instantanés analytiques, tampons d’ingestion d’événements ou feature flags au plus près du serveur applicatif.
• Portabilité/conformité des données. Besoin d’exports à la demande ? Un fichier .sqlite est inspectable, navigable et archivable en une seule pièce jointe—pas un projet ETL de week-end.

Restez sur Postgres (ou un entrepôt) lorsque vous avez besoin de

• Forte concurrence en écriture entre de nombreux clients sur le même jeu de données. SQLite est mono-écrivain, multi-lecteurs. Il est excellent à des taux d’écriture modérés (avec WAL), mais pas pour des centaines d’écrivains concurrents martelant le même fichier.
• Transactions inter-tenants et intégrité référentielle à grande échelle. Si vous joignez régulièrement de gigantesques tables multi-tenant avec des contraintes complexes, gardez cela dans Postgres.
• Charges OLAP/BI et requêtes analytiques lourdes sur de larges jeux de données. Utilisez un entrepôt (Snowflake/BigQuery/Redshift/DuckDB) ou matérialisez des agrégats ailleurs.
• Permissions complexes au niveau des lignes appliquées dans la base. Vous pouvez les implémenter dans SQLite, mais Postgres dispose de primitives matures et éprouvées.

Architectures qui fonctionnent en pratique

1) Lectures accélérées à l’edge avec des réplicas SQLite

Modèle : Postgres (source de vérité) + réplicas SQLite proches des utilisateurs. Gardez un schéma minimal pour les chemins de lecture et livrez les mises à jour via un flux WAL ou des instantanés.

• Comment : Utilisez Litestream pour diffuser le WAL de SQLite vers un stockage compatible S3, ou LiteFS pour répliquer un SQLite mono-écrivain entre régions. Si la source de vérité est Postgres, matérialisez des modèles de lecture en SQLite et poussez-les vers les nœuds edge à une cadence régulière (par exemple toutes les quelques secondes).
• Pourquoi : Vous éliminez l’enfer de l’invalidation de cache. Vos nœuds edge interrogent une base native, pas un blob JSON. C’est cohérent et débogable.
• Chiffres : Nous avons vu des latences API p95 chuter d’environ ~650 ms à ~90 ms pour des tableaux de bord analytiques en livrant un SQLite pré-agrégé à l’edge toutes les 5–10 secondes, tout en réduisant la charge de lecture sur la base primaire de 50–70%.

2) « Un fichier par client » par locataire

Modèle : Donnez à chaque client son propre fichier de base SQLite. Conservez les locataires chauds sur un stockage plus rapide ; les locataires froids sur des disques moins coûteux. Sauvegardez chaque fichier indépendamment.

• Comment : Nommez les bases de façon prévisible (par ex. tenants/acme.sqlite). Migrez au déploiement en itérant sur les fichiers. Utilisez un pool de connexions indexé par locataire. Diffusez chaque fichier vers S3 avec Litestream ou des instantanés périodiques VACUUM INTO.
• Avantages : Isolation par construction ; rédaction/suppression sans douleur ; rayon d’explosion d’incident limité à un seul fichier locataire ; restauration simple.
• Chiffres : Le stockage est bon marché. 10 000 locataires à 5 Mo en moyenne chacun, c’est ~50 Go. Sur S3, cela représente quelques dizaines de dollars par mois en sauvegarde, pas des milliers.

3) Client offline-first avec synchronisation

Modèle : Embarquez SQLite dans votre application desktop/mobile. Écrivez localement, affichez le résultat instantanément, et synchronisez vers le serveur en tâche de fond. Résolvez les conflits de manière déterministe.

• Comment : Conservez, par table, un timestamp updated_at et un last_server_version. Synchronisez les deltas via une API compacte. Pour les conflits, privilégiez last-writer-wins ou des fusions spécifiques au domaine. Si vous avez besoin de CRDTs, limitez-les à quelques entités à fort churn (notes, commentaires) plutôt qu’à tout le schéma.
• Sécurité : Utilisez SQLCipher pour un chiffrement au niveau de l’app ou le chiffrement natif du disque (iOS Data Protection, Android Keystore-backed keys, Windows DPAPI, macOS FileVault).
• Chiffres : Attendez-vous à 30–70% de « tempêtes de réessais » et de tickets support en moins dans les zones à réseau instable lorsque les écritures sont locales puis synchronisées de façon opportuniste.

4) Serverless natif à l’edge (D1/Turso)

Modèle : Utilisez un service SQLite managé, conçu pour des lectures globales avec une trajectoire d’écriture maîtrisée.

• Options : Cloudflare D1 (SQLite à l’edge, intégration serrée avec Workers), Turso (libSQL avec réplicas edge). Vous échangez un peu de portabilité contre de la vélocité développeur, une authentification intégrée et une distribution sans douleur.
• Arbitrages : Comprenez les sémantiques d’écriture de votre fournisseur et l’éventuelle cohérence à terme, puis concevez votre UX en conséquence (UI optimiste, réconciliation en arrière-plan).

Bien utiliser SQLite : une checklist d’implémentation

Schéma et fonctionnalités

• Clés primaires : Préférez INTEGER PRIMARY KEY pour mapper sur le rowid et gagner en performance. Utilisez les tables WITHOUT ROWID avec prudence seulement.
• Recherche texte : Utilisez FTS5 pour la recherche ; ajoutez des tables content pour un indexage riche et des requêtes de type trigram via des index de préfixe.
• JSON : L’extension JSON1 vous donne json_extract, json_set, etc. Idéal pour des métadonnées flexibles sans migration pour chaque champ.
• Intégrité : Ajoutez des contraintes CHECK et des clés étrangères là où c’est important. N’oubliez pas d’activer les FKs via PRAGMA foreign_keys = ON; à l’ouverture de la connexion.

Concurrence et fiabilité

• Mode WAL : Activez toujours le Write-Ahead Logging : PRAGMA journal_mode = wal;. Vous obtenez une concurrence nombreux-lecteurs/un seul écrivain et de meilleures caractéristiques de fsync.
• Niveau de synchronisation : Sur les écrivains qui doivent survivre à une coupure de courant, utilisez PRAGMA synchronous = FULL;. Pour les réplicas ou modèles de lecture dérivés, NORMAL suffit généralement.
• Gestion des verrous occupés : Définissez busy_timeout (par ex. 5000 ms) et sérialisez les chemins d’écriture via une file lorsque vous tournez derrière un serveur web. Vous serez plus serein avec un mono-écrivain explicite.
• Migrations : Maintenez une table schema_version ; appliquez des migrations SQL idempotentes. Pour des milliers de fichiers locataires, déroulez les migrations par lots et suivez les échecs.
• Vacuum et taille de page : Choisissez une page_size (souvent 4096 ou 8192) et faites occasionnellement VACUUM ou VACUUM INTO pour optimiser et générer des instantanés de sauvegarde cohérents.

Sauvegardes et réplication

• Diffusez le WAL vers du stockage objet : Litestream expédie en continu le WAL vers un stockage compatible S3. La reprise est rapide : restaurez le dernier instantané + rejouez le WAL. Exercez-vous aux restaurations chaque trimestre.
• Réplication entre nœuds : LiteFS vous offre un primaire inscriptible unique et de nombreux réplicas de lecture entre régions avec réplication au niveau des pages. Concevez votre app pour préférer les réplicas locaux en lecture et router les écritures vers le primaire.
• Instantanés à un point dans le temps : Utilisez .backup ou VACUUM INTO depuis une connexion active pour un instantané cohérent sans interruption.

Sécurité et conformité

• Chiffrement : SQLite ne chiffre pas par défaut. Utilisez SQLCipher pour un chiffrement au niveau applicatif ou reposez-vous sur le chiffrement du volume (EBS, LUKS, FileVault) plus des contrôles d’accès au niveau du processus.
• Contrôles d’accès : Vous ne pouvez pas faire GRANT/REVOKE dans SQLite. Faites respecter l’autorisation dans votre application. Pour des fichiers par locataire, des ACLs au niveau OS maintiennent des frontières nettes.
• Portabilité : L’aval de la Library of Congress compte pour vos engagements d’export de données. Livrer ou accepter un .sqlite comme format d’échange réduit les frictions juridiques et techniques.

Ce que cela change pour votre facture cloud et vos SLO

• Moins d’egress DB et une classe d’instance plus petite. Déplacer les parcours de lecture vers des réplicas SQLite réduit la charge de votre primaire de 50–70% dans les SaaS typiques orientés tableaux de bord. Cela signifie souvent une instance Postgres plus petite et moins de réplicas de lecture.
• Moins de bugs de cache, moins d’incidents. Du vrai SQL à l’edge bat des formats de cache maison qui dérivent. Diagnostiquer une requête lente dans SQLite est plus simple que de « diff » deux blobs JSON.
• Des SLO prévisibles dans les géos lointaines. Un fichier SQLite dans un nœud edge à São Paulo place les utilisateurs d’Amérique latine avec 6–8 heures de recouvrement horaire pour le support et sous ~100 ms pour les lectures. C’est une UX qui se vend.

Les arbitrages à accepter

• Un seul écrivain par base. Assumez-le : mettez en file les écritures ; maintenez des chemins d’écriture critiques étroits ; concevez l’UX pour des mises à jour optimistes quand les écritures sont routées vers un primaire distant.
• La maturité opérationnelle remonte dans la pile. Sans rôles/authentification imposés par le serveur, votre application doit être disciplinée sur l’autorisation, les migrations et le routage par locataire.
• Les sémantiques de réplication varient. D1, Turso, LiteFS et Litestream ressemblent tous à SQLite mais se comportent différemment sous pression d’écriture et en cas de panne. Testez la bascule, les partitions réseau et les temps de restauration comme pour n’importe quelle base.

Un plan 30–60–90 jours pour piloter SQLite sans drame

Jours 1–30 : Prouvez la valeur sur une fonctionnalité très lue

1. Choisissez un tableau de bord ou une vue catalogue avec un p95 connu > 300 ms.
2. Définissez un modèle de lecture minimal (tables dénormalisées + FTS) dans SQLite.
3. Générez le SQLite depuis Postgres chaque nuit ; puis passez à des mises à jour incrémentales toutes les 10 secondes.
4. Servez les lectures depuis le fichier SQLite localement ; journalisez les bascules vers Postgres.
5. Mesurez p50/p95 et la baisse de CPU sur Postgres. Visez 40–70% d’amélioration de latence.

Jours 31–60 : Poussez à l’edge et ajoutez de la résilience

1. Répliquez le SQLite vers deux régions (par ex. US-East + South America) via stockage objet + CDN ou réplicas LiteFS.
2. Ajoutez des health checks : PRAGMA integrity_check; au déploiement ; alertes sur le retard de réplica.
3. Automatisez les instantanés via Litestream. Documentez un exercice de restauration en 15 minutes.
4. Protégez le déploiement derrière un feature flag ; comparez les budgets d’erreurs.

Jours 61–90 : Étendez au par-locataire et au hors ligne

1. Basculez un petit cohort de clients vers des fichiers SQLite par locataire. Validez suppression, restauration et parcours support.
2. Prototypiez un utilitaire desktop offline-first (admin, import, app terrain) adossé à SQLite. Livrez une bêta privée.
3. Décidez : edge-only, isolation par locataire, ou offline-first—choisissez-en un à industrialiser le trimestre prochain.

Des choix de fournisseurs sans verrouillage

• Cloudflare D1 : Étroit avec Workers. Excellent pour des lectures globalement distribuées. Attention au routage des écritures et au modèle de cohérence à terme.
• Turso/libSQL : Un SQLite « server-ifié » avec réplicas edge. Ergonomie développeur simple ; gardez un œil sur les subtiles différences de compatibilité vs SQLite en amont.
• Fly.io LiteFS : Le vrai SQLite avec réplication au niveau des pages et un primaire unique. Excellent si vous voulez un maximum de portabilité et de contrôle.
• Litestream : Expédition WAL vers stockage objet, simple et fiable, pour la durabilité et le PITR. Parfait pour des fichiers par locataire.

Vous pouvez les combiner : D1/Turso pour les lectures à la demande, Litestream pour une sauvegarde durable, et LiteFS quand vous avez besoin de réplicas de lecture totalement sous votre contrôle.

Ce que votre équipe doit désapprendre

• « SQLite est pour les prototypes. » Il alimente de vastes systèmes en production (OS mobiles, navigateurs, IoT). Votre SaaS peut l’utiliser en toute sécurité—si vous respectez le modèle mono-écrivain.
• « Les caches doivent être clé–valeur. » La plupart des caches deviennent des bases ad hoc. Commencez avec une vraie base à l’edge ; elle vieillit mieux.
• « L’export de données est un rapport. » Pour des promesses sérieuses de portabilité, livrez le véritable format de données. Un unique fichier SQLite est à la fois lisible par un humain et adapté aux machines.

La dimension nearshore

Si vous opérez une organisation d’ingénierie distribuée avec des partenaires nearshore, SQLite réduit le couplage opérationnel. Vous pouvez confier à une équipe au Brazil un jeu de données et un environnement autonomes ; elle peut construire et tester des fonctionnalités hors ligne, valider des artefacts déterministes et livrer des bundles edge sans avoir besoin d’une copie complète de votre Postgres de production. Moins de cérémonie, plus de résultats—avec 6–8 heures de recouvrement de journée de travail pour des boucles de feedback serrées.

En résumé

Postgres reste votre colonne vertébrale. Mais en 2026, traiter SQLite comme un citoyen de seconde zone vous fait perdre en vitesse, fiabilité et économies. Adoptez-le délibérément là où il excelle : à l’edge, par locataire et hors ligne. L’aval de la Library of Congress est un signal d’alarme : les formats autonomes gagnent à long terme. Architectez en conséquence.

À retenir

• SQLite est désormais adoubé institutionnellement pour la préservation ; ce n’est pas un jouet—utilisez-le là où il est pertinent.
• Utilisez SQLite pour les lectures à l’edge, l’isolation par locataire et l’UX offline-first ; gardez Postgres pour les écritures à haute concurrence et la logique inter-tenant.
• Les outils modernes (D1, Turso, LiteFS, Litestream) rendent SQLite côté serveur pratique avec réplication et sauvegardes.
• Attendez-vous à 40–70% d’amélioration de latence sur les fonctionnalités à forte lecture et 50–70% de charge en moins sur votre base primaire.
• Concevez pour un seul écrivain : mode WAL, files d’écriture et bascules claires.
• La sécurité requiert du chiffrement au niveau de l’app ou du volume et l’autorisation dans votre couche de service.
• Pilotez en 90 jours : commencez par un modèle de lecture, poussez à l’edge, puis étendez au par-locataire ou au offline-first.