PostgreSQL 前世今生：从 1986 Berkeley 实验室到 2025 全球基础设施，一条开源数据库的 39 年演化史

本文是「PostgreSQL 源码系列」项目篇。同系列前文：

• PostgreSQL 从 postgres 二进制到生产级守护：最外层模块与启动全流程
• PostgreSQL 元数据存储机制：从磁盘文件到内存缓存，pg_class 撑起的整个系统表体系
• PostgreSQL MVCC：从一行 UPDATE 到 5 个 HeapTuple 的演化
• PostgreSQL 内存管理：从 shared_buffers 到内存上下文
• PostgreSQL 事务生命周期：从 BEGIN/COMMIT 到 CLOG 一条链路
• PostgreSQL 内核开发：读取一张表的 9 步标准流程与缓存全景

很多人对 PostgreSQL 的印象是”那个比 MySQL 更严肃的 SQL 数据库”。但如果你只看版本号，会以为它就是从 1996 年某个 1.0 起步的普通开源项目。事实上，**PostgreSQL 是从 1970s 数据库研究浪潮中走出来的一条”主线程”**，跟 System R、Ingres、Oracle、DB2 同代，是为数不多还在持续演化的”老兵”。

它走过 39 年，靠的不是某个天才的灵光一现，而是一连串关键技术决策：

• 1986：把”Ingres 后继”做成 POSTGRES（Post-Ingres），把”关系 + 复杂对象”作为研究路线；
• 1995：砍掉复杂对象、暴露 SQL 接口、加版权变成 Postgres95，跨入开源世界；
• 1996：改名 PostgreSQL，由社区接管，进入漫长的”工程师迭代期”；
• 2005：8.0 发布（Windows 原生、PITR、Savepoint），从”研究生项目”毕业为生产级 RDBMS；
• 2010：9.0 入流复制 + 热备，开始有”现代 PG”的雏形；
• 2017：10 大版本（逻辑复制、原生分区、并行），开始把 Oracle / DB2 的核心能力一条条搬过来；
• 2024：17 / 18（持续增量备份、async / async / MERGE / 列存实验），开始新一轮”企业级”整合。

本文不是维基百科式的事件流水账，而是**按时间线串起”技术决策 + 关键人物 + 分支演进 + 生态影响”**。读完你应该能回答：

1. PostgreSQL 跟 MySQL 是不是同一年代的产品？不是。
2. 为什么”Postgres”前面要加”Post”？因为它是 Ingres 的后继。
3. 为什么 1996 年要改名 PostgreSQL？因为 95 那两个数字太像 MySQL 的 1.0。
4. 8.0 之前 PostgreSQL 都”不能上生产”吗？不是不行，是工程师太少。
5. 为什么这十年冒出那么多分支？因为 PG 的扩展机制（access method / FDW / hook）允许在不动内核的情况下造分支。

全文约 80+ 个历史事件点、15+ 张架构 / 家谱 / 分类图，按 8 个时期组织。

一、39 年总览：从 Ingres 到 PG 18

在展开之前，先看一张总时间线：

把 39 年切成 8 个时期，可以看到节奏明显在加快：

节奏观察：1986-2005 年共发布 1+6+7=14 个主版本（平均 0.7 年一个），但从 2017 年开始变成每年一个大版本（1 年一个，节奏快 1 倍以上）。原因：2014 年 PGDG 把开发节奏定为每年 1 个 major release，long-term 不再维护。

二、前传（1970s-1986）：数据库研究的”战国时代”

2.1 1970s 三大研究脉络

1970s 关系型数据库几乎同时从三个地方冒出来。

关键观察：

• System R 发明了 SQL，证明了关系模型的可行性 → IBM 没立刻商业化，反而让 Oracle 学走了先机；
• Ingres 证明了研究生项目也能成为商品（INGRES → ASK Ingres → CA Ingres），但 Stonebraker 自己不感兴趣；
• Oracle 走的是”IBM 还没做、我先做“的路线，1979 年第一版就敢卖，根本不管 SQL 标准。

2.2 Ingres 的遗产：一份技术 + 一群人

Ingres 给后来 PG 留下的三个最重要的遗产：

1. POSTQUEL 查询语言（Ingres 的 QUEL 后继）；
2. C 实现的存储管理器（heap / catalog / utility 三件套，PG 18 里还能看到 src/backend/catalog/、src/backend/utils/cache/ 这些目录结构）；
3. 一群人：Michael Stonebraker、Anant Jhingran、Joseph Hellerstein、Michael Olson（PG 早期 contributor）……

