前言

2026 年 7 月，GitHub Trending 上出现了一个让数据库圈和精神圈同时震动的新项目：malisper/pgrust——PostgreSQL，用 Rust 重写，WASM 编译，直接在浏览器里跑。

这个项目的 README 只有一行字：

pgrust — postgres, rewritten in rust

背后附着一行令人窒息的测试数据：PostgreSQL 官方全套回归测试 46,066/46,066 个查询全部通过（100%），完全兼容 PostgreSQL 18.3。

换句话说：这个 Rust 重写版本，不是一个 demo，不是一个 PoC，而是一个在功能语义上与原版完全等价的完整实现。

这到底是怎么做到的？意义在哪里？局限性又在哪？本文从架构设计、技术路径、WASM 编译、实际应用场景到生态影响，给你一次讲透。

一、背景：为什么有人想用 Rust 重写 PostgreSQL

1.1 PostgreSQL 的四十年技术债

PostgreSQL 起源于 1986 年的 UC Berkeley 项目"Ingres"，1996 年正式开源，至今已近四十年。四十年来，无数优秀的工程师在这棵代码树上添砖加瓦，使其成为功能最完备的开源关系型数据库。

但四十年也是一笔沉重的包袱：

C 语言的内存安全困境。 PostgreSQL 的核心代码大量使用 C 语言的手动内存管理，这意味着：

• 空指针解引用、数据竞争、缓冲区溢出等 bug 永远可能存在
• 即便社区极其优秀，内存安全漏洞仍然是 CVE 的常客
• 2024 年，PostgreSQL 曝出的高危漏洞中，有相当比例与内存安全直接相关

并发模型受限于历史设计。 PostgreSQL 的进程模型（每连接一个 OS 进程）在 1996 年是合理的设计，但在今天动辄十万连接的互联网场景下，其上下文切换开销已成为明显的瓶颈。

扩展性受制于 FFI 边界。 PostgreSQL 的扩展机制（Extension）通过动态库加载实现，但 C ABI 的稳定性、安全性以及与现代语言生态的集成，一直是痛点。

1.2 SQLite 的 Rust 之路：前车之鉴

SQLite 是"用 Rust 重写主流数据库"领域的先行者。

2024年，Oxide Computer 的工程师宣布他们用 Rust 重写了 SQLite 的核心部分，并通过了 SQLite 官方的全部测试套件。这个项目证明了：

1. 用内存安全语言重写数据库核心是可行的
2. 测试套件是最关键的护城河——SQLite 有 7 万多个测试用例
3. 性能不仅不会退化，甚至可以在特定场景下提升

但 SQLite 是一个嵌入式数据库，复杂度远低于 PostgreSQL。PostgreSQL 的 SQL 方言支持、MVCC 并发控制、复杂查询规划、复制协议、外部表等特性，使其复杂度高出一个数量级。

1.3 pgrust 的出现：不可能完成的任务？

正是带着这个背景，pgrust 出现在 GitHub Trending 上。它的目标不是"部分重写"，而是"完整等价"——用 Rust 从零实现 PostgreSQL 的所有核心功能，并达到 100% 的测试兼容。

二、技术路径：不是发明，是翻译

2.1 翻译而非重写：语义等价原则

pgrust 的核心策略，可以用一句话概括：保持行为与 PostgreSQL 完全一致，用 Rust 语法重写 C 代码。

这不是创造新数据库，而是编译器级别的大型迁移项目。

具体做法是：

1. 逐个分析 PostgreSQL 的 C 源码文件
2. 将其翻译为语义等价的 Rust 代码
3. 保持数据结构内存布局、函数签名、系统调用兼容
4. 通过完整的回归测试套件验证等价性

这个过程类似于"人肉编译器"，但有 AI 辅助（作者在多个公开场合提到使用了 Claude 等 AI 工具辅助翻译），所以能在较短时间内完成如此大规模的代码迁移。

2.2 为什么选择 Rust

Rust 对 pgrust 的价值在于它能解决 PostgreSQL 长期以来的多个核心问题。

内存安全： Rust 的所有权系统和借用检查器在编译期就能消除空指针、悬垂指针、数据竞争等 C 语言中常见的内存安全问题。

无 GC 暂停： Rust 的所有权模型不依赖垃圾回收器，在内存管理上没有任何不确定的暂停。对于追求毫秒级延迟的数据库来说，GC pause 是一个巨大的优势。

现代并发原语： Rust 原生支持 async/await、无锁数据结构、Send/Sync trait 等高级并发抽象。

WASM 友好： Rust 是编译 WASM 的首选语言，工具链成熟，生态丰富。这是 pgrust 能直接跑在浏览器里的关键原因。

2.3 架构总览

用户 / 客户端
     │ PostgreSQL Wire Protocol (v3)
     ▼
┌─────────────────────────────────────┐
│  pgrust 前端层                       │
│  协议解析器 │ 会话管理器              │
└─────────────────────────────────────┘
     │
     ▼
┌─────────────────────────────────────┐
│  pgrust 核心层                       │
│  查询解析器 │ MVCC 引擎 │ 索引引擎    │
│  存储引擎                              │
└─────────────────────────────────────┘
     │
     ▼
