Origine et conception de rqlite

En septembre 2014, Philip O’Toole a publié rqlite, le premier projet open‑source à placer un journal Raft devant SQLite. La version initiale s’appuyait sur goraft, la même bibliothèque utilisée par InfluxDB et etcd à l’époque. Dès 2016, le code a été migré vers l’implémentation Raft de HashiCorp, qui reste la base actuelle. rqlite a été conçu comme un système CP : chaque écriture doit transiter par le leader, obtenir l’accord d’une majorité et les nœuds minoritaires refusent les écritures en cas de partition. Cette règle de cohérence a structuré l’ensemble de l’API HTTP, les niveaux de lecture et le mécanisme de snapshotting.

Évolution des projets de SQLite distribué

Après rqlite, plusieurs initiatives ont exploré la même idée. En 2017, Canonical a lancé dqlite, une bibliothèque embarquée écrite d’abord en Go puis réécrite en C avec son propre moteur Raft. La différence principale réside dans le mode d’intégration : dqlite se compile dans l’application, alors que rqlite s’exécute comme serveur autonome. En 2021, Litestream a introduit une approche sans consensus : il surveille le WAL de SQLite et le réplique vers S3, offrant une récupération après sinistre à moindre coût. Cette méthode répond à la question « et si la machine meurt ? », alors que rqlite répond à « et si la machine meurt et que je ne peux pas attendre la restauration ? ».

Analyse des modèles de cohérence

Les douze années montrent trois coins du spectre de cohérence. Le premier, incarné par rqlite et dqlite, repose sur le consensus Raft : un leader unique garantit une consistance forte mais impose une latence d’écriture liée à la majorité. Le second, Litestream, adopte un modèle CP simplifié sans cluster ; il sacrifie la disponibilité instantanée au profit d’une récupération rapide via le stockage objet. Le troisième, introduit par cr‑sqlite (2022), ajoute des CRDTs à SQLite, créant un système AP où plusieurs nœuds peuvent écrire indépendamment et fusionner ultérieurement. Chaque modèle répond à un besoin fonctionnel distinct, et les débats entre leurs utilisateurs portent essentiellement sur la question sous‑jacente plutôt que sur la supériorité technique.

Implications commerciales et perspectives

Depuis 2022, la catégorie a attiré des financements et des acquisitions. libSQL a été forké pour créer le service hébergé Turso, racheté par Supabase en 2026. SQLite Cloud propose une réplication Raft en SaaS, tandis que Cloudflare D1 et ses Durable Objects offrent SQLite en tant que base de données serverless à la périphérie. Ces plateformes transforment le « fait‑maison » en produit commercial, mais les projets open‑source originaux (rqlite, dqlite, Litestream) restent actifs et continuent d’évoluer, offrant aux équipes la possibilité de déployer une base de données relationnelle tolérante aux pannes sans dépendre d’un fournisseur.