每一个 PostgreSQL 版本似乎都有属于自己的“性格”。有些版本因某项重量级特性而被铭记，有些版本则解决了长期存在的核心痛点；还有一些版本，则通过大量细节优化，让升级后的日常使用体验变得更加顺畅。而几乎每一个 PostgreSQL 大版本发布，都会伴随着性能方面的持续提升。
PostgreSQL 19 更像是一个兼具多种特质的版本。内置的REPACK CONCURRENTLY为大型生产数据库带来了重要的运维体验提升，并且成为核心能力的一部分。与此同时，也不乏备受关注的重要特性，例如 SQL 属性图查询能力（SQL/PGQ）。逻辑复制持续完善，VACUUM、EXPLAIN、COPY、分区、监控、性能优化以及查询优化器等多个领域也迎来了稳步演进。这些改进或许不像某些明星特性那样耀眼，但对于生产环境而言，却意味着更加稳定、高效和易于维护的数据库系统。
与所有 Beta 版本一样，部分细节在正式发布前仍可能发生变化。不过，随着 PostgreSQL 19 Beta 的发布，现在已经是了解即将到来的变化，以及评估这些变化对生产环境影响的最佳时机。
开箱即用的 REPACK
对于长期运行 PostgreSQL 的系统而言，几乎都曾面临过表膨胀治理、表重写或者数据重组的需求。然而，VACUUM FULL或CLUSTER所需要持有的锁，往往意味着生产业务无法接受的停机窗口。
围绕这一问题，PostgreSQL 生态长期以来形成了成熟的扩展解决方案，其中最具代表性的便是pg_repack。扩展生态的繁荣本身便说明了一件事情：这一需求真实存在，并且足够重要。
PostgreSQL 19 将全新的REPACK命令正式纳入核心系统，同时支持REPACK CONCURRENTLY。对于生产环境用户而言，REPACK CONCURRENTLY很可能会成为一个比大多数发布说明阅读者预想中更加重要的特性。
分区功能变得更加实用
近年来，PostgreSQL 的分区能力取得了显著进步。从最初“理论上可用，但需要深入理解内部机制和各种限制条件”，逐渐演进为更加成熟且易于使用的能力。
PostgreSQL 19 在此基础上进一步增加了分区合并与分区拆分能力。这一变化看似简单，却解决了实际生产环境中的一个常见问题。
分区策略往往是在信息并不充分的情况下制定的。初期设计的分区方案可能适用于当前业务，但随着时间推移，业务负载可能发生变化，数据保留周期可能发生调整，数据增长速度可能超出预期，甚至部分分区可能变得异常庞大，而另外一些分区则非常小。
能够对分区进行拆分与合并，为数据库架构演进提供了更大的灵活性。
-- Combine Q1 and Q2 into a single partition ALTER TABLE customer_orders MERGE PARTITIONS (orders_2026_q1, orders_2026_q2) INTO orders_2026_h1;-- Split the Q3 partition into monthly intervals ALTER TABLE customer_orders SPLIT PARTITION orders_2026_q3 INTO ( PARTITION orders_2026_07 FOR VALUES FROM ('2026-07-01') TO ('2026-08-01'), PARTITION orders_2026_08 FOR VALUES FROM ('2026-08-01') TO ('2026-09-01'), PARTITION orders_2026_09 FOR VALUES FROM ('2026-09-01') TO ('2026-10-01') );优秀的数据库设计通常并非一成不变，而是能够随着业务持续演进。PostgreSQL 提供更多无需重建整个体系即可调整架构的能力，正是其长期适用于生产环境的重要原因之一。
逻辑复制持续成熟
逻辑复制已经成为 PostgreSQL 最近多个版本持续重点投入的领域之一。数据库迁移、版本升级、报表系统建设、数据同步、选择性复制，以及越来越多的高可用与运维场景，都在依赖逻辑复制能力。
PostgreSQL 19 在这一领域继续补齐关键能力。其中最重要的一项改进是：序列值（Sequence）开始支持同步。对于依赖序列生成主键的业务系统而言，仅同步数据而不同步序列状态，往往会在业务切换后带来问题。数据虽然已经同步完成，但下一个生成的 ID 却可能并不处于正确位置。
PostgreSQL 19 新增了序列同步能力，使订阅端能够更加准确地保持与发布端一致。除此之外，还新增了：
- Publication 支持
ALL SEQUENCES - 增强序列同步错误报告能力
- 优化订阅刷新过程中的序列处理逻辑
另一个值得关注的增强是：Publication 在发布全部表时支持使用EXCEPT子句排除指定表。这更加符合实际生产环境中的使用方式——通常需要同步“几乎所有数据”，但又希望排除少数特殊表。
此外，当需要逻辑复制能力时，wal_level=replica可以自动启用逻辑复制功能，同时新增effective_wal_level用于展示系统实际生效的 WAL 级别。这意味着更少的配置陷阱以及更高的系统可观测性。逻辑复制依然是一项复杂能力，但随着每个版本的演进，它正逐渐从一项高级特性成长为 PostgreSQL 标准运维工具集中的基础组成部分。
Autovacuum 变得更加智能，也更加可观测
VACUUM 可以说是 PostgreSQL 最具代表性的机制之一。很多系统在运行多年后，随着表膨胀、事务回卷风险或者查询性能波动的出现，才真正开始关注 VACUUM 的内部工作机制。
PostgreSQL 19 在这一领域带来了多项值得关注的增强。首先，Autovacuum 开始支持并行 Vacuum Worker，并支持全局和单表级别配置。对于大型表和大型索引而言，这意味着 PostgreSQL 在后台维护任务上的处理能力将进一步增强。
-- Allow up to 4 parallel workers globally for autovacuum processes ALTER SYSTEM SET autovacuum_max_parallel_workers = 4;同时，新版本引入了新的评分机制，用于控制 Autovacuum 的表处理顺序。这一能力十分重要，因为 Autovacuum 本质上始终在进行资源权衡：哪些表最需要优先处理，哪些任务应该稍后执行。更加智能的优先级排序，能够帮助系统在问题真正影响业务之前完成维护工作。
-- Adjust the priority scoring just for this table: -- Give insert-based vacuuming a massive urgency boost (3.0), -- while dropping the normal update/delete vacuum urgency (0.5) since rows are rarely deleted. ALTER TABLE application_logs SET ( autovacuum_vacuum_insert_score_weight = 3.0, autovacuum_vacuum_score_weight = 0.5 );除此之外，新版本还新增了pg_stat_autovacuum_scores视图，用于展示评分决策过程。同时，VACUUM 和 ANALYZE 进度视图中也增加了更多信息；VACUUM VERBOSE和 Autovacuum 日志中增加了内存使用情况和并行执行信息；此外，还新增了独立的log_autoanalyze_min_duration参数。
PostgreSQL 19 在维护能力上的一个重要主题，就是提升可观测性。数据库自动完成后台维护工作固然重要，而能够清晰解释这些工作为何发生、如何执行，则更加重要。
SQL 属性图查询正式进入 PostgreSQL
PostgreSQL 19 中最引人关注的新特性之一，便是 SQL/PGQ，即 SQL 属性图查询能力。图数据库在过去多年间经历过多次技术热潮，而某些业务场景确实非常适合采用顶点与边的建模方式，例如：
- 欺诈检测
- 推荐系统
- 网络分析
- 权限关系分析
- 供应链分析
- 组织架构分析
-- sample property graph CREATE PROPERTY GRAPH store_graph VERTEX TABLES ( customers LABEL customer, orders LABEL "order" ) EDGE TABLES ( customer_orders SOURCE customers DESTINATION orders LABEL placed_order );SQL/PGQ 最有价值的一点在于，它并没有要求放弃关系模型，而是在现有关系数据之上增加了一种新的查询方式。这也非常符合 PostgreSQL 一贯的发展路线。
JSONB 的出现并未取代关系表；全文检索能力并未要求部署独立搜索引擎；扩展机制也并不意味着需要维护数据库分支。如今，SQL/PGQ 为 PostgreSQL 增加了一种基于图结构理解关系数据的新视角。
真正值得关注的，并不是“PostgreSQL 成为了图数据库”，而是“已经选择的数据库平台变得更加全面”。这一差异虽然微妙，却十分重要。对于开发者而言，这意味着许多图查询场景未来可能无需引入新的数据库产品、同步链路以及额外的运维复杂度。而在生产环境中，更少的系统组件通常意味着更低的风险。
COPY 持续变得更加实用
COPY是 PostgreSQL 中一个低调但极其重要的功能。数据导入与导出几乎存在于所有业务场景，因此即使只是一些小幅优化，也能够带来显著价值。
PostgreSQL 19 为COPY带来了多项增强。首先，COPY FROM支持跳过多行 Header。这一能力在处理来自供应商系统、内部工具或者各种导出程序生成的 CSV 文件时非常实用，因为这些文件往往包含额外的元数据描述信息。同时，COPY FROM新增ON_ERROR SET_NULL选项，允许将非法输入自动转换为 NULL。这为“导入失败”和“提前完成全部数据清洗”之间提供了新的选择。
-- Imagine a file where a price column occasionally contains 'N/A' or 'MISSING' instead of a numeric value COPY product_catalog (product_id, title, price_usd) FROM '/path/to/dirty_products.csv' WITH ( FORMAT CSV, HEADER, ON_ERROR SET_NULL );此外，COPY TO开始支持 JSON 输出格式，包括直接输出为单个 JSON 数组。
-- Export an entire table directly into a cleanly formatted, valid JSON array COPY customers TO '/path/to/customers_export.json' WITH (FORMAT JSON, ARRAY true);与此同时，分区表也支持直接导出，而无需再通过 COPY (SELECT …) 实现。这些改进或许不会改变世界，但能够持续改善日常数据处理体验。
SQL 易用性改进
PostgreSQL 19 同样带来了多项开发者关注的 SQL 语法增强。GROUP BY ALL可以自动对所有非聚合、非窗口函数表达式进行分组。这对于探索性分析和报表查询场景而言，能够有效减少 SQL 编写复杂度。
-- Using GROUP BY ALL SELECT category, manufacturer, COUNT(*) as total_items, AVG(price) as avg_price FROM inventory_products GROUP BY ALL;窗口函数新增了IGNORE NULLS和RESPECT NULLS支持，包括：
lead()lag()first_value()last_value()nth_value()
对于时序分析场景中获取最近一个非空值的需求而言，这将极大简化实现方式。
INSERT ... ON CONFLICT DO SELECT ... RETURNING同样是一个非常实用的增强。Upsert 已经成为现代应用开发中的常见模式，而能够直接返回冲突记录，则进一步提升了灵活性。
INSERT INTO tags (tag_name) VALUES ('postgres') ON CONFLICT (tag_name) DO SELECT RETURNING tag_id;此外，PostgreSQL 还新增了UPDATE FOR PORTION OF和DELETE FOR PORTION OF，进一步完善时态数据处理能力。同时，随机时间函数RANDOM()也得到了扩展。
全面的性能提升
PostgreSQL 19 在查询优化器与执行器层面继续进行了大量优化工作。优化范围包括：
- Anti Join
- Semi Join
- 常量折叠
- Append Path 下的增量排序
- Join 前聚合处理
- Join 选择率计算
- 函数统计信息等多个领域
相比简单列举优化项，更重要的结论在于：PostgreSQL 正在不断提升对常见查询模式的识别能力，并尽可能减少不必要的计算开销。部分聚合操作现在能够在 Join 之前完成，从而减少参与计算的数据量；更多NOT IN与LEFT JOIN场景能够自动转换为高效的 Anti Join；Memoize 在EXPLAIN中拥有更好的可观测性；基数排序（Radix Sort）进一步提升排序性能；外键检查速度得到优化；COPY FROM的文本与 CSV 输入开始支持 SIMD 指令加速。
这些优化大多数情况下并不需要修改应用代码。升级完成后，PostgreSQL 将自动拥有更高概率生成更优执行计划。这也是数据库性能优化中最理想的一种形式。
为什么 PostgreSQL 19 显得如此重要
PostgreSQL 19 最突出的特点，并非某一项单独的新功能，而是覆盖面的广度。
应用开发领域拥有：
- 图查询能力；
- 更丰富的 SQL 语法；
- 窗口函数增强；
- 更完善的 Upsert 行为。
数据库运维领域拥有：
- REPACK CONCURRENTLY；
- 更智能的 Autovacuum；
- 更完善的监控能力；
- 更丰富的复制可观测性。
性能优化领域拥有：
- 查询优化器增强；
- SIMD 优化；
- 更快的外键检查；
- 更高效的排序算法。
数据库生态建设领域则拥有：
- 更多 Hook 能力；
- Planner Advice 模块；
- 扩展机制增强；
- FDW 统计信息获取能力。
这种广泛而均衡的演进方向，正是 PostgreSQL 持续保持竞争力的重要原因之一。它不仅在单一场景持续进步，而是在应用数据库、运维数据库、分析数据库、可扩展数据库以及数据平台等多个维度同步成长。
PostgreSQL 19 尚未正式发布，因此当前正是开展验证测试的最佳时期。包括应用兼容性测试、升级验证、扩展检查、核心查询计划分析、逻辑复制验证以及运维流程测试等工作，都能够帮助社区进一步完善最终版本质量。
PostgreSQL 的持续进步，始终建立在真实业务场景验证的基础之上。而从目前已经进入 Beta 阶段的 PostgreSQL 19 来看，其中已经包含了大量值得关注和验证的新能力。
作者：Craig Kerstiens
原文链接：
https://www.snowflake.com/en/blog/engineering/postgresql-19-features-beta/
