程序员圈子里有一句老话：“永远不要重写正在运行的代码。”而SQLite，可能是这颗星球上最没有理由被重写的代码——它跑了二十多年，部署在数十亿设备上，稳定得像个物理定律。但2026年，Fireship用一期10分钟的视频告诉我们：这世界上最受信任的代码，真的正在被用Rust重写，而且“它真的能跑了”。
这期视频值得看的原因有三个：第一，它讲清楚了一个反直觉的事实——SQLite的测试套件竟然是专有闭源的，这直接动摇了“社区可以安全地改它”的根基；第二，它记录了"RIIR"（Rewrite It In Rust）这场持续多年的社区运动中，极少数真正走到可用阶段的项目——Turso Database；第三，它回答了一个所有工程师都绕不开的问题：什么样的重写才会成功？答案是测试先行、兼容层护城河和差异化特性，而不是对Rust的信仰。下面我们把这10分钟拆开揉碎讲。
| 项目 | 内容 |
|---|---|
| 视频标题 | The most trusted code on Earth is being rewritten in Rust |
| 频道 | Fireship（约430万订阅） |
| 发布日期 | 2026-06-19 |
| 时长 | 10分12秒 |
| 播放量 | 约60万 |
| 核心主题 | SQLite的历史地位、Turso（原Limbo）项目的Rust重写实践、RIIR浪潮的成败逻辑 |
顺带一提，这期视频的赞助商是AI编程代理Junie——一个讲“重写史诗级代码库”的视频配一个AI写代码的广告位，本身就很有2026年的时代感。
视频开场讲了SQLite的起源：2000年前后，D. Richard Hipp为了解决一个朴素又致命的问题——数据库服务器一宕机，整个应用跟着瘫痪——做出了一个嵌入式数据库。它不跑在独立进程里，而是作为一个库直接嵌进应用程序，没有网络，没有配置，整个数据库就是一个文件。
二十多年过去，SQLite成了无处不在的基础设施：你的手机、浏览器、几乎所有操作系统和海量桌面应用里都躺着它。视频里Fireship用了他标志性的说法：这是"the most trusted code on Earth"。
我的延伸分析：SQLite的可信不只来自“用了很久”，更来自它偏执的测试文化——官方文档里大量篇幅在讲各种“怎么把它弄坏”的极端场景测试。但视频引出了一个鲜为人知的冷知识（这一点也被Turso官方博客确认）：SQLite的测试套件是专有的。也就是说，全世界每天都在用的这段代码，外人根本拿不到它的完整测试集。这意味着任何人想大改SQLite，都无法验证改动是否破坏了那些隐藏的边界行为。这个细节是理解整个故事的钥匙——它决定了后来者的策略。
故事的前半段是fork。两年多前，Turso团队先fork了SQLite做出libSQL，走开放贡献路线（据Turso官方博客：超过1.2万GitHub stars、85位贡献者，加上了复制和向量搜索等功能）。fork的好处是能随时从上游回合并新特性，坏处也摆在桌面上：测试套件拿不到，C语言内存不安全，“带着敬意做大改动”几乎是奢望。
压垮fork路线的最后一根稻草是一个具体的技术挫折。团队想给SQLite加原生向量搜索，希望写出自然到几乎“无聊”的SQL：
SELECT title, year FROM movies
ORDER BY vector_distance_cos(embedding, vector('[4,5,6]'))
LIMIT 3;
但因为向量索引需要侵入式修改字节码生成层，最终只能妥协成一个丑陋的方案：把索引当成单独的表，再手动JOIN回主表。正是这个体验让他们意识到：在别人的地基上，永远盖不出自己想要的那层楼。（这段SQL对比是Turso官方博客的内容，视频用更浓缩的方式讲了同一件事。）
2024年12月，团队成员Pekka Enberg在个人GitHub账号上启动了一个代号Limbo的实验：用Rust从零重写SQLite，目标是在语言层面和文件格式层面完全兼容SQLite，同时做到全内存安全。据Turso官方博客，这个实验没怎么宣传就自然涨到1000 stars、吸引30多位贡献者，随后被转正为公司官方项目，2026年更名为Turso Database，进入beta阶段。
我的延伸分析：这里有个非常值得玩味的策略转变。行业里“重写传奇代码库”的项目十有八九死在半路，而Turso敢下注，靠的是三个差异化条件——这也是视频真正的干货（下一节展开）：一是他们不再依赖SQLite的测试集，而是用全新的可靠性方法论补上这块短板；二是兼容性目标是刻在项目基因里的硬约束而非口号；三是他们不是“为了Rust而Rust”，而是有async、向量搜索这些SQLite架构上给不了的真实诉求。同样逻辑的反面教材马上就有：Bun在2026年年中把整个代码库从Zig迁到Rust，据Fireship的说法只花了约11天，但据第三方分析，迁移后代码里仍有上万个unsafe块——换语言不等于换安全，重写的价值在于架构，不在于语言图腾。
这是整期视频技术含量最高的部分。既然拿不到SQLite的测试集，Turso怎么敢宣称可靠性“持平甚至超越”？他们的答案是确定性模拟测试（Deterministic Simulation Testing，DST）——这个范式由TigerBeetle团队发扬光大，核心思想是：把整个系统放进一个确定性模拟器里运行，可以用不同的故障注入和事件顺序“模拟运行好几年”，而且发现的每个bug都能100%复现。
Turso不止自己做DST，还与Antithesis合作——这家公司提供系统级的确定性模拟测试框架，用确定性hypervisor并行跑大量模糊测试线程，模拟各种硬件和软件故障。官方博客给了一个绝佳案例：Antithesis帮他们找到了io_uring实现里部分写入（partial write）场景下的bug——这种极端罕见的条件，自研模拟器根本测不到，因为测试时真实I/O循环被替换成了模拟I/O。
我的延伸分析：这里藏着一个范式级洞察——SQLite的可靠性是“三十年堆人力测出来的”，Turso的可靠性是“设计出来的”。传统测试发现bug后经常无法复现，而DST把“复现”变成了免费品。这对所有做基础设施软件的团队都是启发：可靠性的上限，取决于你能否把罕见的故障变成可重复的实验。
重写不是信仰投资，Turso拿到的回报都是SQLite架构上给不了的：
全异步I/O：SQLite的接口是同步的，驱动作者想要异步行为只能靠额外的辅助线程。但现实中“所有SQLite查询都很快”是个假设——大数据集上的聚合查询照样很慢，而在现代架构里（比如Turso自己通过HTTP提供SQLite服务、或基于S3的“无限存储”方案），查询走网络是常态。Turso从底层把sqlite3_step扩展为异步API，在Linux上用高性能异步系统调用接口io_uring。
MVCC并发写：通过多版本并发控制实现写并发，摆脱了SQLite传统的锁模型。
原生向量搜索：回到要点2那个挫折——在完全自己的代码库里，向量可以成为一等数据类型，关系查询和向量查询可以在同一张表里用自然的SQL语法完成。这在AI应用遍地的2026年，是个极具现实意义的能力。
以上三点在视频中是主线内容，特性细节与第三方报道（如ghtrends.dev、explainx.ai对Turso 2026年beta状态的描述）相互印证。
官方博客的基准数据（注明：来源为Turso官方博客，在MacBook Air M2上执行cargo bench）：SELECT * FROM users LIMIT 1，调优过的SQLite跑出620ns，Turso跑出506ns——快了约20%。一个beta项目在部分操作上追平甚至超过打磨了二十多年的原版，这本身就是重写可行性的有力注脚。
另外两个容易被忽略的点：一是简化。SQLite多年积累下大量调优旋钮——要开WAL模式、要禁POSIX advisory locks才能榨出极致性能，而Turso在保持字节码和文件格式兼容的同时，砍掉了amalgamation这类历史包袱，追求“开箱即用就是好性能”。二是为WASM而生。SQLite编译到WASM更像事后补丁（需要wa-sqlite这类项目帮忙），Turso从第一天就设计WASM构建，已有可配合Drizzle等流行工具的VFS实现，浏览器支持在推进中。
我的延伸分析：WASM方向值得单独强调。如果数据库能原生跑在浏览器和边缘环境里，“本地优先”（local-first）应用的存储层会多一个重量级选项。这可能是Turso比“又一个更快数据库”更深远的筹码。
flowchart TD
A["SQLite：地球上部署最广的数据库"] --> B["为什么可信"]
A --> C["为什么想动它"]
B --> B1["2000年起二十余年打磨"]
B --> B2["偏执的测试文化"]
B --> B3["测试套件专有闭源"]
C --> C1["C语言：内存不安全"]
C --> C2["同步API：不合现代架构"]
C --> C3["字节码层动不了：<br>向量搜索语法妥协"]
C1 --> D["RIIR浪潮：<br>Rewrite It In Rust"]
C2 --> D
C3 --> D
D --> E{"重写策略对比"}
E --> F["Bun：AI辅助整体迁移<br>Zig到Rust约11天<br>但残留上万个unsafe块"]
E --> G["Turso：从零重写<br>Limbo到Turso Database"]
G --> H["兼容性护城河<br>文件格式+字节码兼容SQLite"]
G --> I["可靠性新范式<br>DST确定性模拟测试<br>+ Antithesis故障注入"]
G --> J["现代化特性<br>async io_uring / MVCC并发写<br>原生向量搜索 / WASM"]
H --> K["结论：重写成功的钥匙<br>兼容层 + 测试先行 + 真实差异化诉求"]
I --> K
J --> K
1. 给“要不要重写”一个可操作的判断框架。 Turso案例给出的答案可以浓缩成三个检查项：你是否被测试集锁死（改不动）？你是否需要动架构地基（加不了）？你是否能守住兼容层（换得走）？三问都答“是”，重写才是理性选择；只要有一问答“否”，就回去做fork或封装。Bun的案例从反面提醒：即便有AI辅助、11天完成机械迁移，上万个unsafe块意味着安全和审计成本只是换了形态，并没有消失。
2. “Rust = 安全”需要打折扣。 2026年就有现成教训：rust-openssl绑定今年披露了高危漏洞CVE-2026-41676（据NVD与OSV记录，0.9.27至0.10.78之前的版本在Deriver::derive中存在缓冲区溢出风险）——Rust代码通过FFI调用C库的边界，依然是C的世界。做内存安全评估时，请把依赖树里的C bindings一并算进去。
3. 对通信行业同行的类比。 5G核心网里大量网元仍是C/C++实现，UPF这类高性能数据面组件的内存安全问题在3GPP生态里讨论多年。Turso给的启示是：与其在十万行遗留代码上渐进式打补丁，不如想清楚哪些“异步化、云原生化”的诉求是老架构给不了的——用清晰的兼容层定义 + 新一代测试方法论（比如基于真实信令流程回放的确定性重放）去验证新实现，比“用新语言重写一遍”这个口号本身重要得多。
4. 立刻能做的动作。 Turso Database目前是beta，不建议直接上生产核心链路，但三件事值得现在做：用cargo bench跑一遍官方基准感受性能；如果你的AI应用有“结构化数据+向量”混合查询需求，关注它的原生向量搜索语法演进；如果你的产品面向浏览器/边缘端，盯住它的WASM构建进度。
这个视频最大的价值，是把一场看似鲁莽的重写，还原成了一堂教科书级的工程决策课：敢动地球最可信代码的底气，来自兼容层、确定性测试和对真实痛点的回应——而不是对任何编程语言的信仰。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。