L'évolution de SQLite distribué, de rqlite aux services cloud managés

En septembre 2014, Philip O'Toole a publié rqlite, un système open source qui combinait SQLite avec le protocole de consensus Raft pour créer une base de données en cluster tolérante aux pannes. Douze ans plus tard, O'Toole revient sur la manière dont cette expérimentation initiale a déclenché l'émergence d'une catégorie plus large de solutions SQLite distribuées, allant des CRDTs local-first aux services managés financés par le capital-risque.

Ce qui s'est passé

O'Toole a initialement développé rqlite pour résoudre un problème d'infrastructure spécifique chez jut.io : fournir un stockage relationnel pour un système en cluster sans désigner un nœud unique comme détenteur permanent des données. En plaçant un journal Raft devant SQLite, il garantissait que chaque écriture était répliquée à travers le cluster, prévenant ainsi toute perte de données en cas de défaillance d'un nœud. Le code source a été publié sur GitHub dès ce même week-end, marquant ce qu'O'Toole considère comme la première combinaison open source de Raft et SQLite. Pendant plusieurs années, rqlite est resté seul dans cette niche, aucun autre projet majeur ne tentant une architecture similaire.

Le paysage a commencé à évoluer en 2016 lorsque Expensify a publié Bedrock, un système de réplication SQLite basé sur Paxos qu'ils utilisaient en interne depuis des années. À peu près au même moment, ActorDB est apparu, offrant des bases de données SQLite répliquées via Raft pour des acteurs individuels dans un environnement Erlang. Bien que ni l'un ni l'autre n'aient connu une adoption généralisée en dehors de leurs entreprises d'origine, ils ont démontré que le concept de réplication de SQLite gagnait du terrain. Cependant, rqlite est resté distinct en tant qu'outil autonome et polyvalent que tout développeur pouvait déployer indépendamment d'un framework applicatif spécifique.

En 2017, Canonical a développé dqlite pour fournir un magasin répliqué embarqué pour LXD et MicroK8s, évitant la charge opérationnelle liée à l'exécution d'etcd. Bien qu'O'Toole et Mark Shuttleworth aient discuté d'une éventuelle collaboration, les projets ont divergé dans leurs modèles de packaging. Dqlite est devenu une bibliothèque C intégrée directement dans les applications, tandis que rqlite est resté un processus serveur séparé. Cette distinction a défini leurs cas d'utilisation respectifs : dqlite pour les fonctionnalités de base de données à l'intérieur des produits, et rqlite pour l'infrastructure de base de données à côté d'eux.

Comment cela fonctionne

Le mécanisme central de rqlite repose sur l'algorithme de consensus Raft pour gérer l'état à travers plusieurs nœuds. Dans ce système CP (Cohérence et Tolérance aux partitions), toutes les opérations d'écriture doivent être dirigées vers le nœud leader. Le leader ajoute ensuite la modification à son journal et la réplique aux nœuds suiveurs. Une écriture n'est considérée comme réussie qu'une fois qu'une majorité du cluster l'a confirmée. Si une partition réseau isole une minorité de nœuds, ces nœuds refusent les écritures pour empêcher la divergence des données, assurant ainsi une forte cohérence au prix de la disponibilité pendant les partitions.

Cette conception contraste fortement avec les approches ultérieures comme Litestream, publié par Ben Johnson en 2021. Litestream n'utilise pas de protocoles de consensus. Il surveille plutôt le Write-Ahead Log (WAL) de SQLite et diffuse les modifications vers un stockage objet tel que S3. Cela offre une reprise après sinistre pour les déploiements mono-nœud à coût minimal, répondant au besoin commun de sauvegarde plutôt que de clustering en temps réel. Rqlite répond à la question de la haute disponibilité là où les temps d'arrêt sont inacceptables, tandis que Litestream adresse la durabilité des données pour des architectures plus simples.

