PostgreSQL 并不是一個(gè)簡(jiǎn)單的關(guān)系型數(shù)據(jù)庫，而是一個(gè)數(shù)據(jù)管理的抽象框架，具有吞噬整個(gè)數(shù)據(jù)庫世界的力量。而這也是正在發(fā)生的事情 —— “一切皆用 Postgres” 已經(jīng)不再是少數(shù)精英團(tuán)隊(duì)的前沿探索，而是成為了一種進(jìn)入主流視野的最佳實(shí)踐。

OLAP 領(lǐng)域迎來踢館者

在 2016 年的一次數(shù)據(jù)庫沙龍里，我提出了一個(gè)觀點(diǎn)： 現(xiàn)在 PostgreSQL 生態(tài)的一個(gè)主要遺憾是，缺少一個(gè)足夠好的列式存儲(chǔ)分析插件來做 OLAP 分析。盡管PostgreSQL 本身提供了很強(qiáng)大的分析功能集，應(yīng)付常規(guī)的分析任務(wù)綽綽有余。但在較大數(shù)據(jù)量下全量分析的性能，相比專用的實(shí)時(shí)數(shù)倉仍然有些不夠看。

以分析領(lǐng)域的權(quán)威評(píng)測(cè) Clickbench 為例，我們?cè)谄渲袠?biāo)注出了 PostgreSQL 與生態(tài)擴(kuò)展插件以及兼容衍生數(shù)據(jù)庫在其中的性能表現(xiàn)。原生未經(jīng)過調(diào)優(yōu)的 PostgreSQL 表現(xiàn)較為拉垮（x1050），但經(jīng)過調(diào)優(yōu)后可以達(dá)到（x47）；此外還有三個(gè)與分析有關(guān)系的擴(kuò)展：列存 Hydra（x42），時(shí)序擴(kuò)展 TimescaleDB（x103），以及分布式擴(kuò)展 Citus（x262）。

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

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

ParadeDB 與 DuckDB 的出現(xiàn)讓 PostgreSQL 的分析性能來到了 OLAP 的第一梯隊(duì)與金字塔尖，彌補(bǔ)了 PostgreSQL 在 OLAP 性能這最后一塊關(guān)鍵短板。

分久必合的數(shù)據(jù)庫領(lǐng)域

數(shù)據(jù)庫誕生伊始，并沒有 OLTP 與 OLAP 的分野。OLAP 數(shù)據(jù)倉庫從數(shù)據(jù)庫中“獨(dú)立”出來，已經(jīng)是上世紀(jì)九十年代時(shí)候的事了 —— 因?yàn)閭鹘y(tǒng)的 OLTP 數(shù)據(jù)庫難以支撐起分析場(chǎng)景下的查詢模式，數(shù)據(jù)量與性能要求。

在相當(dāng)一段時(shí)間里，數(shù)據(jù)處理的最佳實(shí)踐是使用 MySQL / PG 處理 OLTP 工作負(fù)載，并通過 ETL 將數(shù)據(jù)同步到專用的 OLAP 組件中去處理，比如 Greenplum, ClickHouse, Doris, Snowflake 等等。

與許多 “專用數(shù)據(jù)庫” 一樣，專業(yè)的 OLAP 組件的優(yōu)勢(shì)往往在于性能 —— 相比原生 PG 、MySQL 上有 1～3 個(gè)數(shù)量級(jí)的提升；而代價(jià)則是數(shù)據(jù)冗余、 大量不必要的數(shù)據(jù)搬運(yùn)工作、分布式組件之間缺乏一致性、額外的專業(yè)技能帶來的復(fù)雜度成本、學(xué)習(xí)成本、以及人力成本、 額外的軟件許可費(fèi)用、極其有限的查詢語言能力、可編程性、可擴(kuò)展性、有限的工具鏈、以及與OLTP 數(shù)據(jù)庫相比更差的數(shù)據(jù)完整性和可用性 —— 但這是一個(gè)合理的利弊權(quán)衡。

然而天下大勢(shì)，分久必合，合久必分。硬件遵循摩爾定律又發(fā)展了三十年，性能翻了幾個(gè)數(shù)量級(jí)，成本下降了幾個(gè)數(shù)量級(jí)。在 2024 年的當(dāng)下，x86 單機(jī)可以達(dá)到 512 核幾個(gè)TB的內(nèi)存，單卡 NVMe SSD 可達(dá) 64TB，全閃單機(jī)柜 2PB ；S3 這樣對(duì)象存儲(chǔ)更是能實(shí)現(xiàn)幾乎沒有上限的存儲(chǔ)。

