展望 PostgreSQL 19：有哪些值得关注的亮点特性？

由 John Doe 七月 31, 2026

每年秋季的 PostgreSQL 大版本更新，都是数据库圈的固定重头戏。随着 PostgreSQL 19 进入 Beta 阶段，200 余项特性与改进逐步浮出水面。

目录

image

和以往“单核心特性撑场”的版本不同，PostgreSQL 19 走的是全面均衡发展路线：从应用开发者的日常 SQL 编写，到 DBA 的生产运维，再到底层性能与工具链打磨，几乎每个角色都能找到直击痛点的升级。今天我们就来梳理一下，这个新版本里最值得关注的亮点。

运维人福音：生产痛点逐个击破

对于扛着数据库稳定性的运维与 DBA 来说，PostgreSQL 19 带来的几个核心特性，堪称“久旱逢甘霖”。

1. 原生 REPACK CONCURRENTLY：表膨胀再也不用锁表了

回收表空间、整理数据碎片，是 PostgreSQL 运维的常规操作。但长久以来，VACUUM FULL 和 CLUSTER 都会加重锁阻塞业务，生产环境不敢轻易用；大家只能依赖 pg_repack 这类第三方扩展，又要面临安装权限、版本兼容的额外成本。

PostgreSQL 19 直接把 REPACK 命令纳入内核，原生支持 CONCURRENTLY 并发模式：全程不持有重锁、不中断业务读写，就能完成表与索引的空间回收和数据重组织。对于大表密集的生产系统来说，这绝对是提升运维幸福感的核心特性。

2. 分区表支持合并与拆分：策略调整不用推倒重来

分区表用久了，总会遇到策略不适配的问题：业务增长超预期，个别分区变得异常大；或者数据留存周期调整，小分区太多太琐碎。过去调整分区只能手动拆建、迁移数据，操作繁琐且风险高。

PostgreSQL 19 新增了 MERGE PARTITIONS 和 SPLIT PARTITION 语法，支持直接合并多个分区，或是把单个分区拆分成多个子分区。分区策略可以跟着业务节奏灵活演进，不用再为了调整结构重建整套分区表。

-- 把 Q1 和 Q2 合并到一个分区里
ALTER TABLE customer_orders MERGE PARTITIONS (orders_2026_q1, orders_2026_q2) INTO orders_2026_h1;

-- 把第三季度的分区按月度进行拆分
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')
);

3. 自动 Vacuum 全面升级：更智能，也更可控

Vacuum 始终是 PostgreSQL 运维的“半永久话题”。新版本在自动 Vacuum 上做了大量务实优化：

  • 支持并行 Vacuum worker，大表、多索引场景的清理效率大幅提升；

    -- 允许全局最多 4 个并行工作进程用于自动清理进程
ALTER SYSTEM SET autovacuum_max_parallel_workers = 4;

  • 引入优先级打分系统，可按表配置插入、更新删除的清理权重，让最紧急的表优先被处理；

    -- 仅针对这个表调整优先级评分：
-- 大幅提高基于插入的清理紧急性（3.0），
-- 同时降低普通更新/删除清理紧急性（0.5），因为行很少被删除。
ALTER TABLE application_logs SET (
    autovacuum_vacuum_insert_score_weight = 3.0,
    autovacuum_vacuum_score_weight = 0.5
);

  • 新增 pg_stat_autovacuum_scores 视图，自动清理的决策过程更透明。

配合更详细的 Vacuum 进度日志、独立的自动分析日志阈值，后台维护工作终于从“黑盒”变得可观测、可调控。

4. 逻辑复制补全关键短板

逻辑复制的能力在最近几个版本持续完善，PostgreSQL 19 补上了几个最常用的缺口：

  • 序列值同步：发布端可以同步序列状态，订阅端切换后不会出现 ID 冲突，解决了逻辑复制迁移的经典坑；
  • 发布支持 EXCEPT 排除：发布全库表时可以指定排除少数表，更贴合“大部分同步、个别例外”的真实运维场景；
  • 无需重启启用逻辑解码：调整 wal_level 不再强制重启，减少运维操作的业务影响；
  • 新增 effective_wal_level 显示实际生效的 WAL 级别，配置行为更透明。

开发者利好：SQL 写起来更顺手了

除了运维侧的重磅升级，PostgreSQL 19 也给写 SQL 的开发者准备了不少实用改进。

1. 原生支持 SQL 属性图查询（SQL/PGQ）

这是本次版本最受关注的特性之一。PostgreSQL 不用额外引入图数据库，直接在现有关系表的基础上，支持标准的 SQL/PGQ 图查询语法。

你可以把业务表定义为顶点和边，直接运行图遍历、路径分析类查询——非常适合风控反欺诈、推荐关联、组织架构、供应链网络这类场景。不用新增技术栈、不用做数据同步，关系型数据库直接解锁图查询能力，技术架构更简洁，运维成本也更低。

