用 Rust 从零重写的 SQLite
Turso Database 是一个用 Rust 写的进程内 SQL 数据库,目标是与 SQLite 兼容:同样的 SQL 方言、同样的磁盘文件格式、同样的 C API。差别在底层。SQLite 是同步、单写者的 C 库,为本地磁盘的世界而调优;Turso 则把引擎围绕异步 I/O 与多版本并发控制(MVCC)重建,这正是 serverless 与边缘运行时一直向 SQLite 索要、却拿不到的东西。如果你用过 SQLite,它的表层意在让你感觉一模一样;而你对话的引擎,是全新的代码。
如果你收藏的是「Limbo」,就是它
这个项目此前叫 Limbo。名字改成了 Turso Database,改名的原因值得了解,因为它告诉你该多认真地看待它。Turso 这家公司长期通过 libSQL(一个分支)演进 SQLite。这次 Rust 重写,用团队自己的话说,起初只是「一个不起眼的实验」,结果做得足够好,以至于取代 libSQL 成为公司既定方向。所以 Turso Database 不是一个丢了名字的副项目,而是公司把未来押上去的那个赌注。旧的 tursodatabase/limbo 地址现在指向这里。
重写到底买到了什么
兼容性只是入场券。真正值得在意的,是 SQLite 没有的那些:
BEGIN CONCURRENT配 MVCC。 SQLite 把写者串行化。Turso 用多版本并发控制,让多个写者都能推进,这正是 SQLite 在并发负载下最大的痛点。- Linux 上经
io_uring的异步 I/O。 这是项目最初的命题:一个不会在每次磁盘调用上阻塞线程的数据库,这让它适配 serverless 运行时,在那里一个被阻塞的线程就是被浪费的预算。 - 变更数据捕获(CDC),实时跟踪数据库变更,内建而非靠触发器拼凑。
- 内置 MCP server。
tursodb your.db --mcp把数据库通过 Model Context Protocol 暴露给 AI 助手,带查询、插入、改表等工具。多数数据库要靠单独的适配器做这件事;Turso 直接打进了 CLI。 - 向量支持(精确搜索),外加一组项目仍标注为实验性的能力:静态加密、经 tantivy 的全文检索,以及经 DBSP 的增量视图维护。
安装
CLI 以一行安装脚本发布,数据库本体则在多数生态里作为原生库提供。
命令行:
curl --proto '=https' --tlsv1.2 -LsSf \
https://github.com/tursodatabase/turso/releases/latest/download/turso_cli-installer.sh | sh
Rust:
cargo add turso
JavaScript:
npm i @tursodatabase/database
Python:
uv pip install pyturso
Go 绑定(turso.tech/database/tursogo)、经 JDBC 的 Java、以及 .NET 也都有发布。注意各包名并不都与仓库名一致,这是改名的直接后果。
上手
CLI 打开一个交互式 shell tursodb,用法和 sqlite3 shell 类似:
$ tursodb
Turso
Enter ".help" for usage hints.
Connected to a transient in-memory database.
turso> CREATE TABLE users (id INT, username TEXT);
turso> INSERT INTO users VALUES (1, 'alice');
turso> SELECT * FROM users;
1|alice
在 Rust 里,API 天生异步,这正是重点:
let db = Builder::new_local("sqlite.db").build().await?;
let conn = db.connect()?;
let res = conn.query("SELECT * FROM users", ()).await?;
真正要紧的提醒:它仍是 BETA
读完功能清单之后再往下读,收益就在这里。Turso Database 明确处于 BETA,维护者也直说:他们的标准是「SQLite 级别的可靠性」,在确信达到这条线之前,关键任务场景请谨慎。对一个有 1.9 万星(截至 2026-06)的项目来说,这是少见的诚实立场。它今天确实跑在生产里,包括 Turso Cloud 和几个具名产品,也被一套原生的确定性模拟测试(Deterministic Simulation Testing)外加 Antithesis 反复锤打。但「支撑一些生产应用」和「可以在你的生产应用底下替换 SQLite」是两个不同的断言,团队很小心地不把二者混为一谈。
这里还有一处岔路常让新人困惑。Turso 同时有两个演进 SQLite 的项目。libSQL 是分支,如今已可用于生产。Turso Database 是重写,更激进,尚未到位。如果你这个季度就需要一个可靠的东西,这个区分就决定了你该选哪个。
Turso 与替代品
在这几个项目之间摆数据对比表会误导,因为它们回答的是不同问题,所以改用定位来比:
| 项目 | 路线 | 语言 | 成熟度 | 最擅长 |
|---|---|---|---|---|
| Turso Database | 重写 SQLite | Rust | BETA | 异步、并发写、边缘 |
| SQLite | 原版 | C | 极稳 | 嵌入一切 |
| libSQL | SQLite 的分支 | C | 可用于生产 | 今天就要 SQLite 加服务端能力 |
| DuckDB | 全新引擎 | C++ | 可用于生产 | 分析型(OLAP)查询 |
SQLite 仍是嵌入式存储的安全默认项,有 Turso 暂时追不上的数十年硬化。libSQL 是务实选择:同一团队、今天就能要到 SQLite-plus。DuckDB 其实不算竞品:它是列式、为分析而生,而 Turso 与 SQLite 一样是行式、面向事务。Turso 独有的主张,是把异步、可并发写的 SQLite 带到那些 SQLite 当初就没为之设计的运行时里。
何时适用,何时不适
当你想要 SQLite 语义,同时要异步、非阻塞 I/O、更好的写并发,或要经 WebAssembly 的浏览器构建,且能承受一个年轻引擎的风险时,选 Turso。当你今年就需要 SQLite 在你最重要的数据下久经验证的耐久性时,先别上:那时 SQLite 或 libSQL 才是负责任的选择,等 Turso 收敛到它的可靠性标准再回头看。想看像它这样的 Rust 系统项目背后更大的势头,见 Rust 趋势。
常见问题
这和 Limbo 是同一个项目吗? 是。Limbo 已改名为 Turso Database。tursodatabase/limbo 地址会重定向到这里,发布的包也改用了 turso 命名。
Turso 能用于生产了吗? 它已在一些应用(包括 Turso Cloud)的生产里运行,但维护者仍把它定为 BETA,关键任务场景在它达到 SQLite 级可靠性之前请谨慎。
Turso 和 libSQL 有何不同? libSQL 通过分支演进 SQLite,已可用于生产。Turso Database 是用 Rust 从零重写,是团队既定的长期方向,但尚未达到生产可用。
能用我现有的 SQLite 数据库吗? 这正是设计目标:Turso 保留 SQLite 的文件格式、SQL 方言与 C API,你已有的数据和查询意在原样沿用。