PostgreSQL 不仅仅是一个简单的关系数据库；它是一个数据管理框架，有可能吞没整个数据库领域。
“一切皆用 Postgres”的趋势不再局限于少数精英团队，而是正在成为主流最佳实践。
OLAP 的新挑战者
PostgreSQL 生态系统中的一个重大差距是缺乏适用于 OLAP 工作负载的足够好的列式存储引擎。虽然 PostgreSQL 本身提供了大量的分析功能，但其对较大数据集进行全面分析的性能并不能完全达到专用的实时数据仓库的水平。
考虑ClickBench，一个分析性能基准，我们在其中记录了 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和pg_quack等项目充分利用 DuckDB 作为嵌入式文件数据库的分析性能提升。
ParadeDB和DuckDB的出现，将PostgreSQL的分析能力推向了OLAP的顶级，填补了其分析性能的最后一个关键空白。
OLTP 和 OLAP 之间选择之难
OLTP 和 OLAP 之间的区别在数据库诞生之初并不存在。由于传统 OLTP 数据库难以支持分析场景的查询模式和性能需求，OLAP 数据仓库与数据库的分离出现于 20 世纪 90 年代。
长期以来，数据处理的最佳实践涉及使用 MySQL/PostgreSQL 处理 OLTP 工作负载，并通过 ETL 流程将数据同步到专门的 OLAP 系统，如 Greenplum、ClickHouse、Doris、Snowflake 等。
与许多“专业数据库”一样，专用 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 允许用户开发扩展，利用数据库的通用基础设施以最低的成本提供功能。例如，矢量数据库扩展pgvector仅有几千行代码，与 PostgreSQL 的数百万行代码相比，其复杂性可以忽略不计。然而，这种“微不足道”的扩展实现了完整的矢量数据类型和索引功能，优于许多专用矢量数据库。
为什么？
因为 pgvector 的创建者不需要担心数据库一般的额外复杂性：ACID、恢复、备份和 PITR、高可用性、访问控制、监控、部署、第三方生态系统工具、客户端驱动程序等，这些都需要数百万个几行代码就很好解决了。他们只关注问题的本质复杂性。
例如，ElasticSearch 是在 Lucene 搜索库上开发的，而 Rust 生态系统有一个改进的下一代全文搜索库Tantivy，作为 Lucene 的替代品。 ParadeDB 只需要包装并连接到 PostgreSQL 的接口即可提供与 ElasticSearch 相当的搜索服务。更重要的是，它可以站在PostgreSQL的肩膀上，利用整个PG生态的联合力量（例如与PG Vector的混合搜索）与另一个专用数据库进行“不公平”竞争。
可扩展性还带来了另一个巨大的优势：扩展的可组合性，允许不同的扩展一起工作，产生1+1»2的协同效应。例如，TimescaleDB可以与PostGIS结合用于时空数据支持；用于全文搜索的 BM25 扩展可以与 PGVector 扩展相结合，提供混合搜索功能。
此外，分布式扩展Citus可以透明地将独立集群转变为水平分区的分布式数据库集群。该功能可以与其他功能正交组合，使PostGIS成为分布式地理空间数据库，PGVector成为分布式矢量数据库，ParadeDB成为分布式全文搜索数据库等等。
更强大的是扩展是独立发展的，不需要繁琐的主分支合并和协调。这允许扩展——PG的可扩展性让众多团队可以并行探索数据库的可能性，所有扩展都是可选的，不会影响核心功能的可靠性。那些成熟、健壮的功能有机会稳定地集成到主分支中。
PostgreSQL 通过极致可扩展性的魔力实现了基础可靠性和敏捷功能，使其成为数据库世界中的异类，并改变了数据库格局的游戏规则。
DB Arena 的游戏规则改变者
PostgreSQL 的出现改变了数据库领域的范式：致力于打造“新数据库内核”的团队现在面临着一项艰巨的考验——如何在开源、功能丰富的 Postgres 中脱颖而出。他们独特的价值主张是什么？
在出现革命性的硬件突破之前，实用的、新型的通用数据库内核的出现似乎不太可能。没有任何一个数据库可以与 PG 的整体实力相媲美，在其所有扩展的支持下，即使是 Oracle，也无法与 PG 的开源和免费王牌相媲美。
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
挑战与整合
PostgreSQL生态系统中的一个困境是许多扩展和工具的独立发展，缺乏一个统一器来协同它们。例如，Hydra 发布了自己的包和 Docker 镜像，PostgresML 也是如此，每个都发布了带有自己的扩展且仅自己的扩展的 PostgreSQL 镜像。这些镜像和包与AWS RDS等综合数据库服务相去甚远。
扩展是 PostgreSQL 的灵魂。没有自由使用扩展的 Postgres 就像做饭没有盐一样，受到巨大的限制。
整合 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 模型。