为什么说PostgreSQL前途无量？

PostgreSQL并不是一个简单的关系型数据库，而是一个数据的抽象框架，具有吞噬整个数据库世界的力量。而这也是正在发生的事情——“一切皆用Postgres”已经不再是少数精英团队的前沿探索，而是成为了一种进入主流视野的最佳实践。

OLAP领域迎来踢馆者

在2016年的一次数据库沙龙里，我提出了一个观点：现在PostgreSQL生态的一个主要遗憾是，缺少一个<>足够好的列式存储分析插件来做OLAP分析。尽管PostgreSQL本身提供了很强大的分析功能集，应付常规的分析任务绰绰有余。但在较大数据量下全量分析的<>性能，相专用的实时数仓仍然有些不够看。

以分析领域的权威评测Clickench为例，我们在其中标注出了PostgreSQL与生态扩展插件以及兼容衍生数据库在其中的性能表现。原生未经过调优的PostgreSQL表现较为拉垮（<>x1050），但经过调优后可以达到（<>x47）；此外还有三个与分析有关系的扩展：列存<>Hydra（<>x42），时序扩展<>TimescaleD（<>x103），以及分布式扩展<>Citus（<>x262）。

这样的分析性能表现不能说烂，因为起MySQL，MariaD这样的纯OLTP数据库的辣眼表现（<>x3065,x19700）确实好很多；但第三梯队的性能表现也绝对说不上足够好，与专注于OLAP的第一梯队组件：Umra，ClickHouse，Dataend，SelectD（<>x3~x4）相，在分析性能上仍然有十几倍的性能差距。食之无味，弃之可惜。

<>然而，<>ParadeD<>和<>DuckD<>的出现改变了这一点！

<>ParadeD提供的PG原生扩展<>pg_yti实现了第二梯队（<>x10）的性能水准，与第一梯队只有3～4倍的性能差距。相对于功能上的收益，这种程度的性能差距通常是可以接受的——ACID，新鲜性与实时性，无需ETL、额外学习成本、的新服务，更别提它还提供了Elastiearch质量的全文检索能力。

而<>DuckD则专注于OLAP，将分析性能这件事做到了极致（<>x3.2）——略过第一名Umra这种学术研究型闭源数据库，DuckD也许是OLAP实战性能最快的数据库了。它并不是PG的扩展插件，但它是一个嵌入式文件数据库，而<>DuckDFDW以及<>pg_quack这样的PG生态项目，能让PostgreSQL充分利用DuckD带来的完整分析性能红利！

ParadeD与DuckD的出现让PostgreSQL的分析性能来到了OLAP的第一梯队与金字塔尖，弥补了PostgreSQL在OLAP性能这最后一块关键短板。

分久必合的数据库领域

数据库诞生伊始，并没有OLTP与OLAP的分野。OLAP数据仓库从数据库中“”出来，已经是上世纪九十年代时候的事了——因为传的OLTP数据库难以支撑起分析场景下的查询模式，数据量与性能要求。

在相当一段时间里，数据处理的最佳实践是使用MySQL/PG处理OLTP工作负载，并通过ETL将数据同步到专用的OLAP组件中去处理，如Greenplum,ClickHouse,Doris,Snowflake等等。

与许多“专用数据库”一样，专业的OLAP组件的优势往往在于<>性能——相原生PG、MySQL上有1～3个数量级的提升；而代价则是数据冗余、大量不必要的数据搬运工作、分布式组件之间缺乏一致性、额外的专业技能带来的复杂度成本、学习成本、以及人力成本、额外的软件许可费用、极其有限的查询语言能力、可编程性、可扩展性、有限的工具链、以及与OLTP数据库相更差的数据完整性和可用性——<>但这是一个合理的利弊权衡。

然而天下大势，<>分久必合，合久必分。硬件遵循摩尔定律又发展了三十年，性能翻了几个数量级，成本下降了几个数量级。在2024年的当下，x86单机可以达到512核几个T的内存，单卡NVMeSSD可达64T，全闪单机柜2P；S3这样对象存储更是能实现几乎没有上限的存储。

硬件的发展解决了数据量的问题，而数据库软件的发展（PostgreSQL，ParadeD，DuckD）解决了查询模式的问题，而这导致分析领域——所谓的“大数据”行业基本工作假设面临挑战。

正如DuckD发表的宣言《<>大数据已死》所主张的：<>大数据时代已经结束了——大多数人并没有那么多的数据，大多数数据也很少被查询。大数据的前沿随着软硬件发展不断后退，99%的场景已经不再需要所谓“大数据”了。

如果99%的场景甚至都可以放在一台计算机上用单机/主从的DuckD或PostgreSQL搞定，那么使用专用的分析组件还有多少意义？如果每台都可以自由自主收发短信，那么P机还有什么存在价值？（北美医院还在用P机，正好也还有1%不到的场景也许的需要“大数据”）

基本工作假设的变化，将重新推动数据库世界从百花齐放的“合久必分”阶段，走向“分久必合”的阶段，从大爆发到大灭绝，大浪淘沙中，新的大一超融合数据库将会出现，重新一OLTP与OLAP。而承担重新整合数据库领域这一使命的会是谁？

吞食天地的PostgreSQL

数据库领域有许多“细分领域”：时序数据库，地理空间数据库，文档数据库，搜索数据库，图数据库，向量数据库，消息队列，对象数据库。而PostgreSQL在任何一个领域都不会缺席。

一个PostG插件，成为了地理空间事实标准；一个TimescaleD扩展，让一堆“通用”时序数据库尴尬的说不出话来；一个向量扩展<>PGVector插件，更是让整个<>专用向量数据库细分领域变成笑话。

同样的事情已经发生过很多次，而现在，我们将在拆分最早，地盘最大的一个子领域OLAP分析中再次见证这一点。但PostgreSQL要替代的可不仅仅是OLAP数仓，它的野望是整个数据库世界！

然PostgreSQL有何德何能，可当此大任？诚然PostgreSQL先进，但Oracle也先进；PostgreSQL开源，但MySQL也开源。PostgreSQL<>先进且开源，这是它与Oracle/MySQL竞争的底气，但要说其一无二的特点，那还得是它的<>极致可扩展性，与繁荣的扩展生态！

PostgreSQL并不是一个简单的关系型数据库，而是一个数据的抽象框架，<>具有囊括一切，吞噬整个数据库世界的力量。而它的核心竞争力（除了开源与先进）来自<>可扩展性，即基础设施的<>可复用性与扩展插件的<>可组合性。

PostgreSQL允许用户开发功能模块，复用数据库公共基础设施，以最低的成本交付功能。例如，仅有两千行代码的向量数据库扩展pgvector与百万行代码的PostgreSQL在复杂度上相可以说微不足道，但正是这“微不足道”的扩展，实现了完整的向量数据类型与索引能力，干翻了几乎所有专用向量数据库。

为什么？因为PGVECTOR作者不需要心数据库的通用额外复杂度：事务ACID，故障恢复，备份PITR，高可用，访问控制，监控，部署，三方生态工具，客户端驱动这些需要成百上千万行代码才能解决好的问题，只需要关注自己所需问题的本质复杂度即可。