转载说明：本文译自 Sylvain Kerkour 于 2026-03-11 发布的文章 Rust is slowly but surely eating PostgreSQL: Deep dive into Neon, ParadeDB, PgDog and more。本站版本基于原文完整翻译，统一了 Markdown 结构，图片已导入本地资源，并移除了原文末尾纯导流性质的推广段落。Rust 正在缓慢而坚定地“吃掉” PostgreSQL：深入看 Neon、ParadeDB、PgDog 等项目 多数人把 PostgreSQL 看成一个普通数据库，就像 MariaDB 或 ClickHouse 一样；但实际上，它已经演化成一个“数据内核”，负责管理数据如何存储、如何查询，就像 Linux 这个“计算内核”负责管理进程与系统资源一样。无论是主节点选举、混合搜索（全文 + 向量）、OLAP（时序分析）还是更多场景，Postgres 都受益于一个健康的扩展与 sidecar 生态，因此它很适合承载大多数，甚至可能是全部的工作负载。 正如我们上周在 这些年把 Rust 和 Postgres 用在一切事情上的经验模式 一文中看到的那样，Postgres 和 Rust 可谓天作之合，而且这还不止体现在应用层。Rust 同样是扩展 Postgres 的理想工具。尽管这个数据平台的核心，也就是 PostgreSQL 本身，仍然是用 C 写的，但现在大多数扩展已经开始转向 Rust。 Postgres 生态通常可以分成三类扩展：直接运行在 Postgres 内部的扩展，通常用来增加 SQL 函数，或加入像易用分片、新型索引这类能力。能理解 Postgres 线协议的 sidecar，用来提供连接池、负载均衡、可观测性等能力。监听 Postgres 复制流的 sidecar，通常用在 CDC（Change Data Capture）和 ETL（Extract, Transform, Load）管道里，把数据发送到其他数据库或数据湖。 为什么会这样？它是怎么发生的？又意味着什么？下面来看。pgrx pgrx 的知名度不算高，但它很可能是整个生态里最重要的项目之一，因为它让开发者可以用安全、符合人体工学的 Rust 来编写 Postgres 扩展，而不必直接面对 C。 Image 1: pgrx pgrx 负责把 Postgres 类型映射到 Rust 类型，并提供把扩展接入 Postgres 内部机制所需的一整套能力。 我绝不会相信自己能用 C 写出什么严肃的软件，坑实在太多了；但有了 pgrx，我就能去写 Postgres 扩展，并把正确性更多地交给编译器和类型系统来保证。Wrappers Wrappers 是一个开发框架，也是一组 Postgres 的外部数据封装器。它允许开发者直接从 PostgreSQL 查询外部数据源。数据的真实来源仍然是这些外部系统，但你可以用熟悉的 SQL 接口去查询它们，并把它们和自己的数据直接做联接。 举个例子，你可以直接查询 Stripe 的数据，再和自己的用户表做联接：SELECT invoices.* FROM stripe.invoices INNER JOIN users ON stripe.invoices.customer = users.stripe_customer_id WHERE users.id = 123; 就我个人而言，我并不确信这会是生产环境里集成外部系统的最佳方式；不过如果我是在做原型，我肯定会考虑使用其中一些 wrapper。 更多信息可以看官方站点：https://fdw.devParadeDB：把 Elasticsearch 级别的搜索带进 Postgres ParadeDB 开发的 pg_search 是一个 Postgres 扩展，目标是把高质量、接近 Elasticsearch 的搜索能力直接带进 Postgres。它底层使用的是全文搜索引擎 Tantivy。 从 v0.14.0 开始，pg_search 原生接入了 Postgres 的块存储体系，这件事意义非常大，因为它带来了至少这些能力：集成 Postgres 预写日志（WAL），这是索引做物理复制的前提。支持崩溃恢复和时间点恢复。完整支持 Postgres 的 MVCC（多版本并发控制）。接入 Postgres 缓冲区缓存，并因此大幅提升索引创建速度和写入吞吐。 ParadeDB 和 pg_search 走的是类似 Timescale 的路线：通过接入 Postgres 的存储 API，在保留事务能力和运维简化这些 Postgres 原有优势的同时，把它变成一个具备 OLAP 能力的数据库，只不过这次针对的不是时序…