每一个 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_levelreplica可以自动启用逻辑复制功能同时新增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 属性图查询正式进入 PostgreSQLPostgreSQL 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 JoinSemi Join常量折叠Append Path 下的增量排序Join 前聚合处理Join 选择率计算函数统计信息等多个领域相比简单列举优化项更重要的结论在于PostgreSQL 正在不断提升对常见查询模式的识别能力并尽可能减少不必要的计算开销。部分聚合操作现在能够在 Join 之前完成从而减少参与计算的数据量更多NOT IN与LEFT JOIN场景能够自动转换为高效的 Anti JoinMemoize 在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/