PostgreSQL 19 原生支持时态表
推荐指数 62.0 NO. 014 · 2026.06.13
发布2026/06/12Score82Comments24
为什么值得看
PostgreSQL 19 将原生实现 SQL:2011 标准的 temporal tables（时态表），无需触发器即可查询任意历史时间点的数据状态。对需要审计追踪、合规回溯的 AI 应用数据层是重大利好，此前只能依赖扩展或应用层 hack。
编辑判断
时态表在 MySQL（MariaDB）、SQL Server、Oracle 中已存在多年，PostgreSQL 社区长期靠 temporal_tables 扩展或手动实现，维护成本高且容易出错。原生支持意味着性能优化空间更大，执行计划器可以直接利用底层 MVCC 机制做时间切片，而非扩展层的触发器开销。
对 AI 工程师的具体影响：构建 RAG 知识库时，如果数据源需要版本回溯（比如合同条款变更、用户画像历史），以前要在向量数据库和关系库之间做双写同步，现在 PostgreSQL 本身就能回答"上周二这条记录长什么样"，减少一套数据管道。正在用 pgAudit 或手动 timestamp 方案的团队，19 发布后值得评估迁移成本。
社区反馈
正面 25 条评论
核心争论：时态表应存储双端点还是单端点，以及原生支持与扩展方案的优劣对比
It can be super ugly to try and hand-manage date time range manipulation in a system with moving parts. It is, of course, possible, but it's a headache to try and pull it off when there is complex business logic focused on those datetimes and interactions between ranges. The period constraint is a
I remember reading about this feature for Oracle in the 2000s and was always interested to use it in a production environment. It never came to pass when we used Oracle, maybe now with Postgres I will finally have a chance at it.
Why are they storing a time period (start and end date) in the first example? Why not just store the date when the price comes into effect? That would make both overlaps and time travel impossible without using any constraints.