-- 示例的 SQL 属性图
CREATE PROPERTY GRAPH store_graph
VERTEX TABLES (
    customers LABEL customer,
    orders LABEL "order"
)
EDGE TABLES (
    customer_orders 
        SOURCE customers 
        DESTINATION orders 
        LABEL placed_order
);

2. 这些 SQL 语法糖，少写很多冗余代码

  • GROUP BY ALL：分组查询时不用再逐个列出非聚合字段，写 GROUP BY ALL 就能自动按所有非聚合、非窗口字段分组，写探索性查询和报表 SQL 时格外方便。

    -- 使用 GROUP BY ALL
SELECT 
    category,
    manufacturer,
    COUNT(*) as total_items,
    AVG(price) as avg_price
FROM inventory_products
GROUP BY ALL;

  • 窗口函数支持 IGNORE NULLS：lead、lag、first_value 等窗口函数新增空值忽略选项。过去要取“上一个非空值”得写复杂的嵌套逻辑，现在一行语法就能搞定。

  • Upsert 能力增强：INSERT ... ON CONFLICT DO SELECT ... RETURNING 语法上线，冲突时可以直接返回冲突行的信息，业务侧处理幂等场景更灵活。

    INSERT INTO tags (tag_name) 
VALUES ('postgres')
ON CONFLICT (tag_name) DO SELECT
RETURNING tag_id;

  • 时态数据操作升级：UPDATE 和 DELETE 支持 FOR PORTION OF 语法，针对时间区间数据的修改更直观。

3. COPY 命令全方位增强

作为数据导入导出的核心工具，COPY 也迎来了多处体验升级：

  • 导入时支持跳过多行表头，处理带冗余元数据的 CSV 文件不用提前清洗；

  • 新增 ON_ERROR SET_NULL 选项，非法值自动置空，不用因为个别脏数据导致整批导入失败；

    -- 想象一下有一个文件，其中的价格列有时会出现 'N/A' 或 'MISSING'，而不是数字值
COPY product_catalog (product_id, title, price_usd)
FROM '/path/to/dirty_products.csv' 
WITH (
    FORMAT CSV, 
    HEADER, 
    ON_ERROR SET_NULL
);

  • 导出支持 JSON 格式，可直接输出标准 JSON 数组；

    -- 将整张表直接导出为格式整齐、有效的 JSON 数组
COPY customers TO '/path/to/customers_export.json' WITH (FORMAT JSON, ARRAY true);

  • 支持直接导出分区表，不用再套一层子查询。

隐形性能提升：升级就变快

很多性能优化不需要改业务代码，只要升级版本，就能享受到查询效率的提升。PostgreSQL 19 在优化器、执行器层面做了大量深耕：

  • 急切聚合（Eager Aggregation）：部分聚合运算可以下推到连接之前执行，大幅减少参与连接的数据量，多表关联+聚合的常见查询会明显提速；
  • 连接与排序优化：反连接、半连接的识别更智能，更多 NOT IN、LEFT JOIN 场景会被优化为高效执行路径；基数排序的引入，也让大数据量排序性能再上一个台阶；
  • SIMD 加速导入：COPY FROM 的文本与 CSV 导入支持 SIMD 指令，大批量数据加载速度更快；
  • 外键约束检查、常量折叠、增量排序等细节优化遍布执行链路，很多常用查询都会无声变快；
  • 异步 IO 能力持续优化，IO 密集型场景的表现进一步提升。

另外，pg_plan_advice 模块的加入也值得关注。你可以通过它干预优化器的执行计划选择，给特定 SQL 绑定执行建议，解决生产环境中“执行计划跑偏导致慢查询”的经典难题，为计划稳定性提供了原生手段。

工具链与可观测性：排错调优更高效

  • 细粒度日志级别控制：可以单独针对某个后台进程调高日志详细度，不用全局调整导致日志量暴增，生产环境排查问题更安全；
  • pg_waldump 支持 tar 格式：配合 pg_verifybackup 可以直接校验 tar 格式的物理备份，备份验证与故障排查更省空间、更高效；
  • 在线校验和修改：调整数据页校验和级别不再需要重启实例，又少了一个需要停业务的运维操作；
  • SSL 连接支持 SNI：网络层的兼容性与安全性进一步提升；
  • 首批内置 DDL 生成函数上线：支持直接获取数据库、角色、表空间的对象定义语句，后续版本将逐步覆盖更多数据库对象，替代部分 pg_dump 的使用场景。

写在最后

整体来看，PostgreSQL 19 没有追求“一鸣惊人”的概念性功能，而是把功夫下在了真实生产场景的痛点上：运维更省心、开发更顺手、性能更强劲、工具更完善。它延续了 PostgreSQL 一贯的务实风格：不讲故事，只解决真问题。

按照社区节奏，PostgreSQL 19 正式版预计会在 2026 年 9-10 月发布。目前 Beta 版本已经开放测试，无论是提前验证业务兼容性，还是评估升级收益，都可以在测试环境先体验起来。毕竟每一次大版本的打磨，都是在给长期运行的系统攒下实实在在的价值。

参考

PostgreSQL 19 Release Notes

搜索

分类

标签