2014 年 rqlite 的誕生與 CP 架構選擇
Philip O'Toole 於 2014 年 9 月發布 rqlite，旨在解決叢集系統中關係型儲存節點故障導致資料遺失的問題。其核心設計是在 SQLite 前方加入 Raft 日誌，將所有寫入操作複製到叢集中。
rqlite 被定義為 CP（Consistency-Partition tolerance）系統，這意味著寫入必須經過領導節點並獲得多數節點確認，而在網路分區發生時，少數派節點會拒絕寫入以保證一致性。這一設計決策自發布以來從未改變，後續的 HTTP API、讀取一致性級別與快照功能均基於此架構衍生。
初期版本使用 goraft 庫，後於 2016 年初替換為 Hashicorp 的 Raft 實作並沿用至今。O'Toole 指出，雖然 Expensify 內部早已使用 Paxos 風格協議複製 SQLite（後於 2016 年開源為 Bedrock），且 ActorDB 也在同期出現，但 rqlite 是首個將此概念獨立出來、作為通用開源工具供任何人運行的系統。
嵌入式庫與日誌串流技術的分歧
2017 年，Canonical 為了讓 LXD 和 MicroK8s 擁有內嵌的複製儲存而不需依賴 etcd，開發了 dqlite。dqlite 最初以 Go 語言編寫，後重寫為 C 語言並自帶 Raft 庫。與 rqlite 作為獨立伺服器不同，dqlite 是一個供產品內嵌使用的函式庫，兩者在包裝形式上有本質區別。
2021 年初，Ben Johnson 發布了 Litestream，這標誌著技術路線的重大轉變。Litestream 不使用共識演算法，而是監控 SQLite 的 WAL（Write-Ahead Logging）並將其串流至 S3 儲存桶。這種方法為單節點 SQLite 資料庫提供了極低成本的災難復原能力，主張多數應用只需單機運行與故障恢復，無需複雜叢集。
Litestream 與 rqlite 解決的是不同問題：前者應對「機器當機如何恢復」，後者應對「機器當機且無法等待恢復時如何繼續服務」。Fly.io 於 2022 年聘用 Ben Johnson 並推出 LiteFS，透過 Consul 租約在檔案系統層級複製 SQLite，試圖將此功能平台化。有趣的是，Litestream 的 WAL 處理方式後來啟發了 rqlite v8.0 版本的改進。
多寫入合併與雲端托管服務的興起
2022 年出現了兩種不同於共識演算法或日誌串流的新方法。cr-sqlite 透過擴充 SQLite 引入 CRDT（無衝突複製資料型別），允許多個寫入者在不依賴領導節點的情況下產生分歧並最終合併，這屬於 AP（可用性-分區容忍度）架構，適合本地優先應用。
libSQL 則是直接對 SQLite 核心進行分支修改，由 ChiselStrike（後更名為 Turso）開發。由於 SQLite 官方不接受外部貢獻，Turso 透過修改引擎內部並建立邊緣節點複製的托管服務來實現分散式功能。該公司獲得風險投資，並於 2026 年被 Supabase 收購。同期出現的 SQLite Cloud 則提供基於 Raft 複製的托管 SQLite 服務，設計理念最接近 rqlite 原始架構。
雲端平台也相繼進入此領域。Cloudflare 於 2022 年宣布 D1，將 SQLite 作為邊緣網路內的無伺服器資料庫，並將儲存整合進 Durable Objects。這類產品將分散式 SQLite 轉化為用戶無需了解底層實作的托管服務，標誌著該類別從「自行運行的工具」轉變為「購買的服務」。
技術架構的三種路徑與商業化現實
回顧十二年發展，O'Toole 總結出分散式 SQLite 設計空間的三個角落：首先是基於共識演算法的強一致性叢集（rqlite, dqlite）；其次是基於日誌串流的低成本災難復原（Litestream）；最後是基於 CRDT 的多寫入最終一致性（cr-sqlite）。每種架構針對不同的應用場景，用戶間的爭論往往源於對需求定義的誤解。
儘管核心概念被至少八個團隊以不同協議重新實現，證明瞭「SQLite 作為儲存引擎加上外部複製」這一思路的有效性，但資本流向卻集中在平台化服務上。rqlite、dqlite 和 Litestream 保持開源免費，而獲得融資或被收購的項目均將技術包裝為計費服務。
O'Toole 表示，雖然基礎設施概念最終走向商業化是常見現象，但他強調該想法在開源階段維持了八年才出現商業銷售。rqlite 至今仍在維護，繼續作為一個可自行運行、完全理解且無需付費的容錯關係型資料庫選項存在。