硬件的發(fā)展解決了數(shù)據(jù)量的問題，而數(shù)據(jù)庫軟件的發(fā)展（PostgreSQL，ParadeDB，DuckDB）解決了查詢模式的問題，而這導(dǎo)致分析領(lǐng)域 —— 所謂的“大數(shù)據(jù)” 行業(yè)基本工作假設(shè)面臨挑戰(zhàn)。

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

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

基本工作假設(shè)的變化，將重新推動(dòng)數(shù)據(jù)庫世界從百花齊放的“合久必分”階段，走向“分久必合”的階段，從大爆發(fā)到大滅絕，大浪淘沙中，新的大一統(tǒng)超融合數(shù)據(jù)庫將會(huì)出現(xiàn)，重新統(tǒng)一 OLTP 與 OLAP。而承擔(dān)重新整合數(shù)據(jù)庫領(lǐng)域這一使命的會(huì)是誰？

吞食天地的 PostgreSQL

數(shù)據(jù)庫領(lǐng)域有許多“細(xì)分領(lǐng)域”：時(shí)序數(shù)據(jù)庫，地理空間數(shù)據(jù)庫，文檔數(shù)據(jù)庫，搜索數(shù)據(jù)庫，圖數(shù)據(jù)庫，向量數(shù)據(jù)庫，消息隊(duì)列，對(duì)象數(shù)據(jù)庫。而 PostgreSQL 在任何一個(gè)領(lǐng)域都不會(huì)缺席。

一個(gè) PostGIS 插件，成為了地理空間事實(shí)標(biāo)準(zhǔn)；一個(gè) TimescaleDB 擴(kuò)展，讓一堆“通用”時(shí)序數(shù)據(jù)庫尷尬的說不出話來；一個(gè)向量擴(kuò)展 PGVector 插件，更是讓整個(gè)專用向量數(shù)據(jù)庫細(xì)分領(lǐng)域 變成笑話。

同樣的事情已經(jīng)發(fā)生過很多次，而現(xiàn)在，我們將在拆分最早，地盤最大的一個(gè)子領(lǐng)域 OLAP 分析中再次見證這一點(diǎn)。但 PostgreSQL 要替代的可不僅僅是 OLAP 數(shù)倉，它的野望是整個(gè)數(shù)據(jù)庫世界！

用戶選擇 PostgreSQL 的原因：開源，先進(jìn)，擴(kuò)展。

為什么？因?yàn)?PGVECTOR 作者不需要操心數(shù)據(jù)庫的通用額外復(fù)雜度：事務(wù) ACID，故障恢復(fù)，備份PITR，高可用，訪問控制，監(jiān)控，部署，三方生態(tài)工具，客戶端驅(qū)動(dòng)這些需要成百上千萬行代碼才能解決好的問題，只需要關(guān)注自己所需問題的本質(zhì)復(fù)雜度即可。

向量數(shù)據(jù)庫哪家強(qiáng)？

再比如，ElasticSearch 基于 Lucene 搜索庫開發(fā)，而 Rust 生態(tài)有一個(gè)改進(jìn)版的下一代 Tantivy 全文搜索庫作為 Lucene 的替代；而 ParadeDB 只需要將其封裝對(duì)接到 PostgreSQL 的接口上，即可提供比肩 ElasticSearch 的搜索服務(wù)。更重要的是，它可以站在 PostgreSQL 巨人的肩膀上，借用 PG 生態(tài)的全部合力（例如，與 PG Vector 做混合檢索），不講武德地用數(shù)據(jù)庫全能王的力量，去與一個(gè)專用數(shù)據(jù)庫單品來對(duì)比。

可擴(kuò)展性帶來的另一點(diǎn)巨大優(yōu)勢(shì)是擴(kuò)展的可組合性，讓不同擴(kuò)展相互合作，產(chǎn)生出 1+1 >> 2 的協(xié)同效應(yīng)。例如，TimescaleDB 可以與 PostGIS 組合使用，提供時(shí)空數(shù)據(jù)支持；再比如，提供全文檢索能力的 BM25 擴(kuò)展可以和提供語義模糊檢索的 PGVector 擴(kuò)展組合使用，提供混合檢索能力。

再比如，分布式擴(kuò)展 Citus 可以將單機(jī)主從數(shù)據(jù)庫集群，原地升級(jí)改造為透明水平分片的分布式數(shù)據(jù)庫集群。而這個(gè)能力是可以與其他功能正交組合的，因此，PostGIS 可以成為分布式地理數(shù)據(jù)庫，PGVector 可以成為分布式向量數(shù)據(jù)庫，ParadeDB 可以成為分布式全文搜索數(shù)據(jù)庫，諸如此類。

