Limbo（现 Turso Database）：用 Rust 重写 SQLite 的豪赌

2024 年 12 月 10 日，Turso 的 Pekka Enberg 与 Glauber Costa 发了一篇博客：他们要做一件”野心勃勃的实验”——用内存安全的 Rust 从零重写整个 SQLite，代号 Limbo。两年前他们刚 fork SQLite 做出了 libSQL，为什么又要推倒重来？这个项目现在怎么样了？本文基于当时的官方公告与项目最新 README，做一次梳理。

一、背景：从 fork（libSQL）到重写（Limbo）

故事要从两年前说起。Turso 团队是 SQLite 嵌入式设计的拥趸，但不满它相对封闭的开发模式，于是在 2022 年 fork 出了 libSQL——一个开放贡献的分支，加上原生复制、向量搜索等特性，后来成了 Turso 云平台的引擎，官方称其收获了 1.2 万+ GitHub Star、85 位贡献者。

fork 路线有两个绕不开的痛：

1. SQLite 的测试套件是专有（proprietary）的，外部贡献者很难有信心做大改动；
2. SQLite 用 C 写就，是不安全语言，在它上面演进代码库风险很高。

真正的转折点是给 SQLite 加向量搜索。为了让向量语法足够自然，他们不得不改动字节码生成器。但即使这样，想要的 ORDER BY vector_distance_cos(...) LIMIT 3 仍然做不到，最后只能妥协成把索引当一张独立表、再显式 JOIN：

SELECT title, year FROM vector_top_k('movies_idx', vector('[4,5,6]'), 3)
JOIN movies ON movies.rowid = id;

这次”戴着镣铐跳舞”让团队重新发问：从零重写 SQLite，到底要多少工作量？能不能顺带把异步 I/O 这些早就想做的事做了？ Pekka 在个人 GitHub 上开了个实验，代号 Limbo，没怎么宣传就靠 X 上的一条帖子涨到 1000 Star、30+ 贡献者，于是 Turso 决定把它扶正为官方项目。

二、它现在是什么：从 Limbo 到”数据库界的 LLVM”

需要说明的是，这个项目已经改名并演进：仓库从 tursodatabase/limbo 变为 tursodatabase/turso，README 现在的名字是 Turso Database。它的自我定位也从”重写的 SQLite”升级成更宏大的目标——做”数据库界的 LLVM”。

和 SQLite 一样，它把 SQL 编译成字节码交给一台虚拟机（VDBE）执行。Turso 的设想是：这台 VM 作为通用底座，上面挂多个”前端”——SQLite 是第一个也是主要前端（方言、文件格式、C API 都兼容），Postgres 现在已经是第二个实验性前端（说 Postgres 方言、走 Postgres 线协议），未来还会有更多。存储、并发、查询编译器、VM 是共享的。官方调侃这个字节码通用到”可以在上面跑 Doom”。

它明确表示：如果重写成功，这套代码就取代 libSQL 成为下一代方向；两者目前都在生产运行，libSQL 久经考验，Turso Database 是开发重心。

三、技术机制：异步 I/O + WASM 优先 + DST

全异步 I/O。SQLite 的接口是同步的，驱动作者想做异步就得外挂辅助线程；而多数 SQLite 查询很快（本地无网络往返），很多驱动干脆就放弃了异步。Turso 认为这有两个根本问题：不是所有 SQLite 查询都快（大表聚合永远慢），而且现代环境里查询本来就该走网络（Turso 自己就是通过 HTTP 提供 SQLite）。于是 Limbo 从底层把核心入口 sqlite3_step 设计成异步——数据没准备好就先返回调用方；Linux 上用高性能的 io_uring。

WASM 优先。SQLite 虽能编译到 WASM，但那是事后补丁（生态里有 wa-sqlite 这类项目撑着）。Limbo 从零就有 WASM 构建，已有能配合 Drizzle 等 ORM 直接用的 VFS 实现。

