Hacker News 热议：PostgreSQL 线程模型与扩展能力，哪个更有用？

由 John Doe 七月 20, 2026

最近数据库圈最火的话题，莫过于用 Rust 重写 PostgreSQL 的 pgrust 项目。Hacker News 热议：线程模型与扩展能力，哪个更加有用？

这是 Hacker News 上一场针对 “使用 LLM 辅助将 PostgreSQL 用 Rust 语言重写” 的热门讨论。项目作者（malisper）指出，这个新架构通过引入“每连接单线程（Thread-per-connection）”模型，在事务工作负载上比原生 Postgres 快 50%，在分析型工作负载上快约 300 倍（接近 ClickHouse 的性能），且通过了 100% 的回归测试。

以下是 Hacker News 讨论帖中的相关内容：

核心共识

1. 多线程模型能显著降低开发并行查询的复杂度： 讨论者普遍认同，在原生 Postgres 的多进程模型中，编写使用共享内存的代码极其繁琐。在进行并行查询（如并行哈希连接）时，进程间无法直接传递指针，只能复制数据或传递偏移量，这带来了巨大的开销。而线程模型能更轻易地利用并行性来提升性能。

2. 原生 Postgres 的多进程架构在现代面临瓶颈： 即使有人认为进程和线程在系统底层（如 Linux）的上下文切换开销差异不大，但为了实现现代 OLAP（分析型）数据库的极致性能，抛弃历史包袱、转向多线程/混合模型是必然的技术演进方向。

主要反对观点

1. 隔离性与安全性（进程隔离 vs 线程崩溃）：

反对者观点： 原生 Postgres 的“每连接单进程（Process-per-connection）”设计能够有效防止那些“粗制滥造的第三方扩展（Sketchy extensions）”因为段错误（Segfault）而让整个数据库崩溃。如果在单进程多线程模型中，一个线程内的扩展发生内存越界或崩溃，将直接导致整个数据库实例宕机，数据损坏风险骤增。

作者与支持者的反驳： 事实上，原生 Postgres 为了保护共享内存（Shared memory），如果某个子进程异常终止，主进程（Postmaster）依然会杀死所有其他进程并进入恢复模式（回放 WAL），期间拒绝连接。因此，即使是进程模型，也避免不了全局中断（类似于一次在线重启）。

2. 对 LLM 生成核心系统代码的质疑：

资深数据库开发者（如 brianaker）提出质疑：“拥有食材并不意味着炖出来的汤就能喝”。他们不相信现阶段的 LLM 能够独自应对完整的 SQL 解析器构建以及数据库系统底层错综复杂的工程设计。由“直觉（Vibe-generated）”生成的代码在缺乏严格隔离机制时，难以用于容错要求极高的数据库底层。

3. 生态兼容性与重写成本：

Postgres 强大的原因在于其生态。许多用 C 语言编写的现有扩展内部依赖了全局状态或缺乏锁保护机制。如果底层换成多线程，这些扩展不仅无法直接运行，且用 Rust 重写（如使用 PGRX）也面临自定义内存分配器与 C++ 动态内存分配不兼容的物理限制。

用户分享的值得关注的真实场景案例

1. Informix 的“Data Blades”血泪史：

案例背景： 知名数据库先驱 Michael Stonebraker 曾主导过一个允许将自定义功能作为插件直接加载到数据库引擎中的特性，在 Informix 中被称为“Data Blades”。

经验教训： 用户分享了这段历史教训——当时一个行为不良的 Data Blade 就能直接干掉整个商业数据库引擎，甚至导致商业公司的衰退。这证明了在缺乏足够沙盒隔离的情况下，让扩展代码与数据库核心共享内存/线程是一场灾难。

2. 生产环境中的 Postgres 崩溃恢复机制：

案例细节： 开发者分享了 Postgres 在生产中的实际行为。很多人误以为一个子进程 OOM 或崩溃只会断开那一个连接。实际上，由于防范共享内存被污染的机制，一旦一个进程被 SIGQUIT 杀死，Postgres 会立刻清空共享缓冲区，终止所有正在运行的事务，强制其他连接掉线，并回放 WAL 进行在线恢复。

3. 真实业务对扩展的依赖（如 TimescaleDB、pgvector）：

场景讨论： 一些用户表示业务上其实极少安装第三方扩展（可能最多装 1 个或完全不用），因此为了极致性能放弃扩展安全性是值得的。但另一些用户反驳，生产环境中常用的 TimescaleDB（时序数据库扩展）和 pgvector（AI 向量扩展）对于现代业务不可或缺。如果新架构无法安全兼容这些扩展，其实用性将大打折扣。

提出的替代方案： 针对生产场景，用户们探讨了通过 WebAssembly (WASM) 来沙盒化运行第三方扩展，或者限制只在只读副本（Read Replicas）上加载高风险扩展的妥协方案。

你们怎么看 “PostgreSQL 线程模型和扩展能力冲突的讨论” 这件事？欢迎在评论区聊聊你的观点。