Des innovations plus récentes ont exploré différents points de l'espace de conception. Cr-sqlite introduit les Types de Données Répliqués Sans Conflit (CRDTs) comme extension SQLite, permettant à plusieurs rédacteurs de diverger et de fusionner les modifications sans leader central. Cette approche AP (Disponibilité et Tolérance aux partitions) convient aux applications local-first où la cohérence immédiate est moins critique que la capacité hors ligne. Parallèlement, des projets comme libSQL ont forké le moteur SQLite lui-même pour permettre des intégrations plus profondes, alimentant des services comme Turso qui proposent des bases de données répliquées en edge sous forme de produit managé.

Détails clés

• Rqlite a été publié en septembre 2014, utilisant initialement la bibliothèque goraft avant de passer à l'implémentation Raft de Hashicorp début 2016.
• Dqlite de Canonical, créé en 2017, est une bibliothèque C intégrée dans les applications, alors que rqlite fonctionne comme un serveur autonome.
• Litestream, lancé en 2021, diffuse les fichiers WAL de SQLite vers S3 pour la reprise après sinistre sans utiliser de protocoles de consensus.
• Cr-sqlite permet le support multi-rédacteur via les CRDTs, répondant aux besoins des applications local-first qui nécessitent une cohérence éventuelle.
• Turso, construit sur le fork libSQL, a été acquis par Supabase en 2026, soulignant la viabilité commerciale de SQLite distribué managé.
• Cloudflare D1 et Durable Objects représentent le virage vers la réplication SQLite serverless et managée en edge.

Pourquoi c'est important

Pour les ingénieurs logiciels et les responsables d'infrastructure, comprendre l'histoire de SQLite distribué clarifie les compromis entre différents patterns architecturaux. L'émergence de trois coins distincts dans l'espace de conception — clustering basé sur consensus, diffusion WAL et fusion CRDT — signifie que le choix d'une solution exige une définition précise des exigences. Les développeurs doivent décider s'ils ont besoin d'une forte cohérence avec haute disponibilité, d'une reprise après sinistre économique ou de capacités de collaboration hors ligne. Appliquer incorrectement un système CP comme rqlite à un cas d'utilisation nécessitant uniquement une sauvegarde, ou inversement, peut entraîner une complexité inutile ou des risques pour les données.

La trajectoire allant des outils open source aux plateformes managées reflète également une tendance plus large dans les logiciels d'infrastructure. Alors que rqlite, dqlite et Litestream restent gratuits et open source, les capitaux-risqueurs importants et les acquisitions se sont orientés vers des services qui abstraitent la complexité opérationnelle. Des entreprises comme Turso et Cloudflare vendent la réplication SQLite comme une utilité, permettant aux équipes d'éviter la charge de maintenance liée à la gestion de clusters. Ce changement valide la technologie sous-jacente mais modifie le modèle économique pour les développeurs qui dépendaient auparavant de solutions auto-hébergées.

Ce que vous pouvez faire

• Évaluez vos exigences de cohérence : choisissez des systèmes basés sur Raft comme rqlite pour une forte cohérence, ou des CRDTs comme cr-sqlite pour les applications offline-first.
• Envisagez Litestream si votre besoin principal est la reprise après sinistre pour une base de données SQLite mono-nœud plutôt que le clustering en temps réel.
• Utilisez dqlite si vous construisez une application nécessitant une base de données répliquée embarquée sans dépendances de services externes.
• Explorez les services managés comme Turso ou Cloudflare D1 si vous souhaitez déléguer la charge opérationnelle de la gestion de clusters de bases de données distribuées.
• Examinez les capacités de diffusion WAL dans rqlite v8.0, inspirées par Litestream, pour optimiser les processus de sauvegarde et de récupération.
• Évaluez si votre équipe possède l'expertise nécessaire pour maintenir un cluster Raft auto-hébergé ou si une plateforme managée offre une meilleure allocation des ressources.