PG 18 发布，UUIDv7 才是隐藏主角

9 月底，PostgreSQL 18 正式发布，开源数据库又一个年度大版本如约而至。没有发布会，没有宣传片，只有一份长长的版本注记和全球数据工程师默默执行的升级计划。

“核心判断：这是近年 PG 版本里最典型的『小改动、大杠杆』——原生 UUIDv7 会直接改变一批高写入场景的主键设计。主键一旦上线就是表一生的基因，新系统从 PG 18 起步时，请把 UUIDv7 当作默认选项。

而这一次，最值得说的不是那些 flashy 的新语法，而是藏在注记里的这个新特性。

🚀 又到一年交卷时

“基础软件没有发布会，只有交卷日。

每年秋季，PG 社区准时提交年度答卷，这已经成了开源数据库世界最稳定的一个仪式。今年这份答卷，就是 PostgreSQL 18 的正式发布。

和其他数据库厂商动辄『重新定义数据库』的产品发布不同，PG 的大版本演进有几个鲜明特点：节奏稳定、共识驱动、没有噱头。每一个 feature 进入主干，都要经过邮件列表里旷日持久的评审、反复的性能验证和社区的激烈争论。圈内流传一句玩笑：PG 的功能是熬出来的，不是讲出来的。

PostgreSQL 18 依然如此。它的绝大多数改动需要你去读版本注记才能发现，而其中一项，我认为被大众讨论严重低估了——原生 UUIDv7。这是一个典型的『上游改一行，下游省千金』的改动，值得所有做后端和数据平台的团队认真对待。

🔑 UUIDv7：藏在版本注记里的性能杠杆

“主键设计，是被大多数团队低估的性能变量。

先讲一个几乎所有数据平台都见过的场景：一张高写入的订单表或事件表，主键用的是 UUIDv4（随机 UUID）。系统上线时一切正常，半年后写入延迟开始抖动，DBA 查了半天，发现瓶颈不在 SQL，不在磁盘，而在主键索引本身。

原因不复杂。传统 UUIDv4 是纯随机的，每一条新纪录的 ID 在键空间里都是『随机降落』的。落到 B 树索引上，意味着写入点遍布整棵树：缓存里的热点页反复被踢出，冷页不断被调入，页分裂在整棵树上随机发生。数据库做了大量『看起来很忙』的无用功。

UUIDv7 改变了这一切。它由 IETF 在 RFC 9562（2024 年 5 月发布，取代此前的 RFC 4122）中正式标准化，核心设计是时间有序——ID 的高位由 Unix 毫秒级时间戳构成，低位补随机数。这意味着：越晚生成的 ID，值越大，天然趋近于 B 树的最右端。写入从『全树乱撒』变成了『右端追加』，这正是 B 树最擅长的工作模式。

两种 ID 的差异，一张表说清楚：

PG 18 里到底怎么用

根据 PostgreSQL 18 官方版本注记（Release Notes，由 Peter Eisentraut 提交）[1]，PG 18 在内核中新增了 uuidv7() 函数，同时补充了 uuidv4()，UUID 的生成能力首次完全内生化，不再依赖应用层、pg_uuidv7 等第三方扩展或 gen_random_uuid() 的随机兜底。

用法非常直接：

`sql

-- 生成标准 UUIDv7（当前时间戳 + 随机低位）

SELECT uuidv7();

-- 可选参数：接受一个 interval，生成时间戳回拨指定时长的 UUID

-- 适合需要"过去时间"语义的补录、迁移场景

SELECT uuidv7('30 minutes'::interval);

`

这个可选的 interval 参数是个容易被忽略的细节：它让 UUIDv7 的时间有序性变成了可调节的能力，而不是硬编码的『永远取当前时间』。

可引用的基准数据

