Douze ans de SQLite distribué : retours et écosystème fragmenté
Sommaire
En bref
- Philip Otoole, auteur de rqlite, revient sur douze années de SQLite distribué, comparant différentes approches (rqlite, dqlite, Litestream, D1 de Cloudflare).
- Le marché reste fragmenté : chaque solution fait des compromis différents sur les transactions, la réplication, les dépendances externes et l'architecture (embeddée vs serveur).
- Les commentateurs soulignent l'absence d'une solution complète réunissant clustering, embeddabilité, transactions et sauvegarde cloud.
- Le débat oscille entre la viabilité de SQLite distribué en production et l'alternative croissante : passer directement à PostgreSQL via des outils simples.
Ce que dit la source
L'auteur propose un bilan personnel de douze années passées à développer et à maintenir rqlite, un système de réplication SQLite basé sur un algorithme de consensus distribuant la charge sur plusieurs nœuds. Il contextualise rqlite par rapport à ses variantes et concurrents (Litestream, dqlite, D1, Durable Objects de Cloudflare), mettant en avant ses choix architecturaux. Le post semble revisiter l'histoire et les compromis de ces approches, sans que le texte complet soit disponible.
- D1 de Cloudflare est au cœur un wrapper autour de Durable Objects (stockage singleton), ce qu'un développeur de D1 lui-même a confirmé ; utiliser directement Durable Objects est souvent plus efficace que D1.
- rqlite utilise un algorithme de consensus entre nœuds pour garantir la cohérence et permettre le basculement du nœud primaire, contrairement à Litestream qui ne fait que synchroniser vers S3.
- Les solutions divergent radicalement sur les transactions : rqlite n'offre pas officiellement le support BEGIN/COMMIT, tandis que dqlite supporte les transactions complètes de SQLite.
- dqlite (maintenu par Canonical) n'a aucune dépendance externe (pas de S3 ni Consul), mais souffre de limites documentées ; une bibliothèque client Python DB-API et SQLAlchemy est en développement.
- Plusieurs approches coexistent : zaxonlite (Zig, WAL replication avec Paxos) et sqlodin (Odin, sans WAL, exécution SQL sur chaque nœud mais support SQL limité).
- PostgreSQL avec outils simples gagne du terrain auprès des développeurs comme alternative plus complète que SQLite distribué, surtout avec l'émergence d'agents IA facilitant la gestion.
- rqlite est utilisé en production (exemple : plan de contrôle de morio.it, une solution d'observabilité open source) et bénéficie d'une maintenance exemplaire.
Dans les commentaires
Débat partagé entre enthousiasme pratique et questions architecturales : certains saluent l'implémentation et la stabilité de rqlite en production, d'autres expriment un scepticisme croissant sur la nécessité même d'une couche de distribution SQLite face à PostgreSQL. Peu d'interrogations substantielles sur les garanties de fiabilité (aucune mention de tests Jepsen).
- Un commentateur signale que D1 s'avère peu fiable en production, contredisant l'argument de simplicité de Cloudflare.
- L'absence d'une solution globale est un point de friction récurrent : aucun projet ne combine embeddabilité, clustering, transactions, sauvegarde S3 et modes AP/CP optionnels.
- Plusieurs commentaires suggèrent que PostgreSQL simple + outils modernes (IA, gestion aisée) est devenu plus pragmatique que d'ajouter une couche de distribution sur SQLite.
- Le ton du dernier tiers de l'article est perçu comme défensif et 'snarky' envers D1, suivi d'une section jugée défaitiste pour rqlite ; un lecteur critique y voit un refus du débat nuancé.
- Aucune mention de tests Jepsen ou d'audit de robustesse distribuée dans les commentaires fournis, laissant les garanties en partition ouvertes.
Alternatives citées : dqlite (Canonical, transactions complètes), Litestream (synchronisation S3 simple), zaxonlite et sqlodin (Zig/Odin avec Paxos), D1 (Cloudflare, wrapper Durable Objects), PostgreSQL (alternative croissante)
Notre lecture
Dix-deux ans après les premiers pas de rqlite, le sujet reste pertinent mais aux marges. Pour qui ne peut pas migrer vers PostgreSQL (contraintes embarquées, coût, complexité opérationnelle), rqlite offre une base solide et bien maintenue. Le tableau comparatif détaillé des solutions aurait cependant aidé à clarifier qui choisir quand : le fragmenté de l'écosystème (transactions, dépendances, architecture) fait que chaque compromis convient à un cas d'usage spécifique, sans solution généraliste. À court terme : intéressant pour qui est déjà investi SQLite et a besoin de réplication simple ; sinon, le coût d'apprentissage d'une nouvelle approche distribuée n'en vaut probablement pas la peine. Pas d'urgence pour une DSI à examiner cela sauf si SQLite embarqué est un élément architectural clé.