导读：本文与各位聊聊Postgres的未来与它的发展简史、产品特性。

各位开发者和数据库管理者，如今PostgreSQL 已经不仅仅是一个单纯的关系数据库；它还是一个数据管理框架，有可能吞没整个数据库领域。

“一切皆可用 Postgres”的趋势不再局限于少数精英研发团队，而是正在成为主流的最佳实践。

Postgres发展史

Postgres 的起源始于 Ingres 项目。它最初是在加州大学伯克利分校Michael Stonebraker 的指导下以 Ingres（交互式图形 RE trieval 系统）的 形式开始的。

这个团队改变和优化了数据库课程，还资助了一个关系数据库项目。

最初使用的语言是 QUEL，还不是标准 SQL。ANSI 在 1986 年正式设定了对 SQL 的偏好，许多关系数据库项目都朝着这个方向发展。1995 年 Postgres95 发布时添加了 SQL 支持。

1996 年，当 PostgreSQL 的第一个版本 6.0 发布，开发小级的工作正式走出了学术界，并且成立了 PostgreSQL 全球开发团队，这也是目前领导该项目的小组。

如今，在使用可靠的数据库时，很多事情人们都认为是理所当然的事，实际上都是一点点发展起来的。

2000年，Postgres开始了成长之旅。从那年开始，Postgres 开始使用外键和连接支持，与其它数据库等级持平。

2002 年左右有了更多关键的基础部分，主要关注成为可靠的数据库和 SQL，包括以预写日志( WAL )、外连接、模式以及能够在现实中可能支持 4亿 笔交易等。

此外针对IPv6，Postgres 也很早就开始研究这个问题了。

Postgres 社区中的支柱包括 Tom Lane、Josh Berkus、Bruce Momjian、Hiroshi Inoue 和 Peter Eisentraut。

其中一位说：“参与 Postgres 的每个人都对其前景感到非常满意。他们认为这里存在更广的市场机会。而Oracle 已经是一个整体，所以想象并不容易。但开源数据库浪潮正开始达到顶峰。”

进入 2000 年代后期，特别是 2005 年前，Postgres 已经可以被视为一个相当可靠的数据库。凭借更丰富的事务支持、广泛的 SQL 支持以及 WAL 和 VACUUM 等改进。如果你是它的早期采用者，你会开始信任它来处理生产工作负载。

虽然它是值得信赖的，但在易用性方面仍有一些路要走。此时，我们开始看到具有多个不同主题的功能组合，包括如下：

• 并发索引创建

• 热备服务器

• 查询语言改进

• 所有数据类型 - 数组、UUID、ENUM、XML

• 二阶段提交

• 更丰富的用户角色系统

从系统早期开始，我们看到一群人一直在参与其中，但其他的人们也开始加入并贡献功能。

2009 年，Postgres 8.4 提供了窗口函数和公共表表达式 (CTE)，有了这些，我个人就再也不会回头用另外一个数据库了。

有了 Postgres 作为坚实的基础，大约在这个时候我们开始看到它在更广泛的数据生态系统开始印记。

由于坚实的代码库以及其宽泛的许可证，许多公司采用了 Postgres 并开始对其进行分叉。

在 2000 年代初期到后期，大多数公司要做的第一件事就是向 Postgres 添加 MPP 支持，以便它可以针对更多以 OLAP 为中心的工作负载。当人们将其与对窗口函数和 CTE 等内容的支持相结合时，就将拥有一些新的、强大的东西，而无需从头开始构建它。

这种类型的产品可以缩短数据库成熟所需的时间。许多原来的分叉今天已经不存在了，但有些仍然存在于其他产品中......

• Aster Data → 被 Teradata 收购
  

• Truviso → 被思科收购

• Netezza → 被 IBM 收购

• Greenplum → 被 EMC 收购

• ParAccel → 从未被收购，但实际上成为了 RedShift

尽管 Postgres 分叉出现了一些分散，但Postgres 仍然继续做它一直在做的事情——继续前进。

Postgres 9.0 和 9.1的发布，也就是在2010年，这是 Postgres 变酷的开始。开始对监听/通知（数据库中的发布-订阅）和 hstore（键/值数据类型）等功能的支持打破陈旧的关系数据库模式。借助对 pg_upgrade.随着 GIN 和 GiST 索引的出现，人们开始获得的不仅仅是标准 B 树索引。

扩展始终是 Postgres 的一部分，但通过集成中的一些重构，它们变得更容易为用户所用。我们看到了 Postgres 外部数据包装器的开发，因此可以连接不同的 Postgres 数据库。

不仅仅是旧的无聊的数据类型、列和关系。然而，所有这些都是建立在同一个符合 ACID 的、值得信赖的基础上的。

