OLAP 的新挑战者

在 2016 年的一次数据库聚会上，我认为 PostgreSQL 生态系统中的一个重大差距是缺乏 适用于 OLAP 工作负载的足够好的 列式存储引擎。 虽然 PostgreSQL 本身提供了大量的分析功能，但其对较大数据集进行全面分析的性能并不能完全达到专用的实时数据仓库的水平。

考虑 ClickBench ，一个分析性能基准，我们在其中记录了 PostgreSQL、其生态系统扩展和衍生数据库的性能。 未调优的 PostgreSQL 性能较差 ( x1050 可以达到 ( x47 )，但通过优化 )。 此外，还有三个与分析相关的扩展：列式存储 Hydra ( x42 )、时间序列 TimescaleDB ( x103 ) 和分布式 Citus ( x262 )。

Clickbench c6a.4xlarge、500gb gp2 结果的相对时间

这种性能并不算差，特别是与 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 和 pg_quack 等项目充分利用 DuckDB 作为嵌入式文件数据库的分析性能提升。

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

数据库领域的钟摆

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

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

DDIA ch3，OLTP 共和国和 OLAP 王国

与许多“专业数据库”一样，专用 OLAP 系统的优势通常在于 性能 ——比原生 PG 或 MySQL 实现 1-3 个数量级的提升。 然而，代价 。 是冗余数据、过多的数据移动、分布式组件之间的数据值缺乏一致、专业技能的额外劳动力费用、额外的许可成本、有限的查询语言能力、可编程性和可扩展性、有限的工具集成、较差的数据完整性 与完整的 DMBS 相比的可用性。

然而，俗话说“善有善报，恶有恶报”。 随着 硬件遵循摩尔定律三十多年来不断改进 ，性能呈指数级增长，而成本却直线下降。 2024年，单台x86机器可以拥有数百个核心（512个vCPU EPYC 9754 x2），数TB RAM，单个NVMe SSD可以容纳高达64TB，单个全闪存机架可以达到2PB； 像 S3 这样的对象存储提供了几乎无限的存储空间。

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

正如 DuckDB 的宣言 “ 大数据已死 ” 所暗示的那样， 大数据时代已经结束 。 大多数人没有那么多数据，而且大多数数据很少被查询。 随着硬件和软件的发展，大数据的前沿正在消退，99%的场景都不再需要“大数据”。

如果现在可以在具有独立 DuckDB 或 PostgreSQL（及其副本）的单台计算机上处​​理 99% 的用例，那么使用专用分析组件有何意义？ 如果每部智能手机都可以自由地发送和接收短信，那么寻呼机还有什么意义呢？ （需要注意的是，北美医院仍在使用寻呼机，这表明可能只有不到 1% 的场景真正需要“大数据”。）

基本假设的转变正在引导数据库世界从多元化阶段回到趋同阶段，从大爆炸转向大规模灭绝。 在这个过程中，一个统一、多模型、超融合的数据库新时代将出现，OLTP和OLAP重新统一。 但谁将领导这项重新整合数据库领域的艰巨任务呢？

PostgreSQL：数据库世界吞噬者

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

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

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

是什么让 PostgreSQL 如此强大？ 当然，它很先进，但 Oracle 也很先进； 它是开源的，MySQL 也是如此。 PostgreSQL的优势来自于它的 先进性和开源性 ，这使得它能够与Oracle/MySQL竞争。 但它真正的独特之处在于其 极端的可扩展性和蓬勃发展的扩展生态系统 。

用户 选择 PostgreSQL 的 原因： 开源、可靠、可扩展

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

极致可扩展性的魔力

PostgreSQL 允许用户开发扩展，利用数据库的通用基础设施以最低的成本提供功能。 例如，矢量数据库扩展 pgvector 仅有几千行代码，与 PostgreSQL 的数百万行代码相比，其复杂性可以忽略不计。 然而，这种“微不足道”的扩展实现了完整的矢量数据类型和索引功能， 优于 许多专用矢量数据库。

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

例如，ElasticSearch 是在 Lucene 搜索库上开发的，而 Rust 生态系统有一个改进的下一代全文搜索库 Tantivy ，作为 Lucene 的替代品。 ParadeDB 只需要包装并连接到 PostgreSQL 的接口即可提供与 ElasticSearch 相当的搜索服务。 更重要的是，它可以站在PostgreSQL的肩膀上，利用整个PG生态的联合力量（例如与PG Vector的混合搜索）与另一个专用数据库进行“不公平”竞争。