确定性仿真测试（DST）。重写一个以可靠性著称的数据库，测试只会更难？Turso 的答案恰恰相反——因为是从零写，他们把 DST（TigerBeetle 带火的测试范式）从第一天就内建进数据库核心，还和 Antithesis 合作做系统级确定性仿真。Antithesis 的确定性超并行 fuzz 已经帮他们抓到了自家 DST 抓不到的 io_uring 部分写（partial write）bug——这是极难自动化触发的极端场景。除此之外他们还常规 fuzz 输入，并逐条比对 Limbo 与 SQLite 生成的字节码是否一致。

四、关键数据与官方口径

2024 年公告里唯一的性能数字是这样的（官方自测，M2 MacBook Air）：

到今天（README），它宣称的能力还包括：BEGIN CONCURRENT（MVCC 提升写吞吐）、变更数据捕获 CDC、精确向量检索、用 tantivy 做的全文检索、静态加密、用 DBSP 做的增量计算、跨进程 WAL 协调；语言绑定覆盖 Rust/JS/Python/Go/Java/.NET。生产用户包括 Turso Cloud、Kin AI 助手、Spice.ai。

五、评测方法批判：那个”快 20%“怎么读

这组性能数字需要非常克制地理解：

1. 它只是一条点查询的微基准（LIMIT 1），不是 OLTP、不是 TPC 类负载。一条返回单行的查询快 20%，不能外推到写密集、聚合、连接复杂的工作负载；
2. 只有一台 M2 MacBook Air，没有服务器级配置、没有重复跑、没有方差；
3. 官方自己注明”SQLite 的数字是调优后”的（开 WAL、关 POSIX advisory lock 等）——也就是说拿”调好的 SQLite”当对手，Limbo 只赢 20%，这个差距其实不大；
4. 公告里”很多操作上已与 SQLite 持平或更快”是定性描述，没有给出完整 benchmark 套件；今天 README 也没有一份与 SQLite 正面对打的公开基准。

换句话说：这个 20% 说明”Rust 重写没有在最简单的路径上输给 SQLite”，远不足以证明它在生产负载下更快。

六、官方自己承认的局限

这一节全是官方白纸黑字：

• 还没到 1.0：README FAQ 明说”我们还没到 1.0，部分功能明确标注为实验性”，并建议用户”像对待任何数据库一样保留独立备份”；
• SQLite 兼容还没到 100%：兼容覆盖方言、文件格式、C API，当前跟踪 SQLite 3.50.4，但”不是 100%，仍有差异”，由 COMPAT.md 持续追踪，完全兼容是 1.0 的硬性要求；
• 重写的根本风险：SQLite 几十年积累的边界 case 与 bugfix 是公开软件里最厚的护城河之一，DST 是他们押注的缩小差距手段，但”追上 SQLite 级可靠性”是目标而非既成事实；
• Postgres 前端仍是实验性，向量近似索引（HNSW 类）还在 roadmap 上，尚未发布。

七、优势与适用人群

优势：

1. 内存安全（Rust），从设计上规避 C 的一大类漏洞；
2. 原生异步 I/O 与 WASM，契合”边缘 + 浏览器 + Serverless”的现代部署形态；
3. “一核多前端”的架构想象力——同一份 VDBE 跑 SQLite 与 Postgres 方言；
4. MIT 协议，开放贡献，且 Turso 公司在持续投入。

局限：

1. 未到 1.0、兼容未满 100%，生产替换 SQLite 仍需谨慎；
2. 缺乏全面、独立的性能基准；
3. 项目方向已两次调整（fork→重写→更名 Turso Database），长期 API 稳定性待观察。

适合谁： 关注 Rust 嵌入式数据库、需要原生异步与 WASM 部署、愿意跟早期项目的团队；以及 Turso 生态用户。如果你只是要一个稳定、生态成熟的嵌入式库，今天的 SQLite 仍是最稳妥的默认选择——Limbo/Turso Database 是”SQLite 的下一代候选”，而非”今天的替代品”。

参考来源

• Turso 官方博客：Introducing Limbo — A complete rewrite of SQLite in Rust
• Turso Database 官方 GitHub（原 limbo 仓库）
• Koala 项目库条目：Limbo | 用 Rust 重写 SQLite