PostgreSQL 并不是一個簡單的關系型數據庫，而是一個數據管理的抽象框架，具有吞噬整個數據庫世界的力量。而這也是正在發生的事情 —— “一切皆用 Postgres” 已經不再是少數精英團隊的前沿探索，而是成為了一種進入主流視野的最佳實踐。

OLAP 領域迎來踢館者

在 2016 年的一次數據庫沙龍里，我提出了一個觀點： 現在 PostgreSQL 生態的一個主要遺憾是，缺少一個足夠好的列式存儲分析插件來做 OLAP 分析。盡管PostgreSQL 本身提供了很強大的分析功能集，應付常規的分析任務綽綽有余。但在較大數據量下全量分析的性能，相比專用的實時數倉仍然有些不夠看。

以分析領域的權威評測 Clickbench 為例，我們在其中標注出了 PostgreSQL 與生態擴展插件以及兼容衍生數據庫在其中的性能表現。原生未經過調優的 PostgreSQL 表現較為拉垮（x1050），但經過調優后可以達到（x47）；此外還有三個與分析有關系的擴展：列存 Hydra（x42），時序擴展 TimescaleDB（x103），以及分布式擴展 Citus（x262）。

這樣的分析性能表現不能說爛，因為比起 MySQL，MariaDB 這樣的純 OLTP 數據庫的辣眼表現（x3065,x19700）確實好很多；但第三梯隊的性能表現也絕對說不上足夠好，與專注于 OLAP 的第一梯隊組件：Umbra，ClickHouse，Databend，SelectDB（x3~x4）相比，在分析性能上仍然有十幾倍的性能差距。食之無味，棄之可惜。

然而， ParadeDB 和 DuckDB 的出現改變了這一點！

ParadeDB 提供的 PG 原生擴展 pg_analytics 實現了第二梯隊（x10）的性能水準，與第一梯隊只有 3～4 倍的性能差距。相對于其他功能上的收益，這種程度的性能差距通常是可以接受的 —— ACID，新鮮性與實時性，無需 ETL、額外學習成本、維護獨立的新服務，更別提它還提供了 ElasticSearch 質量的全文檢索能力。

而 DuckDB 則專注于 OLAP ，將分析性能這件事做到了極致（x3.2） —— 略過第一名 Umbra 這種學術研究型閉源數據庫，DuckDB 也許是 OLAP 實戰性能最快的數據庫了。它并不是 PG 的擴展插件，但它是一個嵌入式文件數據庫，而 DuckDB FDW 以及 pg_quack 這樣的 PG 生態項目，能讓 PostgreSQL 充分利用 DuckDB 帶來的完整分析性能紅利！

ParadeDB 與 DuckDB 的出現讓 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 核幾個TB的內存，單卡 NVMe SSD 可達 64TB，全閃單機柜 2PB ；S3 這樣對象存儲更是能實現幾乎沒有上限的存儲。

硬件的發展解決了數據量的問題，而數據庫軟件的發展（PostgreSQL，ParadeDB，DuckDB）解決了查詢模式的問題，而這導致分析領域 —— 所謂的“大數據” 行業基本工作假設面臨挑戰。

正如 DuckDB 發表的宣言《大數據已死》所主張的：大數據時代已經結束了 —— 大多數人并沒有那么多的數據，大多數數據也很少被查詢。大數據的前沿隨著軟硬件發展不斷后退，99% 的場景已經不再需要所謂“大數據”了。

如果 99% 的場景甚至都可以放在一臺計算機上用單機/主從的 DuckDB 或 PostgreSQL 搞定，那么使用專用的分析組件還有多少意義？如果每臺手機都可以自由自主收發短信，那么 BP 機還有什么存在價值？（北美醫院還在用BP機，正好比也還有 1% 不到的場景也許真的需要“大數據”）

基本工作假設的變化，將重新推動數據庫世界從百花齊放的“合久必分”階段，走向“分久必合”的階段，從大爆發到大滅絕，大浪淘沙中，新的大一統超融合數據庫將會出現，重新統一 OLTP 與 OLAP。而承擔重新整合數據庫領域這一使命的會是誰？

吞食天地的 PostgreSQL

數據庫領域有許多“細分領域”：時序數據庫，地理空間數據庫，文檔數據庫，搜索數據庫，圖數據庫，向量數據庫，消息隊列，對象數據庫。而 PostgreSQL 在任何一個領域都不會缺席。

一個 PostGIS 插件，成為了地理空間事實標準；一個 TimescaleDB 擴展，讓一堆“通用”時序數據庫尷尬的說不出話來；一個向量擴展 PGVector 插件，更是讓整個專用向量數據庫細分領域 變成笑話。

