P99 CONF 2025 上Glauber Costa 分享了一个在数据库圈和 Rust 圈里都很有讨论度的话题为什么我们要用 Rust 重写 SQLite。很多人看到这个标题的第一反应是“重复造轮子”但实际讨论的并不是“SQLite 不行了”而是“当应用运行时环境越来越复杂一个 C 语言实现的嵌入式数据库还能不能顺畅地嵌进新一代系统”。如果你关注过本地存储、WASM、异步运行时、Rust 数据库生态这场演讲里提到的取舍值得仔细看。这篇文章我会按工程落地的顺序拆开讲重写的动机、技术分层、环境准备、验证方法、常见报错以及到底什么场景适合使用这类替代实现。1. 先想清楚SQLite 已经很成熟为什么还要重写1.1 SQLite 的问题不是功能而是扩展方式SQLite 是目前部署量最大的数据库之一。它把整个数据库内核编译进单个库文件应用直接调用函数没有独立服务也没有网络端口文件格式稳定事务语义经过了大量真实场景验证。移动端、桌面端、嵌入式设备、浏览器存储层很多地方都在用 SQLite。那为什么还要重写如果只看功能列表确实看不出明显缺口。真正的问题出在“C 语言的调用边界”上。C 实现提供的是一套同步函数调用接口应用必须按照这个模型的节奏来使用数据库。这种模型在传统本地应用里没有问题但在几类新场景里会出现摩擦。第一类是 WebAssembly。C 代码能编译成 wasm但要在浏览器或边缘运行时里提供 SQL 能力需要处理 JavaScript 宿主、内存导入导出、异步调度等多层桥接。第二类是 Rust 服务端应用。项目里嵌入一个 C 数据库后每次操作都要经过 FFI还要处理线程安全、生命周期、错误码转换维护成本不低。第三类是强异步场景。服务端希望把数据库操作放进同一个异步事件循环而 SQLite 的同步 I/O 与锁模型并不天然匹配。这些问题不是 bug而是语言边界带来的结构性摩擦。Rust 重写想做的是从系统层面消除这层摩擦。1.2 内存安全不是唯一动机工程可控才是很多人听到 Rust 重写数据库第一反应是内存安全。这个说法不算错但只是很小的一部分。SQLite 本身经过了非常长期的测试、模糊测试和实际部署检验普通应用能触发的内存问题概率已经很低。真正驱动团队重写的原因更多是工程层面的可控性。在 Rust 里写数据库可以用所有权系统约束页缓存、事务句柄、锁等待状态这些对象的管理方式让很多错误在编译期被拦住。对长期维护数据库内核的团队来说这比事后靠测试发现问题要舒服得多。另一个原因是模块化能力。C 项目里很多结构是全局的页缓存、虚拟文件系统、锁管理器之间的边界不总是清晰。Rust 的 trait、模块和 crate 机制让替换某个实现变得更直接。比如你想换掉默认页缓存或者给存储层接入自己的索引格式Rust 版本可以在接口层做更多抽象而不需要动整个核心。所以这个演讲里的“重写”与其说是为了消灭 unsafe不如说是想让数据库内核在后续扩展时更容易被团队掌控。1.3 性能传言要冷静看待讨论 Rust 重写 SQLite 时最常见的说法是“性能大幅提升”。如果你去读这场演讲的讨论会发现真实答案要复杂很多。数据库的读写性能取决于文件布局、缓存策略、事务提交机制、锁粒度而不是单纯由编程语言决定。Rust 重写不会因为语言本身让 SQL 变快。真正的收益可能出现在这些地方异步 I/O 能在高并发小任务下减少线程阻塞Rust 的内存管理能减少频繁分配带来的开销更现代的并发原语能降低特定锁竞争。但如果你只跑单线程顺序写入、简单查询Rust 版和标准 SQLite 的差距会很小甚至可能因为实现尚未优化而更慢。所以判断性能前先确认测试场景是什么。不能用一个没有充分调参的实验结果去否定一个方向也不能用一个单项测试结论去宣称全面领先。我建议把这场演讲理解成“一次重写工程的思考”而不是“Rust 版 SQLite 已经全面超越 C 版”的保证。看它时重点看的不是数字而是作者对兼容、事务、存储层的判断。2. 用 Rust 重写 SQLite到底重写了哪几层2.1 三个层次的兼容目标重写一个数据库第一步是决定兼容到什么程度。这直接决定工作量和风险。兼容层次要处理的内容简单验证方式SQL 语法层DDL、DML、表达式、约束、UPSERT、窗口函数用业务常见 SQL 回归文件格式层页结构、B-Tree、索引、WAL 文件、freelist直接打开标准 SQLite 生成的 .db 文件运行时行为层事务、锁状态、VFS 调用、崩溃恢复语义并发写入、断电和重启测试不同项目的定位差异很大。有些只做语法兼容底层存储完全自己设计数据文件不能和 SQLite 互通。有些目标是字节级兼容希望现有应用直接换底层实现文件不用迁移。还有一些是“SQLite 风格接口但内核独立”只取使用体验不承诺文件格式一致。这个演讲里讨论的 Rust 重写方向更接近“保持原有使用体验同时替换内核”。这意味着 SQL 解析、执行计划、存储、事务和日志都要在 Rust 里重新组织工作量并不小。2.2 SQL 解析和 UPSERT 这类方言细节最容易上手的部分通常是 SQL 解析。Rust 生态里有现成的 SQL 解析器 crate可以先把文本解析成 AST再构建执行计划。但难点在于 SQLite 的 SQL 方言范围很宽。它支持类型亲和性、多种显隐类型转换、带 NULL 处理的表达式规则还有很多历史遗留语法。比如INSERT ... ON CONFLICT ... DO UPDATE也就是很多人在热搜词里说的“存在就更新不存在就新增”。这条 SQL 看起来简单但 on conflict 的匹配目标、DO UPDATE 和 DO NOTHING 的语义、与 WHERE 子句的交互都要逐一对齐。如果只是实验项目可以先实现常用子集。先保证建表、插入、查询、索引、事务这些核心路径能用。但如果指向生产替代兼容性测试必须是持续投入的不是写一个解析器就结束。很多看似简单的 SQL在真实业务里会和类型转换、默认值、级联更新组合出各种边界情况。2.3 存储层和事务模型才是重头戏SQLite 文件内部有页、B-Tree、空闲页链表、WAL 文件和回滚日志。Rust 重写如果选择兼容现有文件格式必须严格