PG 30 年架构大拆解：进程模型是“稳如老狗”还是历史包袱？
一、活动概况
2026年7月29日（周三）19:00–20:30，由中国PG分会、IvorySQL社区与TechTalk技术交流社区联合主办的「三十而立・全球时刻——PG 30周年系列直播」第五期圆满举行。本期主题为 “PG架构的「永恒智慧」与「历史包袱」” 。
本期原定嘉宾熊灿灿因临时赶飞机未能出席，冯若航与付超两位老师补位加入讨论，共六位嘉宾同台。主持人尚雷与五位嘉宾——德哥、吕海波、冯若航、杨向博、付超——围绕PostgreSQL三十年的架构设计，从进程模型到扩展生态、从MVCC到历史包袱，展开了一场不回避争议、不唱赞歌的深度对话。
二、嘉宾阵容
- 主持人：尚雷：PG & Oracle ACE、IvorySQL 专家顾问委员、PG 分会南京分会会长、TechTalk 技术交流社区主理人（公众号：尚雷的驿站）。
- 德哥 ：IvorySQL 专家顾问委员、PostgreSQL ACED、前阿里云数据库高级专家（公众号：digoal 德哥）。
- 吕海波：北京大学企业导师，易景科技首席研究员。PostgreSQL ACE Director，从事IT技术工作30年，曾就职于阿里巴巴、京东、eBay/PayPal等知名科技企业，连续5年为北大硕士研究生讲授数据库内核架构与开发（公众号：IT知识刺客）。
- 冯若航：独立开源贡献者，Pigsty 作者，IvorySQL 专家顾问委员（公众号：老冯云数）。
- 杨向博：PostgreSQL ACE，PG 分会西安用户组负责人（公众号：PostgreSQL 运维之道）。
- 付超：Oracle ACE 与 PostgreSQL ACE 双认证专家，PG 分会西安用户组核心成员。长期从事数据库运维与技术布道工作，具备 Oracle OCM、Kubernetes CKS 等多项认证（公众号：ByteHouse）。
三、直播内容回顾
板块一：进程模型——是Unix哲学还是历史包袱？
讨论从PG最核心的架构特征——多进程模型展开。PG诞生于1986年，彼时Linux线程库尚未出现（1995年才问世），采用多进程是自然的技术选择。
进程模型的代价。 讨论指出，短连接场景是进程模型的“死穴”——每次连接都fork一个进程，创建开销极大，高并发下性能急剧下降，这也是PG长期被诟病“高并发不行”的主要原因之一。
进程模型的优势。 隔离性极高，单个进程崩溃不会影响整个数据库，这也是PG“稳如老狗”口碑的底层支撑。
关于进程与线程的性能差异。 讨论从操作系统底层进行分析：进程与线程在Linux内核层面最终都调用clone系统调用，真正可能产生性能差异的地方是TLB（页表缓存）——线程共享页表，命中率略高，但实测表明这种差异对数据库整体性能影响不大。讨论给出的结论是：单纯从“改线程就能大幅提升性能”的角度来看，收益并不足以支撑架构层面的重构。
PG不改为多线程的核心障碍。 讨论认为，技术原因并非关键，真正的壁垒在于扩展生态。PG的整个扩展机制建立在“每个扩展有自己独立的进程和全局变量”这一假设之上。一旦改为多线程，大量依赖全局状态的扩展将全部失效，重构成本极高。“让所有扩展作者跟着一起改，是一个几乎不可能完成的任务。” 在并行查询场景下，多进程确实带来了数据拷贝开销，但这只是特定场景下的局部问题，不足以推翻整个架构。
进程模型在云原生时代的处境。 讨论也承认，PG的进程模型在容器化时代确实面临一些尴尬——进程是主机级别的资源，而容器追求隔离轻量，两者之间存在一定的“阻抗不匹配”。
板块二：扩展机制——PG最伟大的设计
与进程模型引发的争议不同，扩展机制是全场共识度最高的“永恒智慧”。
索引访问方法：最出彩的设计。 讨论指出，PG最精彩的设计是允许自定义索引访问方法（Index Access Method） 。正因如此，PG才能支撑PostGIS的空间索引、向量数据库的HNSW索引、全文检索的GIN索引——这些都不是内核原生功能，而是通过扩展机制实现的。在PG的10个可扩展维度中，它占了9个，唯一不能定制的是语法。
pgvector该不该进内核？ 这是讨论中一个极具张力的争议话题。针对社区有人提议将pgvector纳入PG内核的动议，讨论给出了明确的反对理由：
第一，向量技术远未定型。 这个领域还在快速迭代，作为扩展可以快速发版本、快速试错；一旦入核就要走严格的内核审查流程，响应速度会慢很多。
第二，存在比pgvector更强的扩展。 有第三方向量扩展在某些场景下比pgvector快100倍。如果把pgvector放进内核，对其他做得更好的扩展并不公平。
第三，入核意味着维护责任转移。 原来扩展作者自己维护，想怎么迭代都行；入核后维护负担转移给内核团队。
讨论给出的判断标准是：是否有SQL标准。图数据库有可能进入内核，是因为有SQL/PGQ标准；向量领域目前还没有统一标准，所以暂时不适合入核。核心原则是：“扩展能搞定的就不该进内核。”
扩展的安全与选型。 讨论中分享了一个PG扩展百科项目，收录了超过2000个PG扩展。其中真正达到生产质量的扩展大概只有一两百个。T0级必装扩展包括PostGIS、TimescaleDB、Citus、pgvector四大功能扩展，以及pg_stat_statements、pg_qualstats、explain、wal2json等运维诊断扩展。
云厂商扩展受限的原因。 讨论从三个方面进行了分析：安全性（很多扩展需要superuser权限）、许可证（AGPL协议的扩展云厂商无法提供）、运维复杂度（扩展升级困难，如TimescaleDB无法直接通过逻辑复制做蓝绿部署）。
板块三：MVCC——伟大但痛苦的设计
MVCC为什么“伟大”。 MVCC（多版本并发控制）让PG实现了“读写互不阻塞” ——读操作永远不会被写操作阻塞。讨论指出，原地更新和追加写是数据库诞生之初就存在的两条不同技术路线，不存在谁对谁错。在时序数据、区块链等以追加写为主的场景中，PG的MVCC性能反而更好，批量导入可达数百万行每秒。
In-place Update与Out-of-place Update。 PG采用out-of-place update（追加写）、无UNDO的方式，与Oracle等数据库的in-place update（原地更新）加UNDO是数据库诞生之初就存在的两条不同技术路线。out-of-place update将“修改”变为“追加”，更新频繁时会产生表膨胀问题，而频繁的清理（Vacuum）又难免对正常操作产生影响。但out-of-place update的优势在于：Insert与Delete只需修改目标块，无需额外处理UNDO块——在区块链、时序数据等极少甚至没有Update的场景中，写入更快。两者并无绝对优劣之分。in-place update会对UNDO进行优化，缩小Insert、Delete与out-of-place update的差距；out-of-place update也会对“清理”进行优化，在对正常操作影响极小的情况下收缩表、缓解膨胀。长期使用某种数据库而主观地认为某一路线更优秀，都是片面的、有局限性的。
MVCC为什么“痛苦”。 代价是显而易见的：每个更新都会产生一个新版本的数据行，旧版本留在数据文件中等待回收——这就是表膨胀的根源。讨论直言：“只要用过PG的人，百分之百都会吐槽——更新多了之后，垃圾回收会带来很多负面影响。” 对云上用户来说，表膨胀还会直接变成账单问题——数据量大了，存储费用就上去了。
Vacuum调优的难点。 讨论认为vacuum调优没有银弹。大表需要调整vacuum_cost_delay等参数，默认值往往不够用。更麻烦的是长事务——如果一个事务长期未提交，它会阻止vacuum回收任何在该事务之后产生的垃圾版本。讨论给出的建议很务实：提前做好可观测性，不要等到磁盘写满了才去救火。
未来的改进方向。 PG 19已经原生支持了在线vacuum（pg_repack能力集成），这一问题正在逐步缓解。
板块四：历史包袱——哪些设计该退休了？
这是全场最“不唱赞歌”的环节——PG架构里最应该被重构、但一直没动的历史包袱是什么？
32位事务ID（XID）——最大的软肋。 讨论给出了最明确的答案：32位的XID是PG最大的历史包袱。PG的事务ID是32位，总共只有约21亿个。在高TPS场景下，一周多就能耗尽，必须依赖vacuum不断“冻结”旧事务来回收ID——让人时刻焦虑。虽然PG内部有64位XID的扩展机制，但数据页中存储的仍然是32位，要彻底改为64位涉及存储格式变更，改动量巨大。
PG是“优秀的内核”还是“糟糕的产品”？ 讨论提出了一个辩证的视角：PG在开箱即用方面确实有很多不足——链接池要自己搭、高可用要自己配、备份要自己攒。但从另一个角度看，这正是PG的哲学——把复杂度从内核外移到运维层。链接池的问题套个PgBouncer就解决了，高可用的问题用Patroni+etcd就搞定了。
存储引擎：为什么PG只有一个？ 讨论延伸到另一个经典问题：MySQL有多种存储引擎，PG为什么死守一个堆表？分析认为，PG的Table AM（表访问方法）抽象并没有想象中那么完美——它把行存的具体实现泄露了出来，确实阻碍了更多存储引擎的出现。但也有观点指出：MySQL号称有多种引擎，最后大家真正在用的，不也就一个InnoDB吗？
异步IO：补短板还是新方向？ PG 18引入了异步IO（AIO）支持。讨论认为异步IO之所以现在才出现，是因为时代变了——机械盘时代IO本身就是瓶颈，SSD时代IO不再是最突出的问题，而云盘时代网络延迟重新成为瓶颈，异步IO的价值才真正凸显。这一特性对AP分析型负载的利好大于OLTP，但至少让PG在做HTAP时性能更好。未来异步IO还可以用在更广泛的场景——比如写多个副本时做到“写一份的性能、多份的可靠性”。
四、总结
整场直播下来，一个贯穿始终的核心观点逐渐清晰：PG的架构哲学，是把复杂度从内核外移到了运维层。
- 进程模型有连接开销？——套个PgBouncer。
- 高可用要自己搭？——用Patroni+etcd。
- 备份恢复不够好用？——用pgBackRest。
- 32位XID让人焦虑？——做好监控和vacuum。
这种哲学让PG内核保持了极高的稳定性——“稳如老狗”。但代价是：PG不是一个开箱即用的产品，而是一个需要自己组装的内核。
在扩展机制上，PG选择了“内核稳定、生态灵活”的路线——通过强大的扩展能力满足各类新需求，经过场景验证后再考虑是否纳入内核。这使得PG既能保持内核的稳定可靠，又能跟上AI、向量等时代潮流。
关于历史包袱，32位XID是公认最需要解决的结构性问题。虽然短期可通过运维手段缓解，但根本解决仍需内核层面的重大重构。
展望未来，PG的扩展性使其在AI时代依然充满想象空间，但要在保持稳定的同时，逐步拆解那些已经拖累发展的历史包袱——这是PG下一个十年需要回答的问题。
活动播报
适逢 PostgreSQL 三十周年，PGConf.Asia 2026 香港站定于 11 月 17–18 日举办，大会面向全球征集 PG 实战技术分享并开放商业赞助合作，演讲提案征集 8 月 31 日截止。
更多资讯请点击：
浙公网安备 33010602011771号