PG 18 把细节卷成了护城河

每年秋天，数据库圈都有一次不大不小的'节日'：PostgreSQL 全球社区同步发布年度大版本。今年轮到 PostgreSQL 18。

单看发布清单，你可能觉得平淡：UUIDv7 主键、RETURNING 子句支持 OLD 和 NEW 行。没有一个听起来像'AI 原生''湖仓一体'那种能上发布会大屏的词。但如果你搭过数仓、写过实时管道、在分库分表的泥坑里泡过几年，会看出另一层意思——这些'小更新'，每一个都是在收编过去十年应用架构里被迫外置的能力。

我的判断是：PostgreSQL 的竞争力，正在从'功能多'转向'细节准'，而细节才是最难抄的护城河。

🚀 一年一大版，节奏本身就是武器

先讲个场景。九月的一个周四晚上，某中型电商的 DBA 群里炸了锅：PostgreSQL 18 发布了，升还是不升？

这是所有 PG 用户的年度保留节目。与一些商业数据库'三年憋一个大招'的节奏不同，PG 社区坚持年度大版本：每年砍掉一批旧分支，合并一批新特性，全球 Contributor 协作推进。素材里这条发布消息本身很克制，只说'开源数据库迎来年度大版本更新'，但'年度'两个字背后是一整套工程纪律——特性冻结、Commitfest 排期、回归测试，环环相扣。

这种节奏的价值常被低估。对使用者来说，年度版本意味着你永远不用'赌一个遥远的 Roadmap'：今年要的能力没赶上，明年这个时候大概率就在。对生态里的发行版、云服务、周边工具来说，稳定的版本节奏意味着可预期的适配周期。

反过来看，一些高举高打的数据库产品，发布会讲得天花乱坠，落地文档却常年残缺。圈内私下流行的说法是：'看一个数据库靠不靠谱，别看发布会，看它的小版本发得勤不勤。'

这就是产业逻辑的第一层：在基础设施领域，可预期的平庸，胜过不可预期的惊艳。 年度节奏让 PG 成了无数系统默认的'确定性来源'，而确定性恰恰是企业选型时最贵的东西。

🔑 UUIDv7：主键之争的十多年悬案，内核收编了

第二个更新，值得单独开一节：PostgreSQL 18 原生支持时间有序的 UUIDv7 主键生成。

没踩过坑的人可能觉得这只是换个 ID 格式。但对经历过移动互联网流量洪峰的架构师来说，主键生成是刻在职业记忆里的痛点：单机自增 ID 在分库分表后会冲突；UUIDv4 完全随机，写入时在 B-tree 索引里到处插页，页分裂频繁、缓存命中率差、写放大严重。于是过去十多年，行业发明了一整层'外挂'：雪花算法、各类号段分发器、专门的 ID 服务，配上维护团队和告警。

UUIDv7 的思路是把时间戳编进 UUID，让 ID 天然趋势递增——既保留了全局唯一的分布式属性，又对 B-tree 友好，新数据总是追加到索引右侧。

PG 18 把它做成原生能力，意味着什么？意味着应用层可以删掉一段配置、一个依赖、一套兜底逻辑。原来需要'ID 生成服务 + 监控 + 值班手册'才能解决的事，现在一列类型定义搞定。

产业逻辑很清晰：数据库正在反向吸收分布式时代沉淀在中间件里的能力。 谁能把'外挂'变成'内置'，谁就能在下一代应用的默认选型里占住位置。这不是性能榜上的军备竞赛，而是工程便利性的静默收割。

↩️ RETURNING 里的 OLD 和 NEW：一行 SQL 干掉一个触发器

第三个更新更小，小到很多通稿只给了一行标题：PostgreSQL 18 支持在 RETURNING 子句中引用 OLD 和 NEW 行。

翻译成人话：以前你执行一条 UPDATE，RETURNING 只能拿到改完之后的新值；想同时拿到'改前是多少钱'，你得再查一次、写个触发器记日志，或者在应用层自己维护前后快照。现在，一条语句直接把变更前后的两行都返回给你。

场景马上就有了。电商运营改价格，风控要求留痕：原价多少、现价多少、谁改的。过去的标准答案是建审计表加触发器——触发器意味着额外的执行路径、额外的锁、以及出问题时最难排查的那类 Bug。现在一条带 RETURNING OLD/NEW 的语句，配合应用层落日志就够了。

这看似是语法糖，实质是开发体验的内卷。数据库的选天平上，除了性能和稳定，还有一块越来越重的砝码叫'写起来爽不爽'。当一个团队发现常见需求在 PG 里都不需要绕路，默认选型就已经完成了大半。

📊 格局之变：Postgres 正在成为'事实标准层'

把三个更新放到更大的坐标系里看，趋势更明显。业界流传最广的那句调侃——'Postgres 正在吃掉数据库世界'——在 PG 18 上又得到了一次注脚。

右上象限里，PG 本体和它的云托管形态同时占位，这正是一个'事实标准'的典型特征：向上，大量新兴数据库直接兼容 PG 协议、甚至直接 fork 其内核；向下，开发者学一套 PG，可以在不同规模和形态的系统间迁移技能。这种'一次学习，处处可用'的生态位，是商业数据库最难受的竞争形态——你很难在一个开放社区持续迭代、且免费可得的产品面前，证明自己的溢价。

而 PG 18 的三个更新，恰好都是往'标准层'里加码：UUIDv7 收编分布式 ID，RETURNING 收编变更审计，年度节奏收编用户预期。没有一项是在跟谁对标，但每一项都在降低用户离开 PG 的理由。

⚠️ 冷静面：开源不等于免运维，升级仍是一场硬仗

最后泼一点冷水。作为亲手做过升级窗口的人，我必须说：PG 18 的新特性再香，大版本升级本身仍是一场需要演练、备份、回滚预案的硬仗。

火山之上是看得见的新特性，火山之下才是决定你能不能真正吃到红利的部分：社区的评审与测试纪律、大版本升级的迁移成本、周边工具的适配周期，以及你自己团队的运维能力。把'内核更新了'直接等同于'我变强了'，是选型里最常见的幻觉。

合理的做法是老三样：在预发环境跑回归，评估新特性的实际收益，规划好升级窗口。UUIDv7 和 RETURNING OLD/NEW 都是'随升级免费获得'的改进，但前提是你真的完成了升级。

小结

PostgreSQL 18 的发布清单很短，信息量却很大：UUIDv7 把分布式 ID 收进内核，RETURNING OLD/NEW 把变更留痕变成一句 SQL，年度大版本把确定性做成节奏。三个细节合起来，是同一个动作——持续降低用户'选 PG、用 PG、离不开 PG'的每一毫米摩擦。开源数据库的战争，已经不在发布会的 PPT 上，而在这些逐年累积的细节里。明年的 PG 19 值得继续盯，但更值得盯的，是你的团队今年有没有把升级窗口排上。