SQLite に別の仕組みを重ねて、1台が落ちてもデータを失わないようにする。そんな発想から始まった rqlite が、12年たって「distributed SQLite」という一つの分野になった、と作者の Philip O’Toole は振り返っています。この記事が面白いのは、単なる自作ソフトの回顧ではなく、後から次々に似た製品が現れた流れを、最初から見ていた当事者が並べ直している点です。流行の起点を2021年ごろに置きがちな語り方に、2014年からの記録で待ったをかけています。
O’Toole が rqlite を最初に公開したのは2014年9月だった。考え方は単純で、SQLite の前に Raft のログを置き、書き込みを必ずクラスタへ複製する。そうすれば、1台のノードが壊れてもデータは消えない。ソースコードはその週末に GitHub に置いたという。彼はこれが、SQLite と Raft を組み合わせた最初のオープンソース実装だったと見ている。
rqlite は、彼自身が働いていたクラスタ型システムで「小さな関係データをどのノードに持たせるべきか」という実務上の悩みから生まれた。仕事では別の道を選んだが、問題自体は一般的だと考えて作り続けた。最初は goraft を使い、のちに2016年初めに Hashicorp の Raft 実装へ切り替えた。設計の核は最初から変わらない。rqlite は CP system で、書き込みは leader を通し、過半数の応答が必要で、分断された minority は書き込みを受け付けない。その方針から HTTP API、read-consistency の段階、snapshotting などが決まっていった。
ただし、彼は自分だけがこの発想を思いついたとは言わない。Expensify は何年も前から自社基盤で SQLite を Paxos 風の方式で複製しており、2016年に Bedrock として公開した。ActorDB も同じ頃に現れた、各 actor に SQLite を持たせて Raft で複製する Erlang システムだった。違いは、rqlite がそれらとは別に、誰でも動かせる独立した open-source の一般向け製品として出てきたことだと整理している。
2017年には Canonical が dqlite を作った。LXD や MicroK8s のために、etcd を動かさずに埋め込み型の replicated store を持ちたかったからだ。O’Toole は Mark Shuttleworth から直接連絡を受け、rqlite を使えないか話したが、結局その形には収まらなかったという。dqlite は Go で始まり、その後 C に書き直され、独自の Raft library を持つようになった。彼の見立てでは、dqlite は rqlite に最も近いが、違いは packaging にある。dqlite は埋め込む library、rqlite は単体で動かす server だ。
2021年には Ben Johnson が Litestream を出した。これは consensus を使わず、SQLite の WAL を監視して S3 に流す方式だ。狙いは、1台で動く SQLite を、安価に disaster recovery できるようにすることだった。多くのアプリはクラスタを必要とせず、壊れたときに戻せれば十分だ、という主張だ。O’Toole はそれをかなり正しい見方だと認めつつ、Litestream と rqlite は別の問いに答えていると言う。前者は「マシンが死んだらどうするか」、後者は「マシンが死んだうえに、復旧を待てないときどうするか」だ。2022年には Fly.io が LiteFS を出し、filesystem レベルで SQLite を複製する方向に進んだ。これが platform の機能として replicated SQLite を扱う流れの最初期だったと彼は書く。
2022年はさらに動きが増える。cr-sqlite は CRDT を SQLite の拡張として加え、複数 writer が leader なしで分岐しても後で merge できるようにした。これは local-first application に向く AP 側の設計だという。libSQL は SQLite 自体を fork し、ChiselStrike から Turso へつながる流れの中で、エンジン内部を変えられない制約を避けた。その上に edge replica を持つ hosted service を作り、のちに Supabase が買収した。ほぼ同時期に SQLite Cloud も現れ、Raft で複製する hosted SQLite を提供している。Cloudflare は D1 を発表し、さらに Durable Objects に SQLite storage を入れた。こうして、かつては「自分で運用するもの」だった replicated SQLite が、「買うもの」へ変わったと彼は見る。
この記事の結論は、流行は新しく見えても、土台の考え方はずっと前からあった、という点に尽きる。SQLite を storage engine として使い、複製は外側で足す。この構図は少なくとも8つのチームが別々の理由で再発明してきた。しかも設計空間には三つの角がある。CP の consensus、安価な復旧の streaming、そして many writers を許す merge。どれも正しく、ただ答えている問いが違う。最後に残るのは、rqlite はまだ同じ役割で生きていて、自己運用できる fault-tolerant な relational database を求めるなら、今でも有力な選択肢だという彼自身の確認だ。
まず印象に残るのは、rqlite の位置づけが「最初の成功例」ではなく「後から増えた一群の原型」に近いことだ。2014年の時点で、彼は SQLite の強さを信じたうえで、足りない部分だけを Raft で補えばよいと考えた。これはかなり筋がいい発想だったと思う。複雑な分散DBを一から作るより、実績のある単体DBに整合性の層を足すほうが、実装も理解も軽い。ここで重要なのは、彼が「分散DBを作った」のではなく、「分散化したい既存DBをどう扱うか」を考えたことだ。以後の流れは、まさにその問いの回答をいろいろな形で並べ直したものになっている。
O’Toole が面白いのは、同じ「SQLite を守る」でも、Litestream を競合としてではなく別の問いへの答えとして扱っている点だ。ここは実務感覚がよく出ている。多くの現場では、クラスタを維持するより、1台のマシンが死んだときに素早く戻せるほうがずっと大事だろう。だから Litestream のような WAL のストリーミングは広く受け入れられた。一方で、サービス停止を長く許せない用途では、復旧を待つ間に止まること自体が問題になる。rqlite が必要とされるのはそこで、複数ノードの可用性をあらかじめ持っておきたい場合だ。どちらが優れているかではなく、運用上の痛みが違う。ここをはっきり分けているのは、かなり誠実だと思う。
彼が最後に強調しているのは、資金が集まったり買収されたりしたのが platform 側の製品だったことだ。これは技術の優劣というより、収益化のしやすさが違うからだろう。open-source の rqlite、dqlite、Litestream は、使う人にとってはありがたいが、そのままだと請求書になりにくい。逆に Turso、Cloudflare、SQLite Cloud のような形なら、複製された SQLite をサービスとして売れる。ここには少し寂しさもある。だが同時に、基礎技術が先に open source で成熟し、その後に商用サービスへ吸い上げられるのは、インフラ分野ではよくある流れでもある。O’Toole がそれを特に悲観していないのも納得できる。自分のプロジェクトが、その前史として12年残ったこと自体に十分な価値がある、という見方なのだと思う。
この文章を読んで一番得られるのは、distributed SQLite という言葉が、単なる流行語ではないと分かることだ。CP を選ぶのか、復旧の安さを取るのか、複数 writer を許すのかで、まったく別の製品になる。しかもそれぞれが、それぞれの現場ではちゃんと正しい。ここが面白い。新しいカテゴリが生まれるとき、人はつい「どれが本命か」を決めたがる。でもこの分野では、本命は1つに絞れない。むしろ「何のために SQLite を分散させるのか」を先に決める必要がある。O’Toole の記事は、その順番を12年分の実例で示している。rqlite がいまも残っているのは、その答えの一つが消えていない証拠だろう。
