出来事の日付：2026年10月24日

Rqliteの開発者フィリップ・オトゥール氏が、このオープンソースデータベースの12年を振り返る記事を公開した。SQLiteの前段にRaft合意プロトコルを置く実験が、複製型・分散型SQLiteシステムという、より広い分野とともに成長してきた経緯を説明している。

オトゥール氏は、実際のインフラ上の課題に直面したことをきっかけに、2014年9月にGitHubでrqliteを公開した。クラスター構成のアプリケーションに小規模なリレーショナルデータストアが必要だったが、そのデータを1台のマシンに置くと、明らかな障害点が生まれてしまう。rqliteは、書き込みをクラスターのリーダー経由で処理し、Raftログを通じて複製してから完了を応答することで対応した。

この設計により、rqliteは一貫性と分断耐性を重視するCPシステムとなっている。書き込みにはノードの過半数による確認が必要で、ネットワーク分断で孤立した少数側のノードは書き込みを拒否する。プロジェクトがRaftの実装を変更し、HTTPインターフェースを開発し、読み取りの一貫性に関する選択肢やスナップショット処理を追加しても、この基本的な選択は維持されてきた。

回顧記事では、rqliteを同時期や後発の取り組みの中にも位置付けている。オトゥール氏によると、Expensifyは2016年にBedrockを公開する以前から、Paxos型の手法でSQLiteを社内で複製していた。一方、ActorDBは同じ頃、個々のSQLiteデータベースとRaftを組み合わせていた。その後、CanonicalはLXDやMicroK8sなどの製品向けに、組み込み可能な複製型データストアとしてdqliteを開発した。対照的に、rqliteはアプリケーションと並行して稼働することを想定したサーバーであり続けた。

別のプロジェクトは、異なる障害モデルに取り組んだ。2021年に公開されたLitestreamは、SQLiteの先行書き込みログをオブジェクトストレージへストリーミングし、マシン障害の後に単一のデータベースを復元できるようにする。合意形成を行うクラスターを維持するものではない。Fly.ioのLiteFSは複製をファイルシステム層に移し、cr-sqliteは競合のない複製データ型を使って、互いに異なる書き込みを行った後でマージできる仕組みを実現した。LibSQLはエンジンレベルの変更を可能にするためSQLiteをフォークし、Tursoのホスティングサービスの基盤となった。

オトゥール氏は、これらの手法を大きく3つの設計に分類している。強い一貫性を持つクラスターのための合意形成、単一の書き込み元から低コストで復旧するためのストリーミング、結果整合性を受け入れるアプリケーションのためのマージだ。それぞれが解決する運用上の問題は異なるため、どれを選ぶかは、アプリケーションが即時のフェイルオーバー、単純な復元、独立した書き込み元のどれを優先するかに左右される。

この記述はrqliteの開発者自身による歴史であり、独立した市場調査ではない。その有用な点は、1つのストレージエンジンに、互いに異なる複製モデルがどのように組み合わされてきたかを技術的に整理していることにある。最初の公開から12年がたった今も、rqliteはセルフホスト型の耐障害性を備えたリレーショナルデータベースとして位置付けられている一方、商用プラットフォームは関連する発想をマネージドサービスへと発展させている。

こうした違いは、「分散SQLite」という表現が、実質的に大きく異なる保証をひとまとめにしてしまう理由も明確にしている。復旧用のストリーミングは、クォーラムに支えられたクラスターと同じ可用性特性を提供するわけではない。また、マージを重視するシステムは、強い一貫性を持つサービスが防ぐ振る舞いを意図的に受け入れる。