Pigsty 有 234 个 可用的扩展 。 还有 1000多个 生态系统中

可扩展性还带来了另一个巨大的优势： 扩展的可组合性 ，允许不同的扩展一起工作，产生1+1»2的协同效应。例如，TimescaleDB可以与PostGIS结合用于时空数据支持； 用于全文搜索的 BM25 扩展可以与 PGVector 扩展相结合，提供混合搜索功能。

此外， 分布式 扩展 Citus 可以透明地将独立集群转变为水平分区的分布式数据库集群。 该功能可以与其他功能正交组合，使PostGIS成为分布式地理空间数据库，PGVector成为分布式矢量数据库，ParadeDB成为分布式全文搜索数据库等等。

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

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

DB Arena 的游戏规则改变者

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

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

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

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

StackOverflow 2023 年调查：PostgreSQL，十项全能选手

StackOverflow 过去 7 年的数据库趋势

PostgreSQL 长期以来一直是 HackerNews 和 StackOverflow 中最受欢迎的数据库。 许多新的开源项目默认将 PostgreSQL 作为主要（如果不是唯一）数据库选择。 许多新一代公司正在全力以赴地使用 PostgreSQL。

正如《 Radical Simplicity: Just Use Postgres》 中所说，“Just Use Postgres”可以实现简化技术堆栈、减少组件、加速开发、降低风险和添加更多功能 。 Postgres 可以替代许多后端技术，包括 MySQL、Kafka、RabbitMQ、ElasticSearch、Mongo 和 Redis，轻松为数百万用户提供服务。 Just Use Postgres 不再局限于少数精英团队，而是成为主流最佳实践。

还有什么可以做的？

数据库领域的结局似乎是可以预见的。 但我们能做什么，又应该做什么？

对于绝大多数场景来说，PostgreSQL 已经是一个近乎完美的数据库内核，这使得内核“瓶颈”的想法变得荒谬。 以内核修改为卖点的 PostgreSQL 和 MySQL 的分支基本上不会有任何进展。

这与当今 Linux 操作系统内核的情况类似； 尽管 Linux 发行版众多，但每个人都选择相同的内核。 分叉 Linux 内核被认为会造成不必要的困难，业界对此不以为然。

因此，主要的冲突不再是数据库内核本身，而是两个方向——数据库 扩展 和 服务 ！ 前者涉及内部可扩展性，而后者涉及外部可组合性。 就像操作系统生态系统一样，竞争格局将集中在 数据库发行版 上。 在数据库领域，只有那些以扩展和服务为中心的发行版才有机会取得最终成功。

内核仍然不冷不热，MySQL 母公司的分支 MariaDB 已接近退市，而 AWS 则通过在免费内核之上提供服务和扩展而获利，蓬勃发展。 投资已流入众多 PG 生态系统扩展和服务发行版：Citus、TimescaleDB、Hydra、PostgresML、ParadeDB、FerretDB、StackGres、Aiven、Neon、Supabase、Tembo、PostgresAI 以及我们自己的 PG 发行版 — Pigsty 。

PostgreSQL生态系统中的一个困境是许多扩展和工具的独立发展，缺乏一个统一器来协同它们。 例如，Hydra 发布了自己的包和 Docker 映像，PostgresML 也是如此，每个版本都使用自己的扩展来分发 PostgreSQL 映像，并且仅使用自己的扩展。 这些镜像和包与AWS RDS等综合数据库服务相去甚远。

即使像 AWS 这样的服务提供商和生态系统集成商在众多扩展面前也表现不佳，由于各种原因（AGPLv3 许可证、多租户的安全挑战）而无法包含许多扩展， 因此无法利用 PostgreSQL 生态系统扩展的协同放大潜力。

延伸类别 猪圈 RDS 和 PGDG AWS RDS PG 阿里云RDS PG 添加扩展 免费安装 不允许 不允许 地理空间 后地理信息系统3.4.2 邮政地理信息系统3.4.1 邮政地理信息系统3.3.4 时间序列 时间刻度数据库 2.14.2

分配性 其他 12.1

人工智能/机器学习 PostgresML 2.8.1

柱状 九头蛇1.1.1

向量 PG向量0.6 PG向量0.6 大于0.0.1 稀疏向量 PG 稀疏 0.5.6

全文搜索 pg_bm25 0.5.6

