本文转自微信公众号“Rust开发笔记”，原文发表于2026年3月，已获授权。

如果我说，有一门编程语言正在“悄无声息”地重塑我们最爱的数据库，你信吗？

PostgreSQL，这个被称为开发者最爱、功能最强大的开源关系型数据库，已经雄踞江湖多年。但在2026年的今天，一场深刻的变化正在其内部发生。变化的源头，不是新的SQL标准，也不是Oracle的某个特性，而是Rust语言。

今天，我们就基于行业内的一些深度观察（如Sylvain Kerkour的博客观点）以及最新的项目动态，来聊聊为什么说 “Rust is eating PostgreSQL” 。这不是取代，而是一次从内到外的进化。

一、 为什么会是Rust？

在深入项目之前，我们要先理解这个化学反应的底层逻辑。PostgreSQL本身是用C语言写的，极其稳定且强大。但C语言在内存安全和并发编程上的“手工感”，在现代云原生环境下显得有些力不从心。

Rust的出现提供了完美的“补强”：

1. 内存安全：无需GC（垃圾回收）即可保证线程安全，这对于数据库这种7x24小时运行的基础软件至关重要。

2. 零成本抽象：Rust的性能与C比肩，这意味着用它重写或扩展数据库逻辑，几乎没有性能损耗。

3. 现代工具链：Cargo等工具让开发、测试、打包扩展变得异常简单。

这三板斧，让Rust成为了改造PostgreSQL生态的“天选之子”。

二、 被Rust“吞噬”的PostgreSQL全景图

目前，Rust对PostgreSQL的渗透主要体现在三个层面：核心存储与计算、代理与中间件、内部函数与扩展。我们挑几个最典型的项目来看看。

1. 存储层的颠覆者：Neon

如果说有一个项目最能让AWS Aurora感到压力，那必然是 Neon 。

Neon将PostgreSQL的计算和存储彻底分离。传统上，PostgreSQL实例必须挂载本地或网络存储。而Neon的存储引擎完全用Rust编写，它把数据日志（WAL）实时处理并卸载到像S3这样的对象存储中。

• Rust在这里做了什么？Rust负责实现高性能的 Pageserver。它需要一边接收来自计算节点的WAL日志，一边进行重组、压缩，并最终落盘到廉价的对象存储。Rust的高并发处理能力和低内存占用，使得Neon可以实现“按需激活计算节点”和“毫秒级数据库分支”这种魔幻特性。

  • 结果：开发者现在可以像操作Git分支一样操作数据库，CI/CD环境瞬间复制一份生产级数据库，成本极低。

2. 中间件的革新者：PgDog

在高并发场景下，我们通常需要在数据库前加一个连接池或代理。传统的PgBouncer虽然好，但功能相对单一。于是，PgDog 出现了 。

PgDog是一个用Rust编写的PostgreSQL代理，它不仅具备连接池功能，还内置了读写分离、负载均衡和分片（Sharding） 的能力。

• Rust在这里做了什么？代理需要解析SQL流量，这要求极高的I/O处理能力。Rust的异步运行时（如Tokio）让它能轻松处理数以万计的并发连接，而不会像某些基于Java的代理那样消耗巨量内存。PgDog通过解析查询，智能地将SELECT扔给从库，将写入留在主库，这一切对应用程序透明。

  • 结果：你的老旧单体应用，不需要改代码，只需把网络连接指向PgDog，瞬间就拥有了分布式数据库的扩展能力。

3. 搜索引擎的内嵌者：ParadeDB & pg_search

Elasticsearch很强大，但维护一套独立的ES集群加上数据同步，实在太累了。ParadeDB 想做的，就是让你在PostgreSQL里直接享受到全文搜索和向量搜索的顶级体验 。

它的核心扩展 pg_search，完全基于Rust编写。

• Rust在这里做了什么？ParadeDB底层并没有重复造轮子，而是站在了巨人的肩膀上——Tantivy。Tantivy是Rust生态中号称“比Lucene还快”的全文搜索引擎库 。通过 pgrx 框架，ParadeDB将Tantivy的能力编译成PostgreSQL扩展。

  • 结果：你现在可以在PostgreSQL中执行复杂的全文检索，甚至混合向量搜索（用于AI），性能比原生的文本搜索高出几个数量级，而且数据不用搬家。

4. 扩展开发的革命：pgrx

刚才提到的ParadeDB能诞生，离不开 pgrx 这个神级框架 。

以前，写PostgreSQL扩展只能用C，那难度和风险，懂的都懂。pgrx 允许你用Rust写扩展，它像一个魔法师，帮你处理了所有与PostgreSQL C ABI（应用二进制接口）交互的脏活累活。

• Rust在这里做了什么？你只需要写Rust函数，加上 #[pg_extern] 注解，pgrx 就会自动生成对应的SQL脚本和二进制库文件。它还提供了安全的SPI（服务器编程接口）调用，让你能安全地在Rust代码中执行SQL。

  • 结果：PostgreSQL扩展开发的难度从“地狱级”降到了“愉悦级”。这也解释了为什么现在新出的优质扩展（如向量搜索、新型索引）几乎都是Rust写的。

5. 内部的未来：PL/Rust

这是最激进的一层——不仅扩展用Rust，连存储过程都用Rust写。

传统的PL/pgSQL适合简单逻辑，一复杂就性能崩盘。PL/Rust 允许你将Rust代码编译成原生机器码，作为数据库函数运行 。

• Rust在这里做了什么？它提供了一个安全的沙箱环境，防止Rust代码搞崩整个数据库后台进程。由于是原生执行，复杂计算逻辑的速度比PL/pgSQL快几十倍。

  • 结果：未来，高并发的数据清洗、复杂的业务逻辑校验，可以直接下沉到数据库里用Rust函数执行，省去一层应用服务器的网络开销。

三、 开发者体验的降维打击

除了这些大型项目，Rust也在改变我们连接数据库的方式。

比如 SQLx，它是Rust生态中最受欢迎的数据库驱动之一 。它最酷的特性是编译时检查SQL语句。你在Rust代码里写的SELECT * FROM users WHERE id = $1，在cargo build的时候就会被拿到数据库去验证字段是否存在。这种“把错误扼杀在编译期”的体验，是动态语言无法想象的。

四、 总结：进化的不是语言，而是生态

回到我们最初的话题：Rust真的在“吃掉”PostgreSQL吗？

从字面上看，是的。存储层（Neon）、中间件层（PgDog）、能力层（ParadeDB）、开发层（pgrx），到处都有Rust的身影。

但从本质上讲，这其实是PostgreSQL生态的一次适应性进化。在AI浪潮和云原生架构的冲击下，传统数据库亟需更安全、更高性能、更易开发的“武器”来应对挑战。Rust恰好提供了这一切。

对于开发者来说，这是一个极好的时代：

• 我们依然可以使用标准的PostgreSQL协议和SQL。

• 但底层却享受着Rust带来的极致性能和云原生红利。

就像当年Java成就了Linux企业级应用一样，今天，Rust正在把PostgreSQL推向下一个黄金十年。

作为开发者，是时候关注一下这些Rust生态下的PostgreSQL项目了。也许在不久的将来，你手上的下一个数据库，就是用Rust扩展支撑起AI搜索和亿级并发的。