如果世界现在还没有注意到 Postgres，那么你已经被敲响了警钟。

随着大数据浪潮开始降温，但 NoSQL 数据库（Mongo 和 Couchbase）的兴起，很明显开发人员想要一种不同的方式来处理他们的数据。Postgres 也听取了意见，但后来却因为它的 JSON 支持而被欺骗了。在 9.2 中提供 JSON 验证，但被扔到文本字段中。

事实上，我们还得再等两年才能在 Postgres 中获得可靠的 JSON 支持。

但是这些都是成长中的必经之路，不是大问题，随着用于轻松应用程序部署—— Heroku 的兴起，Heroku Postgres 成为默认数据库，从 MySQL 数据库的共享托管和应用程序的 VPS 到 PaaS 以及更专用的数据库基础设施的浪潮正在不断增长。

后来的 Postgres 9.3 版本很棒，我们有横向连接、可更新的外部表、校验和等等。在 9.4 中，我们在 JSONB数据类型中得到了更好的 JSON支持。这是磁盘上 JSON 的二进制表示形式，这意味着 GIN 索引可以让更轻松地为数据建立索引，而无需在非常具体的 JSON 函数上建立索引。

JSONB 是一种当人们第一次听说它时，令人震惊的数据类型和功能。

Postgres 不仅仅适合需要闪亮功能的应用开发人员。逻辑解码为未来几年在 Postgres 中更轻松地捕获变更数据 ( CDC )奠定了基础。刷新物化视图可以实现更丰富的报告用例。后台工作人员启用了更多功能和创造性用例，特别是对于扩展来说。

亚马逊随后在 Re:Invent 上宣布支持 RDS 上的 PostgreSQL。人们记得参加过 Re:Invents 活动房间里，是唯一一次观众起立鼓掌的表演。

2016年，小组发布了9.5、9.6、10。此时，我们开始达到标题功能写不全的地步，相反地，我们看到了稳定的性能改进和持续增强现有功能的主题。JSONB 获得了对内联更新的支持，并且开始看到更多并行执行支持的出现。但这并不全是小更新，根据人们的需求，这里可能有你一直渴望的主要功能。一些亮点包括：

• 行级安全性

• 逻辑复制

• 表分区

几年来，PostgreSQL的进步很大程度上仍然是个人贡献者的结果。我们还看到一些公司在 EnterpriseDB（专注于 Oracle 兼容性）、2ndQuadrant（专注于复制）、Postgres Pro（专注于 JSONB）和 Crunchy Data（专注于安全性和云原生）等特定领域进行了共同努力。

OLAP 的新挑战者

曾在 2016 年的一次数据库管理员聚会中，我认为 PostgreSQL 生态系统中的一个重大差距是缺乏适用于 OLAP 工作负载，并且足够好用的列式存储引擎。

虽然 PostgreSQL 本身也提供了大量的分析功能，但其对较大数据集进行全面分析的性能并不能完全达到专用的实时数据仓库的水平。

我们考虑过ClickBench（https://benchmark.clickhouse.com/），一个分析性能基准，我们在其中记录了 PostgreSQL、其生态系统扩展和衍生数据库的性能。

其中：未调优的 PostgreSQL 性能较差 ( x1050 )，但通过优化可以达到 ( x47 )。此外，还有三个与数据分析相关的扩展：列式存储Hydra ( x42 )、时间序列TimescaleDB ( x103 ) 和分布式Citus ( x262 )。

以上的性能并不算差，特别是与 MySQL 和 MariaDB（x3065、x19700）等纯 OLTP 数据库相比；然而，它的第三层性能还不够“好”，落后于 Umbra、ClickHouse、Databend、SelectDB（x3~x4）等第一层 OLAP 组件一个数量级。

这是一个棘手的地方——使用起来不够令人满意，但又太好了而无法丢弃。

然而， ParadeDB和DuckDB的到来，进而改变了游戏规则。

ParadeDB的原生 PG 扩展pg_analytics实现了第二层性能 ( x10 )，将与顶层的差距缩小到仅 3-4 倍。考虑到额外的优势，这种水平的性能差异通常是可以接受的。

无需 ETL 的 ACID、新鲜度和实时数据，无需额外的学习曲线，无需维护单独的服务，更不用说其 ElasticSearch 级全文搜索功能。

DuckDB专注于纯粹的 OLAP，将分析性能推向极致（x3.2）——排除专注于学术的闭源数据库 Umbra，DuckDB 可以说是实用 OLAP 中性能最快的。它不是 PG 扩展，但 PostgreSQL 可以通过DuckDB FDW（地址：https://github.com/alitrack/duckdb_fdw）和pg_quack（地址：https://github.com/hydradatabase/pg_quack）等项目都充分利用 DuckDB 作为嵌入式文件数据库的分析性能提升。