更強(qiáng)大的地方在于，擴(kuò)展插件是獨(dú)立演進(jìn)的，不需要繁瑣的主干合并，聯(lián)調(diào)協(xié)作。因此可以 Scale  —— PG 的可擴(kuò)展性允許無數(shù)個(gè)團(tuán)隊(duì)并行探索數(shù)據(jù)庫前研發(fā)展方向，而擴(kuò)展全部都是的可選的，不會(huì)影響主干核心能力的穩(wěn)定性。那些非常強(qiáng)大成熟的特性，則有機(jī)會(huì)以穩(wěn)定的形態(tài)進(jìn)入主干中。

通過極致可擴(kuò)展性的魔法，PostgreSQL 做到了守正出奇，實(shí)現(xiàn)了主干極致穩(wěn)定性與功能敏捷性的統(tǒng)一。扎實(shí)的基本盤配上驚人的演進(jìn)速度，讓它成為了數(shù)據(jù)庫世界中的一個(gè)異數(shù)，改變了數(shù)據(jù)庫世界的游戲規(guī)則。

改變游戲規(guī)則的玩家

PostgreSQL 的出現(xiàn)，改變了數(shù)據(jù)庫領(lǐng)域的游戲規(guī)則：任何試圖開發(fā)“新數(shù)據(jù)庫內(nèi)核”的團(tuán)隊(duì)，都需要經(jīng)過這道試煉與考驗(yàn) —— 相比開源免費(fèi)、功能齊備的 Postgres，價(jià)值點(diǎn)在哪里？

至少到硬件出現(xiàn)革命性突破前，實(shí)用的通用數(shù)據(jù)庫新內(nèi)核都不太可能誕生了，因?yàn)槿魏螁我粩?shù)據(jù)庫都無法與所有擴(kuò)展加持下的 PG 在整體實(shí)力上相抗衡 —— 包括 Oracle，因?yàn)?PG 還有開源免費(fèi)的必殺技。

而某個(gè)細(xì)分領(lǐng)域的數(shù)據(jù)庫產(chǎn)品，如果能在單點(diǎn)屬性（通常是性能）上相比 PostgreSQL 實(shí)現(xiàn)超過一個(gè)數(shù)量級(jí)的優(yōu)勢(shì)，那也許還有一個(gè)專用數(shù)據(jù)庫的生態(tài)位存在。但通常用不了多久，便會(huì)有 PostgreSQL 生態(tài)的開源替代擴(kuò)展插件滾滾而來。因?yàn)檫x擇開發(fā) PG 擴(kuò)展，而不是一個(gè)完整數(shù)據(jù)庫的團(tuán)隊(duì)會(huì)在追趕復(fù)刻速度上有碾壓性優(yōu)勢(shì)！

因此，如果按照這樣的邏輯展開，PostgreSQL 生態(tài)的雪球只會(huì)越滾越大，隨著優(yōu)勢(shì)的積累，不可避免地進(jìn)入一家獨(dú)大的狀態(tài)。在幾年的時(shí)間內(nèi)，實(shí)現(xiàn) Linux 內(nèi)核在服務(wù)器操作系統(tǒng)領(lǐng)域的狀態(tài)。而各種開發(fā)者調(diào)研報(bào)告，數(shù)據(jù)庫流行趨勢(shì)都在印證著這一點(diǎn)。

StackOverflow 2023 調(diào)研結(jié)果，PostgreSQL 三項(xiàng)全能王

StackOverflow過去7年的數(shù)據(jù)庫指標(biāo)走勢(shì)

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

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

還有什么可以做的？

我們已經(jīng)不難預(yù)見到數(shù)據(jù)庫領(lǐng)域的終局。但我們又能做什么，又應(yīng)該做什么呢？

PostgreSQL 對(duì)于絕大多數(shù)場(chǎng)景都已經(jīng)是一個(gè)足夠完美的數(shù)據(jù)庫內(nèi)核了，在這個(gè)前提下，數(shù)據(jù)庫內(nèi)核卡脖子純屬無稽之談。這些Fork PostgreSQL 和 MySQL 并以內(nèi)核魔改作為賣點(diǎn)的所謂“數(shù)據(jù)庫”基本沒啥出息。

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

同理，數(shù)據(jù)庫內(nèi)核本身已經(jīng)不再是主要矛盾，焦點(diǎn)將會(huì)集中到兩個(gè)方向上 —— 數(shù)據(jù)庫擴(kuò)展與數(shù)據(jù)庫服務(wù)！前者體現(xiàn)為數(shù)據(jù)庫內(nèi)部的可擴(kuò)展性， 后者體現(xiàn)為數(shù)據(jù)庫外部的可組合性。而競(jìng)爭(zhēng)的形式，正如操作系統(tǒng)生態(tài)一樣 —— 集中于數(shù)據(jù)庫發(fā)行版上。對(duì)于數(shù)據(jù)庫領(lǐng)域來說，只有那些以擴(kuò)展和服務(wù)作為核心價(jià)值主張的發(fā)行版，才有最終成功的可能。