Stonebraker 在 Ingres 之后想干什么？他写了 1986 年的论文《The Case for Partial Indexes》（SIGMOD）和《The Design of the POSTGRES Rules System》，明确表示 Ingres 的两个局限：不能扩展数据类型、不能用规则。这就是 POSTGRES 的研究动机。

历史巧合：2014 年 SIGMOD Test of Time Award 同时颁给了 Stonebraker 的《The Case for Partial Indexes》和 Hellerstein 的《Predicate Data Migration》。30 年前的研究影响了 30 年后的生产。

2.3 同期重要事件

三、Postgres 起源（1986-1994）：Post-Ingres 的 4 代演化

3.1 POSTGRES 1（1986-1989）

Stonebraker 拿到 NSF（美国国家科学基金会）资助，重新设计一个面向”复杂对象”的关系数据库。目标是：

1. 支持用户自定义数据类型（UDT）——这是 SQL 标准到 2003 年才有的东西；
2. 支持规则系统（rules）——触发器、视图更新自动重写；
3. 支持多版本并发控制（MVCC）——避免读写冲突；
4. 放弃 SQL，用自己的 POSTQUEL（Post-Ingres Query Language）。

/* POSTQUEL（1986）长这样 */
retrieve (emp.name) from emp in scottsdale
   where emp.salary > 50000

POSTQUEL 比 SQL 多了什么：嵌套表、数组类型、过程化引用、time travel（历史版本查询）。

3.2 POSTGRES 2 / 3 / 4 的演化（1989-1994）

Stonebraker 团队每年发一版，每版都有主题：

MVCC 的”年份之争”：Stonebraker 在 1986 年的论文里就提了 MVCC；POSTGRES v4 在 1993-1994 年才完整实现。但 Oracle 1986 年的商用版就实现了 row-level locking（不是 MVCC）。PG 的 MVCC 是 SQL 数据库里最早生产化的 MVCC 之一。

3.3 POSTGRES 关键论文（值得一读）

3.4 POSTGRES 的”软肋”

到 1993 年，POSTGRES 暴露了 4 个问题，导致它没法商品化：

1. POSTQUEL 学习曲线太陡——市场已经被 SQL 教育过；
2. 代码靠 NSF 资助维护——学生毕业就走，文档和测试不连续；
3. 没有事务日志——crash 后必须从头重做；
4. 没有客户端工具——psql 是 1996 年才出现。

正是在这个背景下，1994 年 Stonebraker 把 POSTGRES 的维护交给 Andrew Yu 和 Jolly Chen 两个研究生，开始砍 POSTQUEL、换 SQL、加版权。

四、Postgres95（1995-1996）：从研究项目到开源产品的转折

4.1 Andrew Yu / Jolly Chen 的改造（1994-1995）

1994 年 Stonebraker 离开 Berkeley 去 MIT / Wisconsin，把 POSTGRES 项目的维护权交给 Andrew Yu 和 Jolly Chen。两人做了两件关键事：

1. 把 POSTQUEL 编译器改成 SQL 编译器（用 1992 年的 Postgres 规则系统做 query rewrite）；
2. 改 BSD 版权（Berkeley-style），让代码可被外部使用。

1995 年 5 月发布的版本叫 Postgres95 v1.0，源码以 ftp 形式发布在 Berkeley。

4.2 Postgres95 的关键改造

4.3 1996 年的两封信件（决定 PG 走向开源）

1996 年有两封关键邮件，决定了 PostgreSQL 后来 30 年的走向：

邮件 1：Marc Fournier 提议改名

Subject: [HACKERS] Name change proposal
Date: 1996-07-08

As discussed, "Postgres95" is a marketing copy, not a real version number.
The version after 95 should be 1, but 1.0 would confuse with MySQL's
1.0. We need a new name.

Proposal: PostgreSQL (Post-GreSQL = Postgres + SQL)

邮件 2：Tom Lane 加入 commit 列表

Tom Lane 在 1996 年加入 PostgreSQL 邮件列表，从此成为核心开发者，到 2025 年依然是 PG 最重要的 contributor 之一，commit 数已超过 **6000+**，是 PG 当之无愧的”首席架构师”。

PG 文化基因：从 1996 年起，PG 的所有技术决策都在 pgsql-hackers 邮件列表上公开讨论。这种”邮件列表 + 共识”的开发模式，比 GitHub PR 模型早 12 年，比 GitLab 早 16 年。

4.4 同期事件

五、早期 PostgreSQL（1997-2005）：6.x / 7.x 的社区自治

5.1 6.x 系列（1997-1999）

PostgreSQL 6.x 是”修 bug + 加工具”的时期：

关键观察：6.5 之前的 PG 跟 MySQL 相比还有两点差距：

