PostgreSQL 未来发展路线和方向

PostgreSQL（简称 Postgres）目前已进入发展的第30个年头。在早期，社区主要致力于补齐崩溃恢复、时间点恢复（PITR）、物理与逻辑复制等重大基础功能。如今，内核缺失的功能绝大多数都集中在性能优化（单机与多机横向扩展性能）上。Postgres 发展极其迅速，平均每年引入约 200 个新特性（例如正在推出的 Postgres 19 包含约 212 个特性）。

目录

核心缺失功能详解：优势、劣势与社区现状

在 Postgres 语境下，“缺失（Missing）”指的是该功能未进入内核核心（Core），且未包含在自带的官方扩展/Contrib模块中。但这并不意味着该功能完全无法使用，许多缺失的功能已经在外部扩展或特定分支（Forks）中得以实现，并持续为内核内核的开发探索方向。

透明数据加密 (TDE / 文件集群加密)

• 定义：在操作系统/文件系统层面对数据文件和 WAL 文件进行内存级别的实时加密与解密（读时解密，写时加密）。
• 优势：
  • 满足外部合规与监管要求。
  • 避免了数据库团队与基础设施团队在存储级加密上复杂的协调成本。
  • 备份文件可自动实现加密。
• 劣势与为何缺失：实际安全价值有限。Postgres 社区极度关注技术本身的安全性，而 TDE 主要是外部合规驱动。在技术层面上，如果黑客已经获得了访问操作系统的权限（如 root 或 postgres 用户），他们可以利用 GDB 等工具轻松从运行中的 Postgres 进程内存中 dump 出加密密钥，从而使文件加密失效。此外，它需要海量的代码改动（需要加密散落在各处的临时文件），且社区认为客户端加密（Client-side Encryption）才是更安全的终极方案。
• 现状：Percona 正在开发一个需要配合其特定分支的开源外部扩展；EDB、富士通（Fujitsu）、Cybertech、Crunchy Data 等商业公司由于更贴近客户的合规需求，已在其各自的商业分支中支持了 TDE。

64 位事务 ID

• 定义：将目前使用的 32 位事务 ID 替换为 64 位，以彻底解决事务 ID 回回绕（Wraparound）问题。
• 优势：消除回绕风险；高并发或极大数据量的业务无需频繁执行 Vacuum Freeze 操作，从而节省大量的系统 I/O 资源。
• 劣势与技术挑战：每一行的行头（Header）大小将增加 50%（因为增加了三个 32 位字段），这会导致明显的内存压力，并导致某些工作负载变慢。
• 替代方案与现状：社区目前正在积极讨论和尝试“页级 LSN Epoch”方案——即让同一页中的所有行共享相同的 Epoch，从而在不明显膨胀行头的前提下解决该问题。目前 Postgres Pro 和 Redrock Postgres 都已成功实现了 64 位事务 ID 并在生产环境中验证；此外，Toast ID 目前也面临着类似的 32 位瓶颈。

优化器提示 (Optimizer Hints)

• 定义：通过在 SQL 注释中加入特定指令（如 Oracle 风格的 Hints）来强制指定查询计划。
• 优势：当生产环境的查询计划突然发生非预期改变（Flipping）时，可作为快速、紧急的应急修复手段。
• 劣势：固化了查询计划。这导致数据库在数据量发生重大变化、或者新版本优化器性能提升时，无法自动切换到更好的执行计划。同时，它往往掩盖了根本问题（执行计划变差通常是因为缺失扩展统计信息、统计目标过低、或者 random_page_cost 等参数配置不当）。
• 现状：外部扩展 pg_hint_plan 已存在很久（支持 Oracle 风格提示）。Postgres 19 引入了 pg_plan_advice，它提供了一种更集中、更整体的方式来收集和管理优化器引导，允许管理员在不修改和重新编译应用代码的前提下，从全局控制和稳定执行计划。

列式存储 (Columnar Storage)

• 定义：将数据按列（而非传统的按行）进行物理组织与存储。
• 优势：极其适合数据分析（OLAP）、数据仓库和日志表等唯一值较少（重复率高）的场景，具备极高的压缩比和高带宽查询性能。
• 劣势：重构单行数据（Tuple）的成本极高；更新（Update）和删除（Delete）操作极其昂贵；需要对优化器和执行器进行颠覆性改造（必须引入批量执行器/Pipelining 架构，而非一次处理一行）。
• 现状：Citus 作为外部扩展提供了该能力。由于此前提交的内核补丁几乎将整个优化器代码复制并重写了一遍，因此被社区拒绝。目前 Crunchy Data、EDB 等公司正在通过开发对接 Apache Iceberg 等外部数据湖的表访问方法（Table Access Methods）来曲线解决该需求。

全局索引 (Global Indexes)

