正在打开每日关注
正在打开每日关注
SQLite 开源却不收 PR，Turso 先 fork 后用 Rust 重写，作者认为动机是自由加功能而非内存安全
今天才知道 SQLite 是开源但不接受外部贡献的，基本不合 PR，代码一直由很小的核心团队自己维护。 所以 Turso 想给它加东西，先是 fork 了一个 C 版的 libSQL，后来干脆用 Rust 从头重写了一个兼容 SQLite 的数据库（原名 Limbo）。他们想要的异步 I/O、并发写入、向量搜索、更好的 WASM 支持，SQLite 官方都不打算做。 好玩的是，用 Rust 重写更安全这个理由放在 SQLite 身上其实说服力不大。SQLite 的测试代码量是源码的几百倍，分支覆盖率做到航空软件级别的 100%，最完整的那套测试还是闭源的。我感觉 Turso 真正想要的是能自由加功能。
是什么：一条关于数据库开源治理的技术观察。作者指出 SQLite 虽开源却基本不接受外部 PR，代码由极小核心团队封闭维护；Turso 为获得所需能力，先 fork 出 C 版 libSQL，最终用 Rust 从零重写 SQLite 兼容数据库（原名 Limbo）。
论点链条：Turso 想要异步 I/O、并发写入、向量搜索与更好的 WASM 支持，而 SQLite 官方明确不打算做。社区常以「Rust 更内存安全」为重写辩护，但作者认为这对 SQLite 说服力很弱——其测试代码量是源码的数百倍、分支覆盖率达航空软件级的 100%，最完整的一套测试甚至闭源。由此推导出真正的动机：不是安全性，而是对代码演进方向与功能自由的掌控权。
关键洞察：开源（open source）不等于开放贡献（open contribution），SQLite 是「大教堂模式」的极端样本；评判重写价值时，工程成熟度与测试文化可能比实现语言更重要。
边界与风险：动机判断属作者推断而非 Turso 官方表态；重写项目在 SQLite 兼容性、生态工具链与长期维护上仍有不确定性，能否替代原版尚待验证。