由 John Doe 七月 2, 2026
PostgreSQL 从最开始的学术弃子，成为了现在的云时代底层基石。
目录
导语
如今 PostgreSQL 已是全球应用最广泛的数据库之一，但它的诞生与早期发展历程，只能用命运多舛来形容。
倘若没有一群极度热忱的开源贡献者接力维护，它大概率会像其前身 Ingres 一样，沦为被世人遗忘的淘汰技术。“Postgres” 本就是 “后 Ingres（Ingres 继任者）” 的缩写。
这两款数据库的缔造者迈克尔・斯通布雷克，堪称数据库领域殿堂级先驱。本月初，他出席了由美国 PostgreSQL 协会在波士顿举办的 PGDay 技术大会，详细讲述了这款开源数据库曲折的发展历程 —— 它诞生的年代，甚至还没有 “开源” 这个概念。
斯通布雷克表示：“某种意义上，Postgres 就是开源软件的典范，因为它不属于任何一家机构。一群无任何企业隶属关系的程序员自发接手了这个项目。”
上世纪 90 年代中期，斯通布雷克基本放弃了 Postgres 项目。但这套代码并未就此销声匿迹，一群意志坚定的志愿者社区接手改造，在保留斯通布雷克设计的可扩展革新架构的基础上，为它适配了标准 SQL 语法。
三十年后，这款始终保持独立内核的数据库，已然成为现代云基础设施的底层支柱。
数据理应采用关系模型
说到关系型数据库，要追溯至 1970 年，彼时任职 IBM 的英国计算机科学家泰德・科德首次提出相关理论。数据库是存储数据的载体，支持以标准化方式查询数据；数据库系统则是管理数据库的软件，二者切勿混淆。
当年科德提出：所有数据都应存储在数据表中，并通过高级查询语言访问。IBM 基于这套理论研发 System R 系统，创造出 SQL 查询语言，相关技术最终落地为 IBM DB2 数据库。
彼时任职加州大学伯克利分校助理教授的斯通布雷克，同样落地了科德的理论。他带领研究生团队不仅做出可用原型，还完成了完整商用版本；后续他联合创办 Relational Technology 公司，将 Ingres 推向市场。Ingres 并未采用 SQL，而是自研查询语言 QUEL，但底层核心逻辑相通。
早期简易版 Ingres 曾免费开放给学术界研究。但到 80 年代初，斯通布雷克搁置了 Ingres 代码，着手研发全新数据库，Postgres 就此诞生。
超越 Ingres：Postgres 的诞生初衷
斯通布雷克解释，当时企业业务需求发生变化：基础财务记账所需的整型、浮点、字符串数据类型已无法满足需求，企业需要存储复杂 CAD 图纸、地理信息 GIS 数据，这类多维度数据需要数据库具备存储与解析能力。
斯通布雷克与团队意识到，理想数据库必须支持扩展自定义数据类型、自定义运算符、自定义函数。
看似只是新增数据类型，实则细节难题重重。他提到：“你需要让查询优化器识别新增类型，这件事难度不小。” 团队还要推导各类交换运算规则，并完成对应优化。
由此诞生了 Postgres 史上最成功的核心特性：抽象数据类型（ADT）。
除此之外，斯通布雷克还给 Postgres 定下更多目标：融合克里斯・戴特提出的参照完整性理论，为关系模型赋予主键与外键语义一致性；内置规则引擎，持续监控数据变更并自动执行对应逻辑；实现数据库崩溃恢复能力。
最终崩溃恢复与规则引擎两大功能未能打磨成熟，但抽象数据类型落地生根。如今绝大多数数据库的扩展能力，都沿用了 1983 年斯通布雷克团队的设计思路。
他坦言：“当年这套设计思路基本走对了。” 事实上，他认为自己在抽象数据类型上的研究，正是其斩获 2014 年 ACM 图灵奖的核心原因。
斯通布雷克团队希望依靠这套技术商业化，于是基于 Postgres 创立 Illustra 公司，这家企业后来被 Informix 收购，相关技术也整合进 Informix 自有数据库。
不过团队也勉强维护了一套开源版本 —— 彼时还没有 “开源” 这一正式术语，它仅被视作免费学术研究软件，供科研人员二次修改，采用宽松的 BSD 开源协议。
屹立不倒的底层架构
1995 年，伯克利两名研究生安德鲁・余、乔利・陈基于最后一版 4.2 学术发行版重启 Postgres 开发。他们砍掉运行效果糟糕的规则引擎与故障恢复模块，最关键的改动是舍弃 QUEL，替换为当时行业通用的 SQL，推出 Postgre95，后续正式定名 PostgreSQL。
谈及这支纯志愿者开发团队，斯通布雷克说：“我和他们素不相识。这群顶尖程序员接手了这个开源项目并持续深耕，一晃三十年。”
完全中立无归属的特性，让任何人都能自由使用、修改 Postgres。它的通信协议被大量用作新型数据库的底层基座，包括 CockroachDB、YugabyteDB、TimescaleDB。亚马逊云、微软 Azure、谷歌云均推出基于 Postgres 的托管数据库服务，核心卖点就是 100% 兼容 Postgres。
他评价道：“各大云厂商巨头基本都把筹码全押在了 Postgres 身上。”
就连 AWS 的图数据库服务，底层同样基于 Postgres 构建。斯通布雷克打趣：“用关系型数据库实现图数据库，性能往往远高于原生图数据库引擎，差距十分明显。”
稳居行业第一梯队
目前在 DB-Engines 全球数据库热度榜单中，Postgres 稳居前列，仅次于 Oracle、MySQL 与微软 SQL Server。但和竞品不同，Postgres 的市场份额仍在持续稳步上涨。
本次 PGDay 活动组织者、Postgres 服务商 EDB 副总裁汤姆・金凯德分析了 Postgres 逆势崛起的核心原因。不同于 MySQL（现归属 Oracle，不少开源开发者对此心存芥蒂），Postgres 初期没有任何大型科技巨头扶持，却依旧站稳脚跟。
极强的可扩展性是普及关键。数据库业务早已不止财务记账，抽象数据类型让 Postgres 轻松切入地理信息市场，后续又适配文档型数据场景。
金凯德接受《The Register》采访时表示：“Postgres 能快速满足开发者存储、检索、查询 JSON 文档的需求。SQL 与多类型数据融合的特性，让它紧跟每一轮应用开发技术浪潮。”
高质量代码库与优化器同样吸引顶尖开发者：“项目代码审查标准严苛，门槛极高。” 宽松的 BSD 协议也降低了创业团队二次开发衍生产品的法律风险。
为何 Postgres 至今缺少文件级加密
尽管广受开源社区青睐，Postgres 仍缺失多项商用数据库标配功能，想要完全对标商业数据库仍有差距。
资深 Postgres 核心贡献者布鲁斯・蒙吉安在本次 PGDay 带来一场干货分享，梳理了一长串待开发功能，其中多数正在推进开发：
支持 64 位事务 ID 以承载超大数据库、适配大规模数据分析的列存引擎、全局索引、服务端多线程、内置连接池、分片分库等功能，均处于不同开发阶段。
但目前最核心的短板是文件级加密，行业内又称透明数据加密（TDE）。所有商用数据库厂商均已支持该功能，同时存储金融交易数据的 PCI DSS 支付行业合规标准强制要求此项能力。当前 Postgres 仅能依靠操作系统层实现加密。
蒙吉安表示，Postgres 文件级加密开发项目推进举步维艰：“投入巨大开发成本，但实际收益有限。” 不仅读写数据文件的底层函数需要重构，系统内所有生成临时文件的逻辑都要同步改造，工程量极其庞大。
不过功能缺失也给商业厂商留出差异化空间，例如 Percona 就在自家商业发行版中内置了 TDE 能力。
商业数据库厂商会优先满足客户诉求，无论需求是业务技术刚需，还是单纯合规硬性要求。
蒙吉安提到，合规类需求很难被社区开发团队优先排期：“我们只愿意开发具备实际技术价值的功能。”
从纯技术角度看，PCI 加密规范本身也存在明显短板：数据一旦加载至服务器内存，加密保护便直接失效。如果攻击者绕过文件系统权限，就能读取内存原始数据，窃取加密密钥。
“就算我们加固文件系统，也必须同步保护内存，目前社区没有成熟可行的方案。”
但换个角度看，缺失 TDE 或许并非缺陷，而是 Postgres 底层设计理念的体现。
“商用数据库优先服务头部大客户的专属场景，而 Postgres 面向全行业通用用户。”
对于开源项目而言，这或许才是最高级别的成功。
参考
The database that refused to die: How Postgres survived its own creators