PostgreSQL 的每一次版本迭代都为开发者和企业带来令人期待的技术突破。从去年发布的 PG 18 到即将到来的 PG 19新特性层出不穷——异步 I/O 让云上性能飞跃内核级 REPACK 解决表膨胀痛点图查询能力为 AI 时代铺路。但面对如此多的更新哪些特性真正值得关注企业什么时候该升级如何参与到这个充满活力的开源社区「YOLANDA 科技见闻」独家专访 HOW 2026开源生态大会暨 PostgreSQL 高峰论坛三位深耕 PG 多年的技术专家IvorySQL 专家顾问委员、PostgreSQL ACED、前阿里云数据库高级专家德哥云和恩墨高级数据库技术顾问、IvorySQL 专家顾问委员彭冲PostgreSQL ACE、PG 分会西安用户组主席杨向博墨创数迹创始人汪丹Yolanda主持共同为你解读 PG 18 的“真香”时刻前瞻 PG 19 的重磅更新并分享实用的企业升级策略与社区贡献指南。划重点PG 的每一次大版本发布都是令人惊喜的。它不是简单的修修补补而是有很多亮眼的新特性真实解决了很多痛点问题。PG 的进化不是激进的而是务实的。社区的严苛性保证了稳定性插件生态验证了需求内核化完成了收敛。这是 PG 独特的进化路径。PG 不会为了追求新特性而牺牲稳定性也不会因为保守而拒绝变化。其丰富插件的可扩展性优势让很多东西可以像搭积木一样实现。从 PG 18 的异步 I/O 支持、统计信息保留到 PG 19 的 REPACK 内核化、图查询引入我们看到了未来数据库的更多可能性。企业什么时候应该升级新版本没有最好的版本只有最合适的版本。不为升级而升级只为解决真问题。PG 社区开放包容社区贡献没有标准答案。从报 Bug 到写插件从文章分享到内核提交每一个声音都能成为 PG 进化的一部分。从小处着手向内核生长。PostgreSQL 18 回顾4 个“真香”特性01 支持异步 I/O让德哥觉得“真香”的第一个能力是 PG 18 支持了异步 I/O。现在很多数据库是跑在云上的云上数据库和线下部署完全是两回事。在本地部署中数据库直接访问 SSDI/O 延迟通常在微秒级别。但云上存储会用云盘云盘底层要通过网络去访问网络延迟相较于本地部署会高很多。像创建索引、垃圾回收、大表扫描、分析型查询等大 I/O 访问量操作在 PG 18 之前都使用同步 I/O数据库进程的大量时间都耗费在网络等待上。PG 18 支持异步 I/O 子系统改变了这个局面这些大 I/O 访问操作的性能提升立竿见影。02 保留统计信息德哥分享的第二个特性和大版本升级有关可能应用不多但非常有价值比如云厂商就会比较激进地提供大版本升级能力。一般来说大版本升级有两种方式一种是通过逻辑复制复制后做切换不过这种方式有比较严苛的适应场景要求所有表都要有主键同步过程中一些不可抗因素也会导致切换后数据不一致。另外一种是通过pg_upgrade直接导出元数据然后在大版本上面导入新的元数据这种方式被诟病的地方就是统计信息导不过去如果升级之后立马开放给用户使用执行计划就可能不准确。特别是如果遇到业务高峰或者有一些乱查询由于没有统计信息往往导致执行计划不准这种请求多起来的话很可能带来雪崩效应。PG 18 引入了保留统计信息的能力彻底解决了这个问题。执行计划不会因为升级而退化避免了“升级即事故”的风险这对于无法承受长时间维护窗口的企业级应用来说是一个质的飞跃。03 disabled_nodes精准控制执行计划向博分享了一个可能会被大家忽略掉、但站在 DBA 角度看非常有用的特性。具体来说就是 SQL 执行计划会跑偏这是一个让 DBA 很头疼的问题。怎么办呢对于一些可以改 SQL 的业务来说可以走逻辑优化的路径。但对于很多 SaaS 业务定制化 SQL 改不了一般就用 hint 提示的手段去做执行计划的修正。可能会遇到这样的场景当你指定一个表走更优的索引时有时会发现它不但没走索引反而走了顺序扫描。这个路径是怎么被选出来的PG 17 及以前版本通过disable_cost给一个路径的启动代价加上一个 100 亿的常量值以此来干预路径选择方式“粗暴且不优雅”当多个路径都被加上这个巨大的常量后原本差距明显的路径可能只相差 1%它们之间的相对差异反而变得模糊可能导致干预失效最终选错了路径。PG 18 完全去掉了disable_cost这个历史包袱把它转化成disabled_nodes一个 int 值默认为 0当你禁用一个设置时对应路径的 node 值加 1并且这个值会层层向上传递。这样就可以精确地比较不同路径的干预程度而不是依赖模糊的代价估算能更精准地控制执行计划。04 pg_overexplain诊断执行计划彭冲补充了一个和执行计划相关的特性这是 PG 18 引入的一个扩展功能pg_overexplain以一种更结构化、更精准的方式输出深藏在内核数据结构中的信息用来深度剖析优化器的内部决策过程做一些内核相关的优化可以帮助诊断执行计划。PostgreSQL 19 前瞻值得期待的更新对于 PG19德哥一直在跟进它的 Git 提交记录从 2600 多个 Commits 中筛选了好几道最开始筛出来 100 多个觉得都特别有价值德哥重点分享了几个对他来说冲击比较大的新能力。01 引入 REPACK CONCURRENTLY使用 PG 的一个痛点就是它的事务 ID 只有 32 位容易用完所以必须不断地做“冻结”操作。另外就是 PG 的存储引擎没有 Undo 回滚段所有垃圾都放在数据文件里和正常的数据放在一起就要不断地做垃圾回收。一旦表膨胀了就会很麻烦特别是在云服务里存储都得额外算钱那每月的账单就要滴血压缩膨胀空间就很关键。怎么办原来是通过第三方的pg_repack插件来解决PG 19 把REPACK CONCURRENTLY做到内核里来了。以后我们就可以很放心地使用REPACK CONCURRENTLY了不用担心第三方工具的兼容和维护等问题这是一个极大的利好。02 实现“图查询”AI 时代图查询是一个非常重要的特性。比如我们使用 Agent 的时候使用越多它堆积的记忆就越多包括 Agent 去连接各种外部知识库这些数据也非常复杂。以前 PG 只能提供一些向量搜索、关键词搜索、全文检索但实际上来看知识很多时候是树状结构的也就是图结构。这时候很多企业可能会选择额外再搭一套图数据库就会导致一些数据可能是重复的浪费企业资源。PG 19 终于把图查询的功能引进来了在 AI 场景存储记忆、存储外部知识库这是一个很有必要的、很高级功能。德哥相信将来的 AI 应用在使用数据库的时候都可能把这块功能给用起来。03 standby 上支持 WAIT FOR比如读写分离场景当业务要求只读查询和之前写入变更的事务之间必须有一个前后顺序很多时候我们的查询不能发到只读库因为不知道只读库回放到什么时候了有没有把之前的修改回放过去这种情况下压力还是得压到主节点。PG 19 有了WAIT FOR当我们做读写分离的时候可以先做预判判断一个只读节点是否已经同步了之前写入的事务检查回放进度 LSN回放到了就把后面的请求转发给这些只读节点。这是一个很好的特性值得我们持续关注后续应用。04 一些“补丁”能力VACUUM 性能优化和逻辑复制功能完善当一个表有很多索引时特别是大表以前每个索引是顺序地一个一个做垃圾回收PG 19 的autovacuum可以并行地对多个索引同时做垃圾回收这能大大缩短垃圾回收的总时间。对于逻辑复制功能不支持复制序列SEQUENCE在 PG 19 里这个功能也补充上了。企业升级策略痛点驱动升级PG 19 要来了不过很多用户使用比较多的版本还是 PG16、PG17大家对于新版本用得还不多毕竟在生产环境下需要一个小心谨慎的态度。具体什么时候应该升级怎么用好新版本的能力三位专家也根据具体场景给出了一些升级建议。场景 1云部署 大 I/O 操作如果你的数据库跑在云盘上且有频繁的索引创建、垃圾回收、大表扫描建议升级 PG 18异步 I/O 带来巨大的性能提升场景 2表膨胀困扰如果你的表经常膨胀存储成本高查询性能下降建议等待 PG 19内核级 REPACK 更稳定更放心场景 3信创 跨 CPU 架构如果你有信创需求需要在 ARM 和 x86 之间做流复制或迁移建议升级 PG 17/18提供内置的字符比较、排序比较兼容性处理场景 4: AI 应用Agent 知识图谱如果你在构建 AI Agent需要存储记忆、知识图谱需要单独维护图数据库数据同步复杂建议等待 PG 19图查询是标配能力原生支持图查询统一数据平面具体场景挑战很多比如逻辑复制引起磁盘堆积问题、数据库拷贝难题、外部表安全问题等等根据自身业务的痛点和 PG 版本能力做匹配是一种可靠的判断逻辑。另外对于升级原则德哥还分享了一个他的思路。对于相对传统一点的企业如果业务迭代速度或者变化节奏不是特别快不用太着急去升级遇到特别大的痛点新版本能很好解决这时候再考虑升级。对于业务本身变化极快的企业可以考虑更快地使用新版本带来的新特性比如 PG 19 的图查询能力可以给 AI Agent 相关的业务带来极大助力帮助提升应用的竞争力那就可以偏激进一点去使用新版本。多元的社区贡献指南成长于社区贡献于社区PG 社区对新人非常友好包容性强那如何更好地在社区做共享怎样参与到 PG 下一个版本的新特性开发中三位深耕于 PG 社区多年的专家分享了他们的经验与建议。从报 Bug 开始从使用者的角度如果发现了 Bug直接在 PG 官网按照模板提交。重要提醒一定要写清楚信息包括详细的环境信息比如版本号、操作系统、硬件配置这个问题你是怎么复现的等等。如果只是填了一段报错上去沟通效率会比较低。写插件一上来就参加内核贡献门槛还是稍微高了一点。PG 的插件生态非常广可以从插件入手。有什么好点子或者在使用过程中遇到了一些问题也许写插件就能解决那就先快速写出来也可以利用好 AI 工具来帮助实现。比如可以写一些巡检脚本或者写一些 Skills。等插件成熟了社区可能会考虑将其引入内核。写文章做分享写文章也是贡献比如可以从实际的案例出发分享故障解决经验、自己的思考和心得等等。内核贡献三步法第一步观察社区的沟通方式。先去邮件列表里边看大家是怎样交流沟通的了解 Bug List观察代码风格把这个流程或者大家的习惯梳理清楚。第二步从小问题入手。可以从社区现有的 Bug List 里找痛点先去解决好一个具体的小问题。第三步大胆提交接受反馈。PG 社区对新手特别友好大佬们非常包容不过 PG 的代码审查很严苛要有心理准备被拒绝是正常的每一次反馈都是学习机会。结语PostgreSQL 的进化哲学从 PG 18 到 PG 19PostgreSQL 的每一个特性都经历了反复讨论与充分验证。PG 不追求激进的创新而是在稳定性的基石上稳步演进至最佳实践。这种务实的进化哲学或许正是 AI 时代我们真正需要的。PG 19 将成为一个新的起点未来AI 时代下数据库的更多可能性、更令人激动的篇章值得共同期待。
PG19 要来了！内核级 REPACK + 原生图查询，HOW2026 大咖提前剧透
发布时间：2026/6/5 4:47:07
PostgreSQL 的每一次版本迭代都为开发者和企业带来令人期待的技术突破。从去年发布的 PG 18 到即将到来的 PG 19新特性层出不穷——异步 I/O 让云上性能飞跃内核级 REPACK 解决表膨胀痛点图查询能力为 AI 时代铺路。但面对如此多的更新哪些特性真正值得关注企业什么时候该升级如何参与到这个充满活力的开源社区「YOLANDA 科技见闻」独家专访 HOW 2026开源生态大会暨 PostgreSQL 高峰论坛三位深耕 PG 多年的技术专家IvorySQL 专家顾问委员、PostgreSQL ACED、前阿里云数据库高级专家德哥云和恩墨高级数据库技术顾问、IvorySQL 专家顾问委员彭冲PostgreSQL ACE、PG 分会西安用户组主席杨向博墨创数迹创始人汪丹Yolanda主持共同为你解读 PG 18 的“真香”时刻前瞻 PG 19 的重磅更新并分享实用的企业升级策略与社区贡献指南。划重点PG 的每一次大版本发布都是令人惊喜的。它不是简单的修修补补而是有很多亮眼的新特性真实解决了很多痛点问题。PG 的进化不是激进的而是务实的。社区的严苛性保证了稳定性插件生态验证了需求内核化完成了收敛。这是 PG 独特的进化路径。PG 不会为了追求新特性而牺牲稳定性也不会因为保守而拒绝变化。其丰富插件的可扩展性优势让很多东西可以像搭积木一样实现。从 PG 18 的异步 I/O 支持、统计信息保留到 PG 19 的 REPACK 内核化、图查询引入我们看到了未来数据库的更多可能性。企业什么时候应该升级新版本没有最好的版本只有最合适的版本。不为升级而升级只为解决真问题。PG 社区开放包容社区贡献没有标准答案。从报 Bug 到写插件从文章分享到内核提交每一个声音都能成为 PG 进化的一部分。从小处着手向内核生长。PostgreSQL 18 回顾4 个“真香”特性01 支持异步 I/O让德哥觉得“真香”的第一个能力是 PG 18 支持了异步 I/O。现在很多数据库是跑在云上的云上数据库和线下部署完全是两回事。在本地部署中数据库直接访问 SSDI/O 延迟通常在微秒级别。但云上存储会用云盘云盘底层要通过网络去访问网络延迟相较于本地部署会高很多。像创建索引、垃圾回收、大表扫描、分析型查询等大 I/O 访问量操作在 PG 18 之前都使用同步 I/O数据库进程的大量时间都耗费在网络等待上。PG 18 支持异步 I/O 子系统改变了这个局面这些大 I/O 访问操作的性能提升立竿见影。02 保留统计信息德哥分享的第二个特性和大版本升级有关可能应用不多但非常有价值比如云厂商就会比较激进地提供大版本升级能力。一般来说大版本升级有两种方式一种是通过逻辑复制复制后做切换不过这种方式有比较严苛的适应场景要求所有表都要有主键同步过程中一些不可抗因素也会导致切换后数据不一致。另外一种是通过pg_upgrade直接导出元数据然后在大版本上面导入新的元数据这种方式被诟病的地方就是统计信息导不过去如果升级之后立马开放给用户使用执行计划就可能不准确。特别是如果遇到业务高峰或者有一些乱查询由于没有统计信息往往导致执行计划不准这种请求多起来的话很可能带来雪崩效应。PG 18 引入了保留统计信息的能力彻底解决了这个问题。执行计划不会因为升级而退化避免了“升级即事故”的风险这对于无法承受长时间维护窗口的企业级应用来说是一个质的飞跃。03 disabled_nodes精准控制执行计划向博分享了一个可能会被大家忽略掉、但站在 DBA 角度看非常有用的特性。具体来说就是 SQL 执行计划会跑偏这是一个让 DBA 很头疼的问题。怎么办呢对于一些可以改 SQL 的业务来说可以走逻辑优化的路径。但对于很多 SaaS 业务定制化 SQL 改不了一般就用 hint 提示的手段去做执行计划的修正。可能会遇到这样的场景当你指定一个表走更优的索引时有时会发现它不但没走索引反而走了顺序扫描。这个路径是怎么被选出来的PG 17 及以前版本通过disable_cost给一个路径的启动代价加上一个 100 亿的常量值以此来干预路径选择方式“粗暴且不优雅”当多个路径都被加上这个巨大的常量后原本差距明显的路径可能只相差 1%它们之间的相对差异反而变得模糊可能导致干预失效最终选错了路径。PG 18 完全去掉了disable_cost这个历史包袱把它转化成disabled_nodes一个 int 值默认为 0当你禁用一个设置时对应路径的 node 值加 1并且这个值会层层向上传递。这样就可以精确地比较不同路径的干预程度而不是依赖模糊的代价估算能更精准地控制执行计划。04 pg_overexplain诊断执行计划彭冲补充了一个和执行计划相关的特性这是 PG 18 引入的一个扩展功能pg_overexplain以一种更结构化、更精准的方式输出深藏在内核数据结构中的信息用来深度剖析优化器的内部决策过程做一些内核相关的优化可以帮助诊断执行计划。PostgreSQL 19 前瞻值得期待的更新对于 PG19德哥一直在跟进它的 Git 提交记录从 2600 多个 Commits 中筛选了好几道最开始筛出来 100 多个觉得都特别有价值德哥重点分享了几个对他来说冲击比较大的新能力。01 引入 REPACK CONCURRENTLY使用 PG 的一个痛点就是它的事务 ID 只有 32 位容易用完所以必须不断地做“冻结”操作。另外就是 PG 的存储引擎没有 Undo 回滚段所有垃圾都放在数据文件里和正常的数据放在一起就要不断地做垃圾回收。一旦表膨胀了就会很麻烦特别是在云服务里存储都得额外算钱那每月的账单就要滴血压缩膨胀空间就很关键。怎么办原来是通过第三方的pg_repack插件来解决PG 19 把REPACK CONCURRENTLY做到内核里来了。以后我们就可以很放心地使用REPACK CONCURRENTLY了不用担心第三方工具的兼容和维护等问题这是一个极大的利好。02 实现“图查询”AI 时代图查询是一个非常重要的特性。比如我们使用 Agent 的时候使用越多它堆积的记忆就越多包括 Agent 去连接各种外部知识库这些数据也非常复杂。以前 PG 只能提供一些向量搜索、关键词搜索、全文检索但实际上来看知识很多时候是树状结构的也就是图结构。这时候很多企业可能会选择额外再搭一套图数据库就会导致一些数据可能是重复的浪费企业资源。PG 19 终于把图查询的功能引进来了在 AI 场景存储记忆、存储外部知识库这是一个很有必要的、很高级功能。德哥相信将来的 AI 应用在使用数据库的时候都可能把这块功能给用起来。03 standby 上支持 WAIT FOR比如读写分离场景当业务要求只读查询和之前写入变更的事务之间必须有一个前后顺序很多时候我们的查询不能发到只读库因为不知道只读库回放到什么时候了有没有把之前的修改回放过去这种情况下压力还是得压到主节点。PG 19 有了WAIT FOR当我们做读写分离的时候可以先做预判判断一个只读节点是否已经同步了之前写入的事务检查回放进度 LSN回放到了就把后面的请求转发给这些只读节点。这是一个很好的特性值得我们持续关注后续应用。04 一些“补丁”能力VACUUM 性能优化和逻辑复制功能完善当一个表有很多索引时特别是大表以前每个索引是顺序地一个一个做垃圾回收PG 19 的autovacuum可以并行地对多个索引同时做垃圾回收这能大大缩短垃圾回收的总时间。对于逻辑复制功能不支持复制序列SEQUENCE在 PG 19 里这个功能也补充上了。企业升级策略痛点驱动升级PG 19 要来了不过很多用户使用比较多的版本还是 PG16、PG17大家对于新版本用得还不多毕竟在生产环境下需要一个小心谨慎的态度。具体什么时候应该升级怎么用好新版本的能力三位专家也根据具体场景给出了一些升级建议。场景 1云部署 大 I/O 操作如果你的数据库跑在云盘上且有频繁的索引创建、垃圾回收、大表扫描建议升级 PG 18异步 I/O 带来巨大的性能提升场景 2表膨胀困扰如果你的表经常膨胀存储成本高查询性能下降建议等待 PG 19内核级 REPACK 更稳定更放心场景 3信创 跨 CPU 架构如果你有信创需求需要在 ARM 和 x86 之间做流复制或迁移建议升级 PG 17/18提供内置的字符比较、排序比较兼容性处理场景 4: AI 应用Agent 知识图谱如果你在构建 AI Agent需要存储记忆、知识图谱需要单独维护图数据库数据同步复杂建议等待 PG 19图查询是标配能力原生支持图查询统一数据平面具体场景挑战很多比如逻辑复制引起磁盘堆积问题、数据库拷贝难题、外部表安全问题等等根据自身业务的痛点和 PG 版本能力做匹配是一种可靠的判断逻辑。另外对于升级原则德哥还分享了一个他的思路。对于相对传统一点的企业如果业务迭代速度或者变化节奏不是特别快不用太着急去升级遇到特别大的痛点新版本能很好解决这时候再考虑升级。对于业务本身变化极快的企业可以考虑更快地使用新版本带来的新特性比如 PG 19 的图查询能力可以给 AI Agent 相关的业务带来极大助力帮助提升应用的竞争力那就可以偏激进一点去使用新版本。多元的社区贡献指南成长于社区贡献于社区PG 社区对新人非常友好包容性强那如何更好地在社区做共享怎样参与到 PG 下一个版本的新特性开发中三位深耕于 PG 社区多年的专家分享了他们的经验与建议。从报 Bug 开始从使用者的角度如果发现了 Bug直接在 PG 官网按照模板提交。重要提醒一定要写清楚信息包括详细的环境信息比如版本号、操作系统、硬件配置这个问题你是怎么复现的等等。如果只是填了一段报错上去沟通效率会比较低。写插件一上来就参加内核贡献门槛还是稍微高了一点。PG 的插件生态非常广可以从插件入手。有什么好点子或者在使用过程中遇到了一些问题也许写插件就能解决那就先快速写出来也可以利用好 AI 工具来帮助实现。比如可以写一些巡检脚本或者写一些 Skills。等插件成熟了社区可能会考虑将其引入内核。写文章做分享写文章也是贡献比如可以从实际的案例出发分享故障解决经验、自己的思考和心得等等。内核贡献三步法第一步观察社区的沟通方式。先去邮件列表里边看大家是怎样交流沟通的了解 Bug List观察代码风格把这个流程或者大家的习惯梳理清楚。第二步从小问题入手。可以从社区现有的 Bug List 里找痛点先去解决好一个具体的小问题。第三步大胆提交接受反馈。PG 社区对新手特别友好大佬们非常包容不过 PG 的代码审查很严苛要有心理准备被拒绝是正常的每一次反馈都是学习机会。结语PostgreSQL 的进化哲学从 PG 18 到 PG 19PostgreSQL 的每一个特性都经历了反复讨论与充分验证。PG 不追求激进的创新而是在稳定性的基石上稳步演进至最佳实践。这种务实的进化哲学或许正是 AI 时代我们真正需要的。PG 19 将成为一个新的起点未来AI 时代下数据库的更多可能性、更令人激动的篇章值得共同期待。