做內(nèi)核的廠商不溫不火，MariaDB 作為 MySQL 的親爹 Fork 甚至都已經(jīng)瀕臨退市，而白嫖內(nèi)核自己做服務(wù)與擴(kuò)展賣 RDS 的 AWS 可以賺的缽滿盆翻。投資機(jī)構(gòu)已經(jīng)出手了許多 PG 生態(tài)的擴(kuò)展插件與服務(wù)發(fā)行版：Citus，TimescaleDB，Hydra，PostgresML，ParadeDB，F(xiàn)erretDB，StackGres，Aiven，Neon，Supabase，Tembo，PostgresAI，以及我們正在做的 Pigsty 。

PostgreSQL 生態(tài)中的一個(gè)困境就是，許多擴(kuò)展插件，生態(tài)工具都是獨(dú)立演進(jìn)，各自為戰(zhàn)的，沒有一個(gè)整合者能將他們凝聚起來形成合力。例如，提供分析的 Hydra 會(huì)打一個(gè)包一個(gè) Docker 鏡像， PostgresML 也會(huì)打自己的包和鏡像，各家只發(fā)行加裝了自己擴(kuò)展的 Postgres 鏡像。而這些樸素的鏡像與包也距離 RDS 這樣完整的數(shù)據(jù)庫服務(wù)相距甚遠(yuǎn)。

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

許多關(guān)鍵擴(kuò)展在RDS中并不可用

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

知行合一的實(shí)踐：Pigsty

雖然接觸 MySQL 和 MSSQL 要早得多，但我在 2015 年第一次上手 PostgreSQL 時(shí)，就相信它會(huì)是數(shù)據(jù)庫領(lǐng)域的未來了?？焓赀^去，我也從 PG 的使用者，管理者，變?yōu)榱素暙I(xiàn)者，開發(fā)者。也不斷見證著 PG 走向這一目標(biāo)。

在與形形色色的用戶溝通交流中，我早已發(fā)現(xiàn)數(shù)據(jù)庫領(lǐng)域的木桶短板不是內(nèi)核 —— 現(xiàn)有的 PostgreSQL 已經(jīng)足夠好了，而是用好數(shù)據(jù)庫內(nèi)核本身的能力，這也是 RDS 這樣的服務(wù)賺的缽滿盆翻的原因。

但我希望這樣的能力，應(yīng)該像自由軟件運(yùn)動(dòng)所倡導(dǎo)的理念那樣，像 PostgreSQL 內(nèi)核本身一樣 —— 普及到每一個(gè)用戶手中，而不是必須向賽博空間上的封建云領(lǐng)主花大價(jià)錢租賃。

所以我打造了 Pigsty —— 一個(gè)開箱即用的開源 PostgreSQL 數(shù)據(jù)庫發(fā)行版，旨在凝聚 PostgreSQL 生態(tài)擴(kuò)展的合力，并把提供優(yōu)質(zhì)數(shù)據(jù)庫服務(wù)的能力普及到每個(gè)用戶手中。

Pigsty 是 PostgreSQL in Great STYle 的縮寫，意為 PostgreSQL 的全盛狀態(tài)。

我們提出了六點(diǎn)核心價(jià)值主張，對(duì)應(yīng) PostgreSQL 數(shù)據(jù)庫服務(wù)中的的六個(gè)核心問題：Postgres 的可擴(kuò)展性，基礎(chǔ)設(shè)施的可靠性，圖形化的可觀測(cè)性，服務(wù)的可用性，工具的可維護(hù)性，以及擴(kuò)展模塊和三方組件可組合性。

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

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

屬于你的圖形化 Postgres 基礎(chǔ)設(shè)施服務(wù)工具箱。

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

來自 ParadeDB 創(chuàng)始人與 DuckdbFDW 作者的感謝致意

我們希望整合 PostgreSQL 生態(tài)里的各種力量，并將其凝聚在一起形成合力，打造一個(gè)數(shù)據(jù)庫世界中的 Ubuntu 發(fā)行版。而我相信，內(nèi)核之爭(zhēng)早已塵埃落定，而這里才會(huì)是數(shù)據(jù)庫世界的未來競(jìng)爭(zhēng)焦點(diǎn)。

開發(fā)者朋友們，你們的選擇會(huì)塑造數(shù)據(jù)庫世界的未來。希望我的這些工作，可以幫助你們更好的用好這世界上最先進(jìn)的開源數(shù)據(jù)庫內(nèi)核 —— PostgreSQL。