图形 阿帕奇时代 1.5.0

GraphQL PG GraphQL 1.5.0

消息队列 PGQ 3.5.0

联机分析处理 pg_analytics 0.5.6

鸭数据库 duckdb_fdw 1.1

CDC wal2json 2.5.3 wal2json 2.5

膨胀控制 pg_repack 1.5.0 pg_repack 1.5.0 pg_repack 1.4.8 点云 PG点云1.2.5

加诺斯点云 6.1 Cloud RDS 上不提供许多重要扩展（PG 16，2024-02-29）

扩展是 PostgreSQL 的灵魂。 没有自由使用扩展的 Postgres 就像做饭没有盐一样，受到巨大的限制。

解决这个问题是我们的主要目标之一。

我们的决心：猪圈

尽管之前接触过 MySQL Oracle 和 MSSQL，但当我在 2015 年第一次使用 PostgreSQL 时，我坚信它未来在数据库领域的主导地位。 近十年后，我从用户和管理员转变为贡献者和开发者，见证了 PG 朝着这一目标迈进。

通过与不同用户的互动发现，数据库领域的缺点不再是内核——PostgreSQL已经足够了。 真正的问题是 利用内核的功能 ，这也是 RDS 蓬勃发展的原因。

然而，我相信这种功能应该像免费软件一样易于使用，就像 PostgreSQL 内核本身一样——可供每个用户使用，而不仅仅是从网络封建领主那里租用。

因此，我创建了 Pigsty ，这是一个包含电池的、本地优先的 PostgreSQL 发行版，作为开源 RDS 替代方案，旨在利用 PostgreSQL 生态系统扩展的集体力量并使对生产级数据库服务的访问民主化。

Pigsty代表 PostgreSQL 的 in Great STY le ， 代表着PostgreSQL 顶峰。

我们定义了六个核心主张来解决 PostgreSQL 数据库服务的核心问题：

可扩展的 Postgres 、 可靠的基础设施 、 可观察的图形 、 可用的服务 、 可维护的工具箱 和 可组合的模块 。

这些价值主张的首字母是 Pigsty 的另一个缩写：

Postgres 、 基础 设施、 图形 、 服务 、 工具箱 、 您 的。

您的图形化 Postgres 基础设施服务工具箱。

可扩展 PostgreSQL 是该发行版的关键。 在最近推出的 Pigsty v2.6 中，我们集成了 DuckDB FDW 和 ParadeDB 扩展，极大地增强了 PostgreSQL 的分析能力，并确保每个用户都可以轻松利用这种能力。

我们的目标是整合 PostgreSQL 生态系统的优势，打造类似于 Ubuntu 数据库世界 的协同力量。 我相信内核争论已经解决，真正的竞争前沿就在这里。

• PostGIS ：提供地理空间数据类型和索引，这是 GIS 的事实标准（& pgPointCloud 、 pgRouting ）。
• TimescaleDB ：添加时间序列、连续聚合、分布式、列式存储和自动压缩功能。
• PGVector ：支持 AI 向量/嵌入和 ivfflat、hnsw 向量索引（以及 用于稀疏向量的pg_sparse ）。
• Citus ：将经典的主从 PG 集群转变为水平分区的分布式数据库集群。
• Hydra ：添加列式存储和分析，可与 ClickHouse 的分析功能相媲美。
• ParadeDB ：将全文搜索和混合检索提升到 ElasticSearch 级别（以及 用于中文标记化的zhparser ）。
• Apache AGE ：图形数据库扩展，为 PostgreSQL 添加类似 Neo4J 的 OpenCypher 查询支持。
• PG GraphQL ：向 PostgreSQL 添加原生内置 GraphQL 查询语言支持。
• DuckDB FDW ：允许通过 PostgreSQL（和 DuckDB CLI）直接访问 DuckDB 强大的嵌入式分析数据库文件。
• Supabase ：基于 PostgreSQL 的开源 Firebase 替代品，提供完整的应用程序开发存储解决方案。
• FerretDB ：基于 PostgreSQL 的开源 MongoDB 替代方案，与 MongoDB API/驱动程序兼容。
• PostgresML ：促进经典机器学习算法，使用 SQL 调用、部署和训练 AI 模型。

开发人员，您的选择将塑造数据库世界的未来。 我希望我的工作可以帮助您更好地利用世界上最先进的开源数据库内核： PostgreSQL 。