同樣的事情已經發生過很多次，而現在，我們將在拆分最早，地盤最大的一個子領域 OLAP 分析中再次見證這一點。但 PostgreSQL 要替代的可不僅僅是 OLAP 數倉，它的野望是整個數據庫世界！

然 PostgreSQL 有何德何能，可當此大任？誠然 PostgreSQL 先進，但 Oracle 也先進；PostgreSQL 開源，但 MySQL 也開源。PostgreSQL 先進且開源，這是它與 Oracle / MySQL 競爭的底氣，但要說其獨一無二的特點，那還得是它的極致可擴展性，與繁榮的擴展生態！

用戶選擇 PostgreSQL 的原因：開源，先進，擴展

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 可以成為分布式全文搜索數據庫，諸如此類。

更強大的地方在于，擴展插件是獨立演進的，不需要繁瑣的主干合并，聯調協作。因此可以 Scale  —— PG 的可擴展性允許無數個團隊并行探索數據庫前研發展方向，而擴展全部都是的可選的，不會影響主干核心能力的穩定性。那些非常強大成熟的特性，則有機會以穩定的形態進入主干中。

通過極致可擴展性的魔法，PostgreSQL 做到了守正出奇，實現了主干極致穩定性與功能敏捷性的統一。扎實的基本盤配上驚人的演進速度，讓它成為了數據庫世界中的一個異數，改變了數據庫世界的游戲規則。

改變游戲規則的玩家

PostgreSQL 的出現，改變了數據庫領域的游戲規則：任何試圖開發“新數據庫內核”的團隊，都需要經過這道試煉與考驗 —— 相比開源免費、功能齊備的 Postgres，價值點在哪里？

至少到硬件出現革命性突破前，實用的通用數據庫新內核都不太可能誕生了，因為任何單一數據庫都無法與所有擴展加持下的 PG 在整體實力上相抗衡 —— 包括 Oracle，因為 PG 還有開源免費的必殺技。

而某個細分領域的數據庫產品，如果能在單點屬性（通常是性能）上相比 PostgreSQL 實現超過一個數量級的優勢，那也許還有一個專用數據庫的生態位存在。但通常用不了多久，便會有 PostgreSQL 生態的開源替代擴展插件滾滾而來。因為選擇開發 PG 擴展，而不是一個完整數據庫的團隊會在追趕復刻速度上有碾壓性優勢！

因此，如果按照這樣的邏輯展開，PostgreSQL 生態的雪球只會越滾越大，隨著優勢的積累，不可避免地進入一家獨大的狀態。在幾年的時間內，實現 Linux 內核在服務器操作系統領域的狀態。而各種開發者調研報告，數據庫流行趨勢都在印證著這一點。

StackOverflow 2023 調研結果，PostgreSQL 三項全能王

StackOverflow過去7年的數據庫指標走勢

在引領潮流的 HackerNews StackOverflow 上，PostgreSQL 早已成為了最受歡迎的數據庫。許多新的開源項目都默認使用 PostgreSQL 作為首要，甚至唯一的數據庫 —— 例如，給各種數據庫做模式管理的 Bytebase。《云時代數據庫DevOps：硅谷調研》也提出，許多新一代互聯網公司都開始積極擁抱并 All in PostgreSQL。

正如《技術極簡主義：一切皆用 Postgres 》所言：簡化技術棧、減少組件、加快開發速度、降低風險并提供更多功能特性的方法之一就是 “一切皆用 Postgres”。Postgres 能夠取代許多后端技術，包括 MySQL，Kafka、RabbitMQ、ElasticSearch，Mongo和 Redis，至少到數百萬用戶時都毫無問題。一切皆用 Postgres ，已經不再是少數精英團隊的前沿探索，而是成為了一種進入主流視野的最佳實踐。

還有什么可以做的？

我們已經不難預見到數據庫領域的終局。但我們又能做什么，又應該做什么呢？

PostgreSQL 對于絕大多數場景都已經是一個足夠完美的數據庫內核了，在這個前提下，數據庫內核卡脖子純屬無稽之談。這些Fork PostgreSQL 和 MySQL 并以內核魔改作為賣點的所謂“數據庫”基本沒啥出息。

這好比今天我們看 Linux 操作系統內核一樣，盡管市面上有這么多的 Linux 操作系統發行版，但大家都選擇使用同樣的 Linux 內核，吃飽了撐著魔改內核屬于沒有困難創造困難也要上，會被業界當成山炮看待。