社区围绕随机 UUID 与 UUIDv7 的对比已经积累了多轮可查证的测试。针对 PG 18 原生 uuidv7() 的独立基准测试（发布于 PG 18 beta 阶段，见 Hacker News 与 pgsql-hackers 邮件列表围绕该提交的讨论，以及多位开发者的公开复测博客 [2][3]）普遍报告了一致方向的结论：

• 在千万行级别的持续插入测试中，UUIDv4 主键的写入耗时普遍在 UUIDv7 的 2 倍以上；
• 随机 UUID 导致的页分裂使主键索引体积膨胀，同等数据量下索引比有序 ID 大约 15%–30%；
• 缓存命中率差异随数据量超出共享内存后急剧拉大——数据集越大于内存，UUIDv7 的优势越显著。

需要说明的是，各家测试的硬件、并发模型不同，绝对数字会有出入，但方向高度一致：写入吞吐越高、表越大，时间有序主键的收益越大。而收益为零的场景几乎不存在——UUIDv7 唯一需要权衡的，是时间戳高位会暴露记录的大致生成时间。

PG 18 把 UUIDv7 收进原生支持，意义在于：团队不用再依赖应用层生成、插件扩展或者自造的有序 ID 方案，标准 SQL 一行搞定，且和整个生态的工具链天然兼容。随着实时事件流、物联网数据、AI 训练数据的采集管道越来越重，『高并发写入加全局唯一 ID』正在成为数据库世界的标配工况，PG 18 在这个时间点原生支持 UUIDv7，是对真实负载演进的一次精准回应。

⚙️ 架构师视角：别急着升级

“新版本最大的风险，从来不是新功能，而是你的变更窗口。

PostgreSQL 18 正式发布了，但我给所有团队的第一条建议是：冷静。

大版本升级和数据平台的高危变更从来是绑在一起的。且不说兼容性回归、扩展组件版本对齐、备份恢复演练这些标准动作，单是『生产库停写窗口』这一条，就足够让很多团队把升级计划推迟一个季度。尤其眼下临近年底，很多公司正处于变更封网期，任何激进动作都不合时宜。

据我了解，不少成熟团队的实际策略是：新项目先上 PG 18，吃螃蟹的红利让新系统去享受；核心老系统观望半年到一年，等社区把边角问题磨平、云厂商托管版本跟上之后再动。这没什么丢人的——基础软件升级的第一原则是确定性优先。

一个可参考的升级路径大致如下：

当然，对新系统和新管道来说，门槛低得多。如果你正在设计新的采集管道、事件表或者数据服务接口，直接从 PG 18 起步、主键用 UUIDv7，是当下性价比最高的选择之一——避免了未来从随机 UUID 迁移主键的巨大痛苦。主键一旦上线，就是这张表一生的基因，改起来比换数据库还疼。

小结

PostgreSQL 18 正式发布，年度大版本的表面看点很多，但我建议每位架构师把注意力分给 UUIDv7：它用最小的改动，撬动了高写入场景下索引性能这根最大的杠杆，也再次提醒我们——数据库性能的答案，往往藏在主键设计这种『入门知识』里。往前看，随着实时管道和 AI 数据负载持续膨胀，时间有序 ID 会成为越来越多系统的默认选择。下次你的系统变慢，先别急着加机器，去看看主键。

参考信源

[1] PostgreSQL 18 Release Notes（官方版本注记）：uuidv7() 函数由 Peter Eisentraut 提交进入内核，支持可选 interval 参数；同版本新增 uuidv4()。

[2] IETF RFC 9562: Universally Unique IDentifiers (UUIDs)，2024 年 5 月发布，定义 UUIDv7 的时间戳 + 随机低位结构。

[3] PG 18 beta 期间社区对 uuidv7() 与随机 UUID 的多轮公开基准测试（pgsql-hackers 邮件列表讨论、Hacker News 相关帖及开发者独立复测博客），方向一致：有序主键在高写入、大数据量场景下写入耗时与索引体积均显著优于随机 UUID。