ParadeDB和DuckDB的出现，将PostgreSQL的分析能力推向了OLAP的顶级，填补了它在分析性能的最后一个关键空白。

数据库领域的钟摆

OLTP 和 OLAP 之间的区别在数据库诞生之初，存在与否。由于传统 OLTP 数据库难以支持分析场景的查询模式和性能需求，OLAP 数据仓库与数据库的分离开始出现于 20 世纪 90 年代。

长期以来，数据处理的最佳实践涉及使用 MySQL/PostgreSQL 处理 OLTP 工作负载，并通过 ETL 流程将数据同步到专门的 OLAP 系统，比如 Greenplum、ClickHouse、Doris、Snowflake 等。

这里比较的元素，包括从成本，冗余数据、过多的数据移动、分布式组件之间的数据缺乏一致、专业技能的额外劳动力费用、额外的许可成本、有限的查询语言能力、可编程性和可扩展性、有限的工具集成、较差的数据完整性和可用性与完整的DMBS 的维度对比。

随着硬件遵循摩尔定律三十多年来不断改进，性能呈指数级增长，而成本却直线下降。到 2024 年，单个 x86 服务器可以拥有数百个核心（512 个 vCPU、EPYC 9754 x2）、数 TB RAM、单个NVMe SSD 可以容纳高达64TB / 3M 4K rand IOPS / 14GB /s，以及单个全闪存架可达数PB；像 S3 这样的对象存储提供了几乎无限的存储空间。

硬件的进步解决了数据量与性能问题，而数据库软件的开发（PostgreSQL、ParadeDB、DuckDB）则解决了访问方法的挑战。这使得分析行业（即所谓的“大数据”行业）的基本假设受到审视。

如果现在可以在具有独立 PostgreSQL/DuckDB（及其副本）的单台计算机上处理 99% 的用例，那么使用专用分析组件还有什么意义？

如果每部智能手机都可以自由地发送和接收文本，那么寻呼机还有什么意义呢？（需要大家注意的是，北美地区医院仍在使用寻呼机，这表明可能只有不到 1% 的场景真正需要“大数据”。）

基本假设的转变正在引导数据库世界从多元化阶段回到趋同阶段，从大爆炸转向大规模灭绝。

在这个过程中，一个统一、多模型、超融合的数据库新时代即将出现，OLTP和OLAP重新统一。但谁将领导这项重新整合数据库领域的艰巨任务呢？

PostgreSQL：数据库世界的吞噬者

数据库领域有很多技术利基：时间序列、地理空间、文档、搜索、图形、矢量数据库、消息队列和对象数据库。PostgreSQL 在所有这些领域中都体现了它的存在。

一个典型的例子是 PostGIS 扩展，它为地理空间数据库设定了事实上的标准；TimescaleDB 扩展尴尬地定位了“通用”时间序列数据库；向量扩展PGVector将专用向量数据库利基变成了笑点。

这已经不是第一次了；我们在最古老、最大的子领域再次见证了这一点：OLAP 分析。但 PostgreSQL 的野心并不止于 OLAP；它现在正在关注整个数据库世界！

极致可扩展性的魔力

PostgreSQL 不仅仅是一个关系数据库；它是一个能够吞没整个数据库星系的数据管理框架。除了开源、先进之外，其核心竞争力还源于可扩展性，即基础设施的可重用性和扩展的可组合性。

PostgreSQL 允许用户开发扩展，利用数据库的通用基础设施以最低的成本提供功能。例如，矢量数据库扩展pgvector仅有几千行代码，与 PostgreSQL 的数百万行代码相比，其复杂性可以忽略不计。

pgvector地址：

https://github.com/pgvector/pgvector

然而，这种“微不足道”的扩展实现了完整的矢量数据类型和索引功能，却优于许多专用矢量数据库。

为什么？因为 pgvector 的创建者不需要担心数据库一般的额外复杂性：ACID、恢复、备份和 PITR、高可用性、访问控制、监控、部署、第三方生态系统工具、客户端驱动程序等，这些都需要数百万个几行代码就很好解决了。他们只关注问题的本质复杂性。

例如，ElasticSearch 是在 Lucene 搜索库上开发的，而 Rust 生态系统有一个改进的下一代全文搜索库Tantivy，作为 Lucene 的替代品。

Tantivy地址：

https://github.com/quickwit-oss/tantivy

ParadeDB 只需要包装并连接到 PostgreSQL 的接口即可提供与 ElasticSearch 相当的搜索服务。

更为重要的是，它可以站在PostgreSQL的肩膀上，利用整个PG生态系统的联合力量（例如与pgvector的混合搜索）与另一个专用数据库进行“不公平”竞争。

请看下图：