同理，數據庫內核本身已經不再是主要矛盾，焦點將會集中到兩個方向上 —— 數據庫擴展與數據庫服務！前者體現為數據庫內部的可擴展性， 后者體現為數據庫外部的可組合性。而競爭的形式，正如操作系統生態一樣 —— 集中于數據庫發行版上。對于數據庫領域來說，只有那些以擴展和服務作為核心價值主張的發行版，才有最終成功的可能。

做內核的廠商不溫不火，MariaDB 作為 MySQL 的親爹 Fork 甚至都已經瀕臨退市，而白嫖內核自己做服務與擴展賣 RDS 的 AWS 可以賺的缽滿盆翻。投資機構已經出手了許多 PG 生態的擴展插件與服務發行版：Citus，TimescaleDB，Hydra，PostgresML，ParadeDB，FerretDB，StackGres，Aiven，Neon，Supabase，Tembo，PostgresAI，以及我們正在做的 Pigsty 。

PostgreSQL 生態中的一個困境就是，許多擴展插件，生態工具都是獨立演進，各自為戰的，沒有一個整合者能將他們凝聚起來形成合力。例如，提供分析的 Hydra 會打一個包一個 Docker 鏡像， PostgresML 也會打自己的包和鏡像，各家只發行加裝了自己擴展的 Postgres 鏡像。而這些樸素的鏡像與包也距離 RDS 這樣完整的數據庫服務相距甚遠。

即使是類似于 AWS RDS 這樣的服務提供商與生態整合者，在諸多擴展面前也依然力有所不逮，只能提供其中的少數。更多的強力擴展出于各種原因（AGPLv3 協議，多租戶租賃帶來的安全挑戰）而無法使用。從而難以發揮 PostgreSQL 生態擴展的協同增幅作用。

許多關鍵擴展在RDS中并不可用

擴展是 PostgreSQL 的靈魂，無法自由使用擴展的 Postgres 就像做菜不放鹽。只能和 MySQL 放在同一個 RDS 的框子里同臺，龍游淺水，虎落平陽。而這正是我們想要解決的問題。

知行合一的實踐：Pigsty

雖然接觸 MySQL 和 MSSQL 要早得多，但我在 2015 年第一次上手 PostgreSQL 時，就相信它會是數據庫領域的未來了。快十年過去，我也從 PG 的使用者，管理者，變為了貢獻者，開發者。也不斷見證著 PG 走向這一目標。

在與形形色色的用戶溝通交流中，我早已發現數據庫領域的木桶短板不是內核 —— 現有的 PostgreSQL 已經足夠好了，而是用好數據庫內核本身的能力，這也是 RDS 這樣的服務賺的缽滿盆翻的原因。

但我希望這樣的能力，應該像自由軟件運動所倡導的理念那樣，像 PostgreSQL 內核本身一樣 —— 普及到每一個用戶手中，而不是必須向賽博空間上的封建云領主花大價錢租賃。

所以我打造了 Pigsty —— 一個開箱即用的開源 PostgreSQL 數據庫發行版，旨在凝聚 PostgreSQL 生態擴展的合力，并把提供優質數據庫服務的能力普及到每個用戶手中。

Pigsty 是 PostgreSQL in Great STYle 的縮寫，意為 PostgreSQL 的全盛狀態。

我們提出了六點核心價值主張，對應 PostgreSQL 數據庫服務中的的六個核心問題：Postgres 的可擴展性，基礎設施的可靠性，圖形化的可觀測性，服務的可用性，工具的可維護性，以及擴展模塊和三方組件可組合性。

Pigsty 六點價值主張的首字母合起來，則為 Pigsty 提供了另外一種縮寫解釋：

Postgres, Infras, Graphics, Service, Toolbox, Yours.

屬于你的圖形化 Postgres 基礎設施服務工具箱。

可擴展的 PostgreSQL 是這個發行版中最重要的價值主張。在剛剛發布的 Pigsty v2.6 中，我們整合了上面提到的 DuckdbFDW 與 ParadeDB 擴展，這兩個插件讓 PostgreSQL 的分析能力得到史詩級增強，而我們確保每個用戶都能輕松用得上這樣的能力。

來自 ParadeDB 創始人與 DuckdbFDW 作者的感謝致意

我們希望整合 PostgreSQL 生態里的各種力量，并將其凝聚在一起形成合力，打造一個數據庫世界中的 Ubuntu 發行版。而我相信，內核之爭早已塵埃落定，而這里才會是數據庫世界的未來競爭焦點。

開發者朋友們，你們的選擇會塑造數據庫世界的未來。希望我的這些工作，可以幫助你們更好的用好這世界上最先進的開源數據庫內核 —— PostgreSQL。