1. 没有外键约束的级联操作（6.5 之后才有完整实现）；
2. 没有 sub-select 性能（MySQL 在 3.23 起就解决了，PG 在 7.1 才有 sublink+union 优化）。

5.2 7.x 系列（2000-2005）

7.x 是 PG “长身体”的时期，几乎所有 PG 18 还在用的核心子系统都在这一时期定型：

7.1 的 WAL 是真正的分水岭——之前的 PG crash 后必须 pg_resetxlog，7.1 之后才有了真正的 crash safety。

5.3 关键人物登场

7.x 时代 PG 社区迎来一批”职业开发者”：

5.4 同期竞争产品

2005 年之前的市场格局：Oracle 是企业级霸主，MySQL 是互联网早期的事实标准，PG 长期在中间——**够好但不够”产品化”**。

六、生产化分水岭：8.x 系列（2005-2010）

6.1 8.0（2005-01）：从研究生项目毕业

8.0 是 PG 第一个”真正能上生产”的主版本。三件大事：

1. Windows 原生支持（之前要靠 Cygwin）；
2. Savepoint / nested transactions（嵌套事务）；
3. Point-in-Time Recovery (PITR)——业界第一个 RDBMS 实现。

PITR 的历史地位：PG 8.0 (2005) 之前，业界只有 Oracle 用 RMAN 实现过。MySQL 自 MySQL 4.0 (2002) 才有 binlog，但要拼装 PITR 还得手动拼。PG 是开源世界里第一个把 PITR 做进内核的。

6.2 8.x 全表（2005-2010）

6.3 8.x 时代的”灵魂三件套”

8.x 时代让 PG 第一次追上 Oracle / DB2 的企业级能力。2008 年以后，”PG 不能上生产”的论点基本没人提了。

6.4 同期生态大事

七、9.x 工业化（2010-2017）：复制 + 扩展 + JSON

7.1 9.0（2010-09）：流复制 + 热备

9.0 是 PG 第二个”上生产”的分水岭：

1. Streaming Replication（流复制）——基于 WAL 的物理复制，异步 / 同步两种模式；
2. Hot Standby（热备查询）——备机可读不阻塞 WAL replay；
3. Trigger-based replication 弃用——开始用 PG 自带的流复制替代 Slony-I。

7.2 9.x 全表（2010-2016）

7.3 9.x 的三个”杀手特性”

9.4 的 jsonb 是真正的分水岭——它让 PG 在 NoSQL 入侵 RDBMS 的时代站稳了”半结构化”位置，至今仍是 PG 19.

7.4 9.x 时代的”扩展机制”成熟

9.x 时代 PG 暴露了5 大扩展点，让外部代码可以在不动内核的情况下造分支：

关键观察：正是因为这 5 大扩展点，2010 年以后几乎所有的 PG 分支都不再 fork 内核，而是基于”内核 + extension / hook / FDW”的形态。这就是为什么 PG 分支生态如此繁荣、却又如此”可合并”。

7.5 同期生态大事

八、大版本时代（2017-2025）：10 / 11 / 12 / 13 / 14 / 15 / 16 / 17 / 18

8.1 9.x → 10 的版本号跃迁（2017-09）

2017 年 9 月，PG 从 9.6 直接跳到 10.0。不是 9.7——这是社区深思熟虑的决定：

• 9.x 命名从 2010 年开始，6 年只有 7 个（9.0 / 9.1 / … / 9.6）；
• 用户对 “9.5 vs 9.6” 这种 minor 版本之间的差异期望太低；
• 跳到 10.0 意味着每年一个主版本，**”每年都该有大事”**。

8.2 10.x → 18.x 全表

8.3 每年大版本的”商业意义”

节奏观察：从 2017 年起 PG 进入”大版本时代”，每年 9-10 月发版，每个版本对应一个主题。这跟 Linux Kernel 的”每年两个大版本”节奏不同，更接近 Ubuntu 的”每半年 LTS”节奏。

8.4 18 的两条主线：异步化 + 多态

新版本最核心的两条主线：

九、分支与衍生品：39 年家谱

PostgreSQL 的”可扩展性”让它成为开源数据库里分支生态最繁荣的一支。

9.1 主流分支家谱

9.2 分支按方向矩阵

右下角 X 轴 → Y 轴：X 轴是从”保留内核”到”重写内核”，Y 轴是”OLTP/通用”到”垂直/分析”。

• PG 主线 + PostGIS + TimescaleDB / Citus 都在左边（不动内核）；
• CockroachDB + Neon + YugabyteDB + Aurora + AlloyDB 在右边（动内核）；
• Greenplum 在右上（重度垂直 + 重写内核）；
• Citus 变绿后逐步向”右边”靠拢（深度改造 HA 概念）。