• 定义：在分区表（Partitioned Table）的整体层次上建立索引，而不是在每个子分区上建立局部索引。
• 优势：允许对非分区键的列建立唯一性约束（Unique Constraints）；在跨分区查询非分区键列时，无需扫描所有子分区的局部索引。
• 劣势：会生成一个极其巨大的索引，这直接违背了“为了保持单表和索引足够小、便于快速删除”而引入分区的初衷。此外，删除分区时清理全局索引的成本极其高昂。
• 现状：目前处于评估阶段。从其他关系型数据库的生产经验来看，全局索引往往会因体积过大而变得极慢，许多用户最终在生产中不得不将其移除。

直接 I/O (Direct I/O)

• 定义：在读写共享缓冲区（Shared Buffer Cache）时直接绕过操作系统的文件系统缓存（内核缓存）。
• 优势：防止双重缓存（Double Buffering）造成的内存浪费；消除内核空间到用户空间的数据复制成本；可以消减 WAL 的全页写入（Full Page Images），从而解决 Torn Page Writes（页面撕裂写入）问题。
• 劣势：绕过内核意味着操作系统无法再对读写进行动态合并（Batch/Aggregate）。此外，它会让数据库在面对内存调优失误时更加脆弱——如果 shared_buffers 或 work_mem 配置不当，系统将直接承受极大的性能惩罚，失去了操作系统缓存作为安全缓冲垫的作用。
• 现状：Postgres 19 引入了一些相关底座改进，未来将逐步导向完整的 Direct I/O 支持（社区核心成员 Andres Freund 正在推进相关工作），这也依赖于未来支持可动态调整大小的共享缓冲区。

线程化架构 (Threaded Postgres)

• 定义：将 Postgres 从目前的多进程架构重构为多线程架构。
• 优势：减少线程/进程上下文切换的开销；无需传统繁琐的共享内存段（Shared Memory Segments）；大幅改善在 Windows 平台（进程创建极其缓慢）上的性能；能更轻松地实现内置连接池。
• 劣势：降低了会话隔离的鲁棒性。目前的多进程架构下，单个后端会话崩溃绝不会影响其他进程；而在线程模型中，一个线程的内存损坏极易导致整个数据库实例崩溃。重构需要修改海量的核心代码。
• 现状：社区正在进行长期的架构讨论，但推进速度较为缓慢。

内置连接池

• 定义：将连接池功能直接集成到 Postgres 内部。
• 优势：消除了经过外部连接池（如 PgBouncer）引入的网络延迟；彻底解决了中间人代理机制给身份验证（Authentication）带来的复杂性；简化了整体运维架构。
• 劣势：外部连接池更有利于高可用故障切换（Failover）控制（如果连接池内置，一旦 Postgres 实例崩溃，连接池也会一同消失）。
• 现状：已列入长期路线图，但其实施很大程度上依赖于线程化架构的进展。目前生产环境仍需依赖外部的 PgBouncer 或 Pgpool-II。

类似 Oracle RAC 的共享存储多活集群

• 定义：多个计算节点同时作为 Master 节点，读写同一个底层共享存储。
• 结论：Postgres 明确不打算支持该架构（红灯区域）。虽然该架构能很好地扩展 CPU 和内存，但它无法扩展 I/O（所有节点都在写入同一个存储）。它会引入极其恐怖的节点间通信与分布式锁开销，且需要严格隔离工作负载以减少冲突。这种 80-90 年代的复杂陈旧架构极度脆弱，Postgres 坚定选择“无共享架构（Shared-Nothing Architecture）”，因其具备更高的弹性和横向扩展能力。

多主复制与 DDL 复制

• 定义：支持多节点同时并发写入，并能动态复制 DML 与 DDL 变更。
• 优势：极大地简化了数据库的零停机维护、小版本及大版本无缝升级。
• 劣势与技术挑战：应用层面的冲突解决（Conflict Resolution）机制极度复杂。DDL 复制非常困难，因为必须确保系统目录（System Catalog）在并发事务执行期间能够安全地进行动态变更，当前的逻辑复制在遇到 DDL 变更时极易中断。
• 现状：市场上存在成熟的商业/外部解决方案（如 PG Edge、EDB Postgres Distributed）。社区正在逐步完善底层支持（如富士通正在推进 DDL 复制的相关高级内核补丁）。

分片 (Sharding)

• 定义：将数据物理打散并分布式存储在多台独立的服务器上。
• 优势：支持海量数据量与写入规模的横向扩展。
• 劣势：配置与管理极为繁琐，带来额外的分布式网络延迟。目前的内核缺乏原生的、能横跨多台服务器的分布式 MVCC 快照控制、分布式备份和完美的分布式提交机制。
• 现状：外部扩展如 Citus 提供了良好的支持。社区正在探索如何在不破坏 Postgres 核心 OLTP 优势的前提下，逐步增强内核的分布式联动能力。

开发结论与社区展望总结表

寄语：Postgres 在前30年交出了完美的答卷，在面对未来30年的技术演进中，社区将继续在保持核心架构优雅（不被特定小众需求扭曲）的前提下，通过可扩展机制（Extensions）与内核重构来逐步攻克这些性能顽疾。

参考

What’s Missing in Postgres? (PGConf.dev 2026)