┌─────────────────────────────────────┐
│  存储层（可配置）                     │
│  本地文件系统 │ WASM 线性内存 │ 远程存储 │
└─────────────────────────────────────┘

三、WASM 编译：让数据库跑在浏览器里

3.1 从不可能到可能

传统观念认为，在浏览器里运行一个完整的关系型数据库是天方夜谭。但 WebAssembly 正在打破这些边界。

WebAssembly（WASM） 是一种可移植的二进制指令格式，最初设计用于在浏览器中运行高性能计算代码。它提供了：

• 沙盒化的执行环境
• 接近原生的执行速度
• 跨平台一致性
• 线性内存模型

pgrust 将 Rust 代码编译为 wasm32-unknown-unknown 目标，直接运行在浏览器的 WASM 运行时中。

3.2 wasm-bindgen：Rust 与 JavaScript 的桥梁

Rust 编译 WASM 的标准工具链是 wasm-bindgen，它自动处理 Rust 与 JavaScript 之间的类型转换和函数绑定。

use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub fn execute_query(sql: &str) -> String {
    let result = pgrust_core::execute(sql);
    serde_json::to_string(&result).unwrap()
}

3.3 浏览器端运行效果

访问 pgrust.com，你会看到一个交互式 PostgreSQL 终端，完全在浏览器中运行，支持以下功能：

• 标准 SQL 查询（SELECT、INSERT、UPDATE、DELETE）
• PostgreSQL 内置函数
• psql 元命令（\d、\dt 等）
• 数据持久化（通过 IndexedDB）

关键指标：

• 首次加载： 需要编译 WASM 模块，首次访问耗时约 3-5 秒
• 查询预热： 页面加载时预热查询，提升首次查询体验
• 兼容性： Safari 兼容版本（wasm32）已提供

3.4 技术细节：WASM 环境下的存储问题

在浏览器中运行的数据库，最核心的问题是数据持久化。pgrust 采用了以下策略：

方案一：IndexedDB 存储

const request = indexedDB.open(pgrust_storage, 1);

request.onupgradeneeded = (event) => {
    const db = event.target.result;
    db.createObjectStore(wal, { keyPath: lsn });
    db.createObjectStore(heap, { keyPath: relfilenode });
};

方案二：内存模式（临时数据）

对于不需要持久化的场景，pgrust 可以完全在内存中运行，页面关闭后数据消失，适合临时分析场景。

四、100% 回归测试通过：技术深度拆解

4.1 PostgreSQL 回归测试体系

PostgreSQL 拥有业界最严格的测试体系之一，官方回归测试包含约 46,066 个测试用例，涵盖：

4.2 翻译中的关键挑战

挑战一：MVCC（多版本并发控制）

PostgreSQL 的 MVCC 实现极其精妙，是其高性能的关键。每个事务有一个唯一的事务 ID（XID），元组头部存储 xmin 和 xmax 字段来判断可见性。Rust 实现必须完全等价：

pub fn tuple_visible(tuple: &HeapTuple, snapshot: &Snapshot) -> bool {
    if !snapshot.contains(tuple.xmin) {
        return false;
    }
    if let Some(xmax) = tuple.xmax {
        if snapshot.contains(xmax) {
            return false;
        }
    }
    true
}

挑战二：查询规划器

PostgreSQL 的查询规划器是其最复杂的组件之一，负责将 SQL 转换为最优的执行计划。pgrust 必须保持规划器的行为完全一致。

挑战三：WAL（预写日志）格式

PostgreSQL 的 WAL 是其一致性和复制的基础，格式完全固定。pgrust 的 WAL 写入逻辑必须与 PostgreSQL 字节级一致。

4.3 性能测试结果

分析：

• 本地 Rust 版本性能约为原生 PostgreSQL 的 70-95%，主要性能损耗来自翻译过程中对部分 C 优化的保留不足
• WASM 版本性能明显较低，但对于轻量级查询和浏览器内数据分析场景，已经完全可用

五、实际应用场景

5.1 场景一：浏览器端数据探索

pgrust 的最直接应用是在浏览器中运行完整数据库，用于：

• 离线数据分析： 无需安装任何数据库软件，直接在浏览器中打开 CSV 文件，加载到 pgrust 中进行 SQL 分析
• 技术演示： 在技术博客、在线教程中嵌入可交互的数据库环境
• 嵌入式 BI： 将 pgrust 嵌入到 Web 应用中，为用户提供基于真实 SQL 的数据分析能力

CREATE TABLE sales (
    id SERIAL PRIMARY KEY,
    product VARCHAR(100),
    amount DECIMAL(10, 2),
    region VARCHAR(50),
    sale_date DATE
);

SELECT region, SUM(amount) as total
FROM sales
WHERE sale_date >= 2026-01-01
GROUP BY region
ORDER BY total DESC;

5.2 场景二：Edge Computing 与无服务器数据库

WASM 的一个重要特性是其可移植性和沙盒安全性，pgrust 可以部署在：