此外，分布式扩展Citus可以透明地将独立集群转变为水平分区的分布式数据库集群。

Citus地址：

https://www.citusdata.com/

该功能可以与其它产品功能组合，比如使PostGIS成为分布式地理空间数据库，PGVector成为分布式矢量数据库，ParadeDB成为分布式全文搜索数据库等等。

更强大的是，扩展是独立发展的，不需要繁琐的主分支合并和协调。这种技术使得PG的可扩展性让众多团队可以并行探索数据库的可能性增大，所有扩展都是可选的，不会影响核心功能的可靠性。那些成熟、健壮的功能有机会稳定地集成到主分支中。

PostgreSQL通过极致可扩展性的“魔力”实现了基础可靠性和敏捷功能，使其成为数据库世界中的异类，并改变了数据库格局的游戏规则。

DB Arena 的游戏规则改变者

PostgreSQL 的出现改变了数据库领域的范式：致力于打造“新数据库内核”的团队现在面临着一项艰巨的考验：如何在开源、功能丰富的 Postgres 中脱颖而出。

那么，他们独特的价值主张是什么？

在出现革命性的硬件突破之前，实用的、新型的通用数据库内核的出现似乎不太可能。目前还没有任何一个单一的数据库可以与 PG 的整体实力相媲美，在其所有扩展的支持下，即使是 Oracle，也无法与 PG 的开源和免费的王牌相媲美。

如果一个利基数据库产品能够在特定方面（这通常是性能）比 PostgreSQL 好一个数量级，那么它可能会为自己开辟出一席之地。然而，通常用不了多久，PostgreSQL 生态系统就会产生开源扩展替代品。选择开发 PG 扩展而不是全新的数据库可以让球队在追赶时获得碾压性的速度优势！

按照这个逻辑，PostgreSQL 生态系统将滚雪球一般，不断积累优势，并不可避免地走向垄断，在几年内反映 Linux 内核在服务器操作系统中的地位。开发者调查和数据库趋势报告中亦证实了这一轨迹。

PostgreSQL 长期以来一直是 HackerNews 和 StackOverflow 中最受欢迎的数据库。许多新的开源项目默认将 PostgreSQL 作为主要（如果不是唯一）数据库选择。

PostgreSQL 与大多数其他关系数据库最根本的不同之处之一来自于它的核心设计。

大多数关系数据库最好被描述为关系数据库管理系统（RDBMS）。RDBMS 是专门为处理关系数据库而设计的软件，其中数据存储在具有预定义列和数据类型的表状结构中。可以使用基于关系代数的技术（通常通过结构化查询语言（SQL））来查询、修改和检索数据。

另一方面，PostgreSQL 从技术上来说是一个对象关系数据库管理系统 (ORDBMS)。这意味着它具有与 RDBMS 相同的关系功能，但还具有一些面向对象的功能。

实际上，这意味着 PostgreSQL 允许你：

• 定义你自己的复杂数据类型

• 重载函数以处理不同的参数数据类型

• 定义表之间的继承关系

这些功能是强大的工具，可帮助你使用编程时可能熟悉的一些相同技术来处理数据库和数据。增加的灵活性使您可以在数据库系统内而不是在程序外部对不同类型和关系进行建模。这可以帮助保持一致性并强制执行更接近实际数据的预期行为。

PostgreSQL 是一个由PostgreSQL 全球开发小组管理的开源项目。它使用PostgreSQL 许可证进行许可，这是开源促进会认可的许可证。

虽然还有许多其他开源关系数据库，但 PostgreSQL 是在没有企业所有者或商业同行的情况下开发和管理的。这有助于贡献者制定自己的道路并致力于社区最关心的功能。PostgreSQL 的专业服务由经常为项目做出贡献但不控制开发过程的公司提供。

这种对社区驱动开发的关注导致了 PostgreSQL 用户的大力参与。大量高质量的扩展和应用程序可用于增强核心 PostgreSQL 软件的功能。社区开发的软件可以帮助您管理 PostgreSQL 服务器、编译商业智能报告、管理新类型的数据以及通过各种编程语言和平台使用 PostgreSQL。

而现在，许多新一代公司正在全力以赴地使用 PostgreSQL。

就像“ Radical Simplicity: Just Use Postgres ”所说，“Just Use Postgres”可以实现简化技术堆栈、减少组件、加速开发、降低风险和添加更多功能。

Postgres 可以替代许多后端技术，包括 MySQL、Kafka、RabbitMQ、ElasticSearch、Mongo 和 Redis，轻松为数百万用户提供服务。Just Use Postgres不再局限于少数精英团队，而是成为主流的最佳技术实践。

各位，你的选择将塑造数据库世界的未来。我希望本文可以帮助你更好地利用世界上最先进的开源数据库内核：PostgreSQL。