9.3 关键分支大事记

十、关键人物与社区治理

10.1 核心贡献者时间线

观察：1995-2004 入坑的人大多仍在提交代码。PG 的代码作者极其稳定，这是 PG 39 年演化质量的根本原因。

10.2 治理结构

PG 治理 3 个独特点：

1. 没有公司实体——只有 SPI（Software in the Public Interest）这个非营利组织代管钱和商标；
2. 没有 GitHub 独裁——commit 权靠邮件列表的 -1 veto 制衡；
3. 没有版本独裁者——每个 major release 有一个 release manager（如 18 是 Andres Freund），但只是协调者。

10.3 关键决策的”邮件线程”

PG 文化核心：所有重大决策都在公开邮件列表上讨论。读 pgsql-hackers archive 就能学到 PG 39 年的设计权衡。

十一、PostgreSQL vs MySQL vs SQLite：开源 RDBMS 的三岔口

11.1 三者定位对比

11.2 三者基因对比

11.3 三者关系：MySQL 也用过 POSTGRES 思想

冷观察：**MySQL 的原始名字其实是”Monty’s SQL”**，跟 PostgreSQL 完全没有血缘。MySQL 后来用了 MVCC / SQL / 联系墙这些概念，是因为 2000s 业界共识，不是因为 “PG 影响 MySQL”。

十二、影响 PG 39 年的 10 个关键决策

十三、时间线速查表

按年份汇总所有重要事件：

十四、未来 5 年的趋势与未完成的事

PG 39 年演化还有 5 件”未完成的事”：

14.1 未完成的 5 大特性

14.2 5 年趋势预测

十五、总结：39 年沉淀的 6 个心智模型

读完 39 年演化，PG 给你的 6 个心智模型：

PG 的 39 年，本质上是 6 个心智模型的实现：

1. 学术严谨 + 工程师实用：POSTGRES 用研究项目出发，靠 SQL 化 + BSD 版权进入生产；
2. 节奏稳定 + 机制灵活：每年 1 个大版本，minor 只修 bug；PGDG 的 release manager 制；
3. 严格标准 + 灵活扩展：PG 是 SQL 标准的”守护者”，但提供 FDW / AM / Background Worker / Hook / Extension 5 类扩展点；
4. 关系模型 + 半结构化：从纯 SQL 到 9.4 jsonb 的演进，证明 PG 能跟 NoSQL 共存；
5. 内核精简 + 生态繁荣：每年合并的 patch 中，extension 的贡献占比越来越高；
6. 社区治理 + 法律实体：PGDG + SPI + 邮件列表，commit 权靠共识 + reviewer。

源码引用索引

POSTGRES 论文（学术）：

• Stonebrandon, M. 1986. “The Design of POSTGRES.” SIGMOD.
• Stonebrandon, M. 1989. “The Case for Partial Indexes.” SIGMOD.
• Stonebrandon, M. 1990. “On Rules, Procedures, Caching and Views.” ICDE.
• Stonebrandon, M. 1995. “The Case for Partial Indexes.” （重印）

PG 内核代码：

• src/backend/access/transam/xact.c — 事务引擎（9.x 起定型）
• src/backend/storage/ipc/standby.c — 流复制（9.0 起）
• src/backend/replication/logical/ — 逻辑复制（10 起）
• src/backend/access/heap/heapam.c — heap AM（12 可插拔）
• src/include/catalog/pg_class.dat — catalog 定义
• src/include/utils/relcache.h — Relation 结构

PG 历史项目：

• pgsql-hackers 邮件列表 archive（1996 起）
• pgCon 大会（2005 起）
• PGDG GitHub（2016 起，仅镜像）
• PG 官网 postgresql.org/docs/release-history

同系列前文

• PostgreSQL 元数据存储机制：从磁盘文件到内存缓存，pg_class 撑起的整个系统表体系
• PostgreSQL 从 postgres 二进制到生产级守护：最外层模块与启动全流程
• PostgreSQL 内存管理：从 shared_buffers 到内存上下文
• PostgreSQL 事务生命周期：从 BEGIN/COMMIT 到 CLOG 一条链路
• PostgreSQL MVCC：从一行 UPDATE 到 5 个 HeapTuple 的演化
• PostgreSQL 18 并行 Worker 机制全解
• PostgreSQL Background Worker 全解
• PostgreSQL 内核开发：读取一张表的 9 步标准流程与缓存全景
• PostgreSQL 逻辑复制表的生命周期：从 pg_replication_slots 到 pg_subscription_rel
• pgbench 源码全解：一个 C 文件如何撑起 PostgreSQL 官方压测工具