刊 DailyNews 科技 / AI 每日文摘2026 年 10 月 30 日

每日文摘

深挖 · Turso：用 Rust 从零重写 SQLite 的嵌入式数据库，还想做数据库界的 LLVM

题图

<本文由用户点名深挖：想明确 Turso 的功能与适用场景，作为后续技术方案调研的知识储备。结论先行：它是 SQLite 的 Rust 从零重写（不是 fork、不是云 CLI），用「一个数据库内核、多个 SQL 前端」的 LLVM 思路做嵌入式数据库，AI agent 场景是当前第一卖点——但引擎仍 pre-1.0，官方基准全部自测，选型时要带上这两条滤镜看它。>

是什么

Turso 是一个用 Rust 从零重写的 SQLite 兼容进程内（in-process）SQL 数据库，MIT 协议，24.3k star（GitHub API 2026-09-14 实测，当天仍有提交合并）。官方一句话描述：“A SQL database in Rust: SQLite-compatible, now also speaking Postgres (experimental). The LLVM of databases.”

先做身份纠偏，这是读一切 Turso 资料的前提——网上「Turso」这个词至少指过三代东西：

为什么要重写而不是继续 fork？官方的转向宣言说得很直白：SQLite 是 C 写的（官方原话 “an unsafe language”），测试套件私有，fork 两年也没能通过社区贡献推动内核演进——那就自己写一个。兼容性承诺压了三层：SQL 方言、文件格式（现有 .db 文件直接打开）、C API；当前跟踪 SQLite 3.50.4，未到 100%，已知差距全部记录在 COMPAT.md（例如文本必须合法 UTF-8，SQLite 则保留原始字节）。

核心机制：一个内核，多个前端

Turso 的架构叙事是「数据库界的 LLVM」：与 SQLite 一样把 SQL 编译成字节码在 VDBE 虚拟机上执行，但目标是 “one modern and reliable core, and many frontends compiled down onto it”——SQLite 是第一个前端，2026-07 起实验性增加 Postgres 前端（把 Postgres 方言解析成共同 AST 再编译到同一字节码，共享存储/并发/查询编译器/VM），官方明言只求 “compatible enough”，不承诺 100% 兼容（公告、The Register 报道）。这个 VM 的通用性有个赏心悦目的演示：他们在 VDBE 字节码上跑起来了未修改的 Doom。

对 SQLite 长期短板的修补是真正的功能卖点，但每条都要看成熟度分层：

最值得尊敬的部分是可靠性工程：确定性模拟测试（学 TigerBeetle/FoundationDB）+ Antithesis 故障注入 + 与 SQLite 的差分字节码模糊测试 + Quint 形式化规约——后者在 SQLite 本体里找出了 10+ 个 bug。不过官方自己也设了护栏：README FAQ 明确 pre-1.0 建议 “keep independent backups”，2026-03 的一周年复盘承认还缺 multiprocess 支持与 VACUUM。

怎么跑起来

数据说话

好消息和冷水都要如实端上。

官方基准全部自测，且条件苛刻。 最著名的「并发写 4x SQLite」出自官方博文，前提是 8 线程 + 事务内含 1ms 计算；同一篇文章诚实披露了反例：单线程、零计算时 SQLite 反而更快。基线是 SQLite 全同步模式批量插入约 15 万行/秒。「连接建立快 575x」的数字只在万表场景成立（单表场景仅 3.25x）。Turso Sync 对旧 Embedded Replicas 的 8.9x/312x 则是自家新旧方案对比。这些都没披露硬件与版本，且不存在任何 Turso vs Postgres 的官方基准——repo 里的 PERF.md 只有 ClickBench/TPC-H 跑分脚本，没有公布结果。

社区质疑集中四点（HN 主串 143 分/102 评、kerkour 深评串 192 分/145 评）：闭源云与 open-core（有用户实测 libSQL 的 offline sync 在开源 sqld 上跑不起来，被指对 SQLite 搞 EEE）；libSQL 被边缘化；新引擎成熟度（缺 savepoints/window 函数/ATTACH，MVCC 实验性，有人审 PR 发现数据损坏 bug 修复缺测试）；VC 背景的可持续性（rugpull 担忧、「别拿生产环境当新数据库的 beta 测试场」）。事故记录也有：2025-01 云数据丢失（官方称功能在 beta）、2023-12 泄露他人数据库（旧时代）。

正面证据同样要摆出来：开发速度被 HN 用户形容为 “Commit history is nuts!"；生产案例密度最高的正是 database-per-agent 场景——CTO.new 数万个库、5 万+用户、从 Supabase 迁出后数据库成本降约 95%；Poke 3 个月约 1 亿条消息；Adaptive.ai 超过 200 万个库。独立深评（kerkour.com）的定性比较中肯：它修对了 SQLite 的长期痛点（内建加密、并发写、async），定位上与 DuckDB 互补——“DuckDB for analytical data, and Turso for transactional data”。

值不值得跟

作为后续方案调研的选型知识，把「什么时候该想到它、什么时候别用」记成两张清单：

该想到 Turso 的场景（依据官方场景页与迁移指南）：

  1. 需要 SQLite 但被它的短板卡住——无并发写、无内建加密、无原生向量；
  2. 海量小库架构（database-per-user / per-agent，数千到数百万个库）：这是当前第一卖点，「无限数据库 + 闲置零成本」是独有打法；
  3. 本地优先/离线优先应用想要现成同步层，不想自搭 PowerSync/Electric（Sample Vault 案例就是这个画像）；
  4. AI agent 的数据层：引擎内置 MCP server，官方有完整的 database-per-agent 架构指南；
  5. 读多写少、中小数据量的降本场景（官方口径：50GB、1 万 QPM，托管 PG 约 $200/月 vs Turso 约 $25/月）。

别用或慎用的场景：

  1. 重 JOIN、存储过程/复杂触发器、PostGIS/PG 专有类型——这是官方自己在迁移指南里列的「留在 PostgreSQL」清单，官方承认 PG 优化器对多表 JOIN 更强；
  2. 高并发写是硬需求：云上并发写 2026-08 才 early preview，引擎整体 pre-1.0；
  3. 重分析/OLAP：用 DuckDB，社区与官方都不主张 Turso 干这个；
  4. 对成熟度极敏感的生产系统：Turso Cloud 自己 2026-03 都还没换上自研引擎，README 建议 1.0 前保留独立备份；
  5. 纯本地单机、无同步无多库需求：直接用 SQLite 就够——Turso 的增值全在 Sync/Cloud/平台层。

最后一层对冲值得记住：这家公司（两位创始人均出自 Linux kernel 与 ScyllaDB，About）历史上动作激进——BaaS、边缘数据库、fork、全量重写、闭源云、Postgres 前端，叙事换了五轮，平台层承诺可能再变。但引擎层 MIT + SQLite 文件格式兼容意味着你的数据永远是标准的 .db 文件，随时可以退回 SQLite 生态——退出成本极低，这是评估这类激进项目时最实在的安全垫。

参考阅读