• Cloudflare Workers： 在全球 CDN 边缘节点运行数据处理
• Deno Deploy： 在 Deno 运行时中运行完整的数据库
• 嵌入式设备： 在资源受限的 IoT 设备中运行数据库

这代表了一个全新的范式：数据库作为可移植的计算单元，而非需要专门服务器的重量级服务。

5.3 场景三：内存安全的数据库基础设施

从长远看，pgrust 的最重要意义是为 PostgreSQL 生态提供一条内存安全的演进路径。

如果 pgrust 能够持续维护并与 PostgreSQL 官方版本保持同步，它有可能成为：

• 高安全性场景下的 PostgreSQL 替代品（如金融、政务）
• 数据库内核安全研究的重要参考实现
• 未来 Rust-native 数据库的参考架构

六、与同类项目的横向对比

6.1 与 PostgreSQL 原版的对比

6.2 与 SQLite WASM 版的对比

七、局限性与挑战

7.1 维护成本：跟进 PostgreSQL 主线的代价

PostgreSQL 每年发布一个大版本，每月有小版本更新。pgrust 要保持与 PostgreSQL 的功能同步，需要持续跟进这些变更。这是一个持续性的工程挑战。

7.2 生态系统：扩展与驱动的缺失

PostgreSQL 的强大，很大程度上来自其扩展生态：

• PostGIS： 地理空间扩展的事实标准
• pgvector： 向量存储，RAG 应用的核心
• TimescaleDB： 时序数据扩展
• pg_partman： 分区管理

pgrust 目前没有这些扩展的支持，即使在核心功能上 100% 兼容，生态的缺失也意味着它无法在生产环境中替代 PostgreSQL。

7.3 性能差距

虽然 Rust 版本在本地运行表现不错，但与高度优化的 PostgreSQL C 代码相比，仍有 10-30% 的性能差距。

7.4 社区与商业支持

PostgreSQL 背后有多家商业公司支持，拥有全球最大的开源数据库社区。pgrust 目前是个人项目，缺乏长期维护保障。

八、展望：Rust 重写数据库的时代才刚刚开始

8.1 从不可能到可能

pgrust 的出现，在技术史上具有标志性意义。它证明了：用现代内存安全语言重写一个数百万行代码的复杂数据库系统，是可行的。

这个证明本身，比项目本身更有价值。它为整个行业打开了一扇门：那些因为 C 语言内存安全问题而对数据库内核望而却步的 Rust 开发者，终于有了一个可参考的实现路径。

8.2 未来演进路径

短期（2026-2027）：

• 完善扩展机制支持
• 提升本地 Rust 版本性能（目标：达到原生 PostgreSQL 的 95%+）
• 稳定 WASM 版本，降低首次加载时间

中期（2027-2028）：

• 跟进 PostgreSQL 17 的主要新特性
• 实现逻辑复制协议，与原生 PostgreSQL 组成集群
• 完善 WASM 环境下的存储层，支持更大的数据集

长期（2028+）：

• 成为 PostgreSQL 内核安全研究的参考实现
• 在特定垂直领域（金融、政务、Edge）形成生产级部署
• 推动 PostgreSQL 社区考虑 Rust 作为未来内核语言的可选路径

8.3 对普通开发者的意义

即使你不会直接使用 pgrust，它也值得关注，原因有三：

第一，理解数据库内核的最佳教材。 pgrust 的 Rust 代码比 PostgreSQL 的 C 代码更易于阅读和学习，是理解关系型数据库内部机制的绝佳资料。

第二，AI 辅助代码翻译的里程碑。 pgrust 展示了 AI 在大型代码迁移项目中的潜力——46,066 个测试用例全部通过，意味着 AI 辅助翻译的质量已经达到了工程级标准。

第三，数据库未来的方向标。 WASM 化、内存安全、Edge-native——这些趋势正在重塑数据库的边界，pgrust 是这一趋势的先行者。

九、总结

pgrust 不是一个"更好"的 PostgreSQL——至少现在还不是。它是一个实验性的、令人敬畏的证明：

用 Rust 在语义级别完全重写一个四十年历史的数据库巨头，并在官方全部测试用例上达到 100% 通过，这在 2026 年是可以做到的。

它的价值不在于立即取代 PostgreSQL，而在于：

• 为数据库内存安全化提供了可参考的实现路径
• 展示了 WASM 作为数据库运行时的可能性
• 证明了 AI 辅助大型代码迁移工程的可行性

更重要的是，它让我们重新思考了一个问题：我们习以为常的数据库，真的只能是这样吗？

当你打开浏览器，在沙盒环境中运行一个完整的 PostgreSQL 实例，执行复杂的 SQL 查询，看到结果在毫秒级返回——那一刻，你会感受到数据库这个"基础设施"正在被重新定义。

而定义它的，正是像 pgrust 这样敢于用毕生功力挑战四十年遗产的项目。

参考资料：

• pgrust 官网：https://pgrust.com/
• GitHub：https://github.com/malisper/pgrust
• PostgreSQL 官方回归测试文档：https://www.postgresql.org/docs/current/regress-overview.html
• Rust WASM 官方文档：https://rustwasm.github.io/docs/book/