PG18发布：三个小功能，一盘大棋局

没有发布会，没有 CTO 演讲，没有融资庆祝。PostgreSQL 18 就这样被推上了官网——像过去许多年的每一次年度大版本一样，安静得近乎冷淡。但如果把这次的几个新功能放在一起看，你会发现这盘棋下得比表面大得多：UUIDv7 原生主键、RETURNING 子句支持 OLD/NEW 行、全新的异步 I/O 子系统，每一个都精准指向过去几年里由中间件、云厂商和业务团队「手工发明」的解决方案。

我的判断是：开源数据库的叙事已经变了。它不再是追赶 Oracle 的追赶者，而是在反向吸收整个上层生态的发明，把「外部补丁」一个个收编进内核。

📅 没有发布会，却是全行业最准时的发布

先讲个场景。PG18 发布那几天，我所在的几个 DBA 群里，讨论热度远不如一次手机发布会。有人转了条新闻，下面接一句「哦，18 了」，然后继续讨论手头的慢查询。这种「平静」本身，就是 PostgreSQL 社区最大的工程成就。

从 PostgreSQL 10 开始，这个社区确立了「每年一个大版本」的固定节奏，由全球志愿者组成的 Committer 团队按特性冻结、测试、发布的流程推进，雷打不动。对比一下商业数据库世界：大版本跳票是常态，路线图随公司战略摇摆是常态，「先发布后修补」也是常态。而 PG 的版本节奏，二十多年来几乎精确得像时钟。

• 2017 年：PG10 确立年度大版本节奏，声明式分区落地
• 2019 年：PG12 强化分区与索引体系
• 2023 年：PG16 持续打磨并行与复制
• 2025 年：PG18 发布，UUIDv7、RETURNING 增强与异步 I/O 登场

产业逻辑：在基础设施领域，「确定性」本身就是竞争力。企业选数据库，选的不只是功能，更是未来十年可预期的演进路径。一个每年准时交付、没有营销噪音、没有强制升级绑架的内核，是这个行业里最稀缺的产品形态。而这种「不需要解释」的地位已经有数据背书：在 Stack Overflow 2023 年度开发者调查中，PostgreSQL 的使用率（45.6%）首次超过 MySQL（41.1%）；2024 年这一差距进一步拉开到 48.7% 对 40.3%——PG 连续两年成为全球开发者使用率最高的数据库。

🆔 UUIDv7 收编内核：这个痛点是微服务自己造的

金句先放在这：数据库内核每多一个原生能力，业务团队的 DIY 清单就少一行。

做过分库分表的人都懂那种痛。单机时代，自增主键简单可靠；一旦水平拆分，自增 ID 就冲突了，于是全行业被迫做了同一个选择题：要么引入号段分发、雪花算法这类额外组件，要么用 UUIDv4——全球唯一是保证了，代价是索引写入性能的持续恶化。

原因很朴素：UUIDv4 完全随机，插入时在 B-tree 里要找的位置毫无规律，每次写入都可能命中冷页、触发页分裂，缓存命中率被拉垮。这在写入密集型业务上，是一笔持续多年的隐性税。EDB（原 2ndQuadrant）工程师 Ilia Evdokimov 在 2019 年的公开基准测试《UUIDs are Popular, but Bad for Performance》中就量化过这一点：在千万行、索引远大于内存的规模下，随机 UUID 的批量写入耗时约为顺序整数的 2~3 倍，且差距随表规模扩大而继续拉大。

UUIDv7 的解法聪明在「有序」：按 RFC 9562 规范，在 UUID 的前缀中嵌入毫秒级 Unix 时间戳，让新生成的 ID 在数值上趋势递增。PG18 直接提供了内核函数 uuidv7()，效果是插入永远落在 B-tree 的右侧热区，写入放大显著下降，同时 ID 本身还携带了时间信息，按主键排序即近似按时间排序——这对日志、订单、事件类数据是刚需。

`sql

SELECT uuidv7(); -- 0198f3a2-7b1c-7e0d-9c4e-3f8a2b5d6e7f

SELECT uuid_extract_timestamp(uuidv7()); -- 直接解出时间戳

`

产业逻辑：注意这张表的最后一行——「不需要，内核原生」。过去十年，应用架构师们为了绕开内核能力的空白，发明了整整一层「数据库周边件」：发号器、分片中间件、补偿框架。现在内核把这些经验一个个收编回去。这不是功能更新，是架构层的简化：技术栈变短，故障点变少，招一个懂 PG 的人就够，不用再养一个懂发号器的人。

🔁 RETURNING 引用 OLD/NEW：CDC 从「批发」到「零售」

第二个功能更值得玩味。PostgreSQL 18 允许在 INSERT/UPDATE/DELETE 的 RETURNING 子句中同时引用被修改行的 OLD（旧值）和 NEW（新值）。

没做过数据同步的人可能觉得这平平无奇。但在数据工程的世界里，「拿到每一行变更的前后镜像」是一个巨大的产业。你要把业务库的变更同步到数仓、缓存、搜索引擎，标准做法是搭一套 CDC 管道：解析 WAL 日志、用 Debezium 这类工具捕获变更、投递到 Kafka、再由消费者分发。这条链路能跑通，但要维护一套完整的流式基础设施——对于只有十几张表、每天几万次变更的中小业务，这套装备无异于高射炮打蚊子。

PG18 之前，开发者只能用触发器配合过渡表来近似实现，代码繁琐且容易漏场景。现在一条 UPDATE 加 RETURNING，新旧值直接返回：

`sql

UPDATE accounts

SET balance = balance - 100

WHERE id = 42

RETURNING OLD.balance AS 旧余额,

NEW.balance AS 新余额;

-- 旧余额 | 新余额

-- -------+--------

-- 1500 | 1400

`

产业逻辑：这是 CDC 场景的「零售化」。重型管道（全量、低延迟、多下游）依然属于 Kafka + Debezium 的世界，但大量轻量需求——审计日志、简单的行级同步、变更通知——现在一条 SQL 就能解决。内核在把数据流通的门槛往下压。当然也要说清楚边界：RETURNING 是语句级的、同步的，替代不了真正的事务性变更捕获，别急着拆你家的 Debezium。但它把「要不要为一个小需求搭一套流式平台」这个决策，变得更容易说「不」了。

⚡ 异步 I/O：被低估的第三个功能

第三个功能最不像「功能」，却可能是对存量用户影响最大的一个。PG18 重写了 I/O 层，引入异步 I/O 子系统，通过新的 io_method 参数启用，支持 worker（内置 worker 进程池）和 io_uring（Linux 原生异步接口）两种模式，覆盖顺序扫描、位图堆扫描和 ANALYZE 等核心读路径。

过去三十年，PostgreSQL 的读操作是同步阻塞的：进程发起读请求，然后干等磁盘返回。预读靠 hint bits 和 effective_io_completion 这类补丁式机制缝缝补补。现代 SSD 和 NVMe 的 IOPS 能力远超同步模型的利用上限——硬件在跑，内核在等。PG18 让一个后端进程可以同时挂起大量并发的读写请求，把存储设备的并行能力真正榨出来。

官方公告给出的参考数字是：在合适的硬件与负载下，读取性能最高可提升至原来的 2~3 倍（up to 2-3x）。这写在 postgresql.org 的 PG18 正式发布通稿里，是三个功能中唯一一个官方直接给出倍数级性能数字的——对做报表、做批量扫描、做大表 VACUUM 的团队来说，这个数字比任何新语法都值钱。而且它不需要改一行业务代码：升级内核、调一个参数，就能吃到红利。

产业逻辑：UUIDv7 和 RETURNING 是「收编」应用层的发明，异步 I/O 则是内核在偿还自己的技术债。前者扩大 PG 的适用边界，后者抬高 PG 的性能底线——两条腿走路，才是它能持续吸收上层生态发明的真正底气。

🌐 整个生态都在往 Postgres 上押注

还有一个观察不在发版说明里，而在发版说明外。PG18 发布的同一年，环顾整个数据库产业，会发现一个惊人的事实：几乎所有的行业热点，都在 Postgres 的轨道上。

• Serverless 数据库赛道，Neon（2025 年被 Databricks 收购）和 Supabase 都构建在 PG 之上，成为 AI 应用快速搭建后端的事实底座
• 云巨头这边，AWS 的 Aurora 与 Aurora DSQL 延续 PG 兼容路线，Microsoft、Google Cloud 也都提供 PG 兼容服务
• 国内市场，阿里云 PolarDB PostgreSQL 版、腾讯云 TencentDB for PostgreSQL 以及一批信创数据库，「PG 兼容 + 自研内核」路线的产品线持续扩张

为什么是 PG？技术之外，有一条常被忽略的商业逻辑：PostgreSQL 的 License 几乎没有使用限制，任何人都可以拿它改造、分发、商用，不存在 Oracle 那样的授权费悬顶之剑。第三方数据库排行网站 DB-Engines 的长期趋势也能佐证这个转向：PostgreSQL 稳居流行度第四位多年，并在 2017 年和 2023 年两度获评「年度 DBMS」——毕竟下游开发者生态、扩展生态（PostGIS、pgvector 等）和人才供给都在往这边倾斜，这是任何关注数据库市场的人都能公开核实的事实。

产业逻辑：PostgreSQL 正在成为数据库世界的 Linux——不是某个产品，而是一个产业公共底座。PG18 的每一个内核增强，都会通过这张生态网络被放大：内核原生 UUIDv7，意味着上面所有的云服务、Serverless 平台、国产库都自动跟进。这种杠杆效应，是任何单一商业数据库产品不具备的。

⚠️ 克制的另一面：好功能到生产，还有几公里

说了这么多好话，作为天天在产线上的人，必须泼半盆冷水。

第一，发布 ≠ 可用。PG18 于 2025 年 9 月 25 日正式发布，绝大多数生产环境真正用上，普遍要滞后一两个大版本。企业升级数据库的决策周期以年计：要先等扩展生态兼容、等云厂商托管版本跟进、等自家灰度验证。UUIDv7 再好，你手上的 PG14 集群短期内也用不上。这个「版本到生产的时间差」，是所有基于新内核做架构决策时必须计入的成本。

第二，新能力在测试新边界。UUIDv7 依赖时间戳保证趋势有序，这意味着多节点部署时的时钟质量会成为新的关注点；RETURNING 的轻量同步也不能替代真正的事务级变更捕获；异步 I/O 的 io_uring 模式需要 Linux 5.1+ 内核，且 worker 模式有额外的进程开销，收益因负载类型而异。把内核能力当成银弹，是另一种形式的概念泡沫——而这恰恰是我们这个行当最该警惕的。

第三，竞争并未终结。MySQL 阵营在互联网存量场景依然庞大，Oracle 存量的替换迁移是十年级别的工程，国内信创市场的格局也远未收敛。PG 的赢面在增量和新生态，存量世界的仗还要一场一场打。

小结

PostgreSQL 18 的发布提醒我们：基础设施行业的真正变革，往往不发生在发布会的大屏幕上，而发生在发版说明的一行行 changelog 里。UUIDv7 收编了分布式主键的 DIY 历史，RETURNING OLD/NEW 降低了轻量 CDC 的门槛，异步 I/O 抬高了内核的性能底线，而这一切通过一张几乎全部主流玩家都在押注的生态网络被放大。给从业者的建议很实际：把 PG18 列入下一轮升级评估，现在就开始验证扩展兼容性；同时对「内核原生」保持兴奋但别失了分寸。

数据库行业跑了几十年，故事的讲法换了一茬又一茬——从 Oracle 的销售发布会，到 NoSQL 的反叛宣言，再到云厂商的 re:Invent 主题演讲。而 PostgreSQL 用最笨的方式赢下这一局：不开发布会，不开战略会，每年九月准时把一个更好的内核放在官网下载页上，然后继续安静地写下一年的代码。慢，成了它最快的活