PostgreSQL 擁有極為強(qiáng)大的擴(kuò)展插件體系。 在 《》中， 老馮已經(jīng)闡述過 可擴(kuò)展性 是 PostgreSQL 成功的核心要素。

PG 有 GIS 領(lǐng)域的事實標(biāo)準(zhǔn) PostGIS，向量數(shù)據(jù)庫的瑞士軍刀 pgvector，還有可以替代 ElasticSearch 的 pg_search，以及使用 DuckDB 在 PG 內(nèi)進(jìn)行分析的 pg_duckdb / pg_mooncake 等等。 這些擴(kuò)展為 PostgreSQL 賦予了超乎想象的能力。只有加裝了這些擴(kuò)展，PG 才能稱得上是 “全盛完全體”。

然而，要在生產(chǎn)環(huán)境中可靠地編譯、安裝這些擴(kuò)展插件并非易事，會有許許多的挑戰(zhàn)。 許多擴(kuò)展僅僅提供源代碼，需要自己去摸索編譯。對于嚴(yán)肅的生產(chǎn)環(huán)境來說，源碼編譯和 往往也不是一個可行選項 —— 當(dāng)你需要組合使用多個不同擴(kuò)展，在不同服務(wù)器上精確安裝相同版本，或者根本不想使用容器時，問題就會出現(xiàn)。還有一些非技術(shù)的挑戰(zhàn)需要克服 —— ，以及國內(nèi)網(wǎng)絡(luò)環(huán)境受限導(dǎo)致無法下載。

不過，這些問題都被老馮一一攻克了！經(jīng)過最近兩三年無數(shù)日夜的努力，我很自豪地向大家介紹 PGEXT.CLOUD —— PG擴(kuò)展云，一次性， 一條龍，一步到位解決用戶安裝擴(kuò)展，開發(fā)者分發(fā)擴(kuò)展，廠商交付擴(kuò)展的難題。

PGEXT.CLOUD

PG 擴(kuò)展云（PGEXT.CLOUD）提供了以下三樣基礎(chǔ)設(shè)施，幫助用戶更好的利用 PostgreSQL 擴(kuò)展生態(tài)系統(tǒng)的協(xié)同超能力：

這幾條看似簡單的命令背后，其實隱藏了巨大的復(fù)雜度與工作量。 支持 14 個 Linux 發(fā)行版、6 個 PG 主版本、431 個擴(kuò)展插件所產(chǎn)生的排列組合，是一個近乎天文數(shù)字的挑戰(zhàn)。

而在實現(xiàn)“絲滑”安裝交付的過程中，還伴隨著各種棘手問題 —— 龐大的數(shù)量，駁雜的質(zhì)量，分發(fā)的限制，心智的負(fù)擔(dān)。 好在這些挑戰(zhàn)現(xiàn)在都有了一個不錯的答案。

無可比擬的數(shù)量

PostgreSQL 生態(tài)中擁有數(shù)量龐大的擴(kuò)展，總數(shù)可能超過 1000 個。然而在官方 PGDG 倉庫中，目前只提供了其中約 135 個擴(kuò)展。 誠然，一些耳熟能詳?shù)牟寮ㄈ?PostGIS、pgvector 等）包含在官方倉庫里，但還有許多強(qiáng)大的擴(kuò)展并未被收錄 —— 例如近期炙手可熱的 DuckDB-PG 融合擴(kuò)展 pg_duckdb 和 pg_mooncake。老牌的 Plv8，還有 Supabase 自建所需的一系列 Rust 擴(kuò)展。

官方倉庫不收錄這些擴(kuò)展有許許多多的原因 —— 比如 YUM 倉庫的維護(hù)者 Devrim 就表示，絕對不會讓 Rust 寫的 PG 擴(kuò)展進(jìn)入倉庫中。 而像 plv8，pg_duckdb 這樣一編譯一個小時的擴(kuò)展巨無霸，毫無疑問也會顯著拉高倉庫維護(hù)的成本，所以老馮也完全能理解。

老馮曾經(jīng)寄希望于 Tembo 的包管理器 trunk，或者 pgxman 之類的東西可以解決這些問題，不過似乎最后還是不自己動手上。 （比如 tembo 就已經(jīng)跑路去干 AI DBA 去了）。而這一干就一發(fā)不可收拾，一下子就干成了 PG 生態(tài)里最大的擴(kuò)展目錄與倉庫。

簡單來說，這個擴(kuò)展目錄目前收錄了 431 個擴(kuò)展，拋開 PG 自帶的 71 個擴(kuò)展總共 360 個。 PGDG 官方倉庫維護(hù)了 144 個 EL 擴(kuò)展和 105 個 Debian 擴(kuò)展，而老馮的 PGSTY 維護(hù)了 260 個 EL 擴(kuò)展與 241 個 Debian 擴(kuò)展， 占到了總數(shù)的 72% 左右，哈哈，這可真是以一己之力撐起了大半邊天。

良莠不齊的質(zhì)量

當(dāng)然，光有數(shù)量是不行的，更重要的是質(zhì)量。PGDG 的 YUM 倉庫有許許多多的 “坑”： 某個發(fā)行版和 PG 的組合可能漏掉了，不同 PG 大版本的擴(kuò)展版本不一致，老馮在這里可沒有少給 PGDG 倉庫擦屁股。

更大的問題在于部分?jǐn)U展缺乏及時維護(hù)。當(dāng) PostgreSQL 推出 16、17、18 等新版本時，一些擴(kuò)展因為無人更新而無法兼容新版本，甚至直接導(dǎo)致崩潰。 這兩年來，老馮修復(fù)了近百個“趴窩”的擴(kuò)展。例如，最近幾乎所有重要的 Rust PG 擴(kuò)展，在老馮的推動下都已升級到最新的 pgrx 0.16.1 框架，并支持 PG 18。

可以說，目前目錄里的這些擴(kuò)展，即使原作者棄坑不干了，老馮也有信心接手維護(hù)，持續(xù)為新版本保駕護(hù)航。 當(dāng)然，確實有極個別規(guī)模太大，難以搶救且作者失聯(lián)的擴(kuò)展，老馮也只能無奈攤手（age，hydra）。

總的來說， 目前在目錄里面的擴(kuò)展，即使原作者棄坑不干了，老馮也能接手，持續(xù)將它們維護(hù)下去。當(dāng)然也有極個別的頑固擴(kuò)展實在搞不定，作者也失聯(lián)的，老馮也就只能將它標(biāo)記為棄用了。

也許你會好奇，老馮一個人是怎么維護(hù)這么多擴(kuò)展的？說起來，這還真是多虧了 Claude Code。 Opus 4.1 干這個可真是一把好手，通常我只要念出正確的咒語，然后 Review 一下，大部分情況下問題就迎刃而解了，哈哈！

如何分發(fā)擴(kuò)展

光解決擴(kuò)展的編譯打包還不夠，如何高效地將擴(kuò)展分發(fā)到用戶手中，同樣面臨諸多挑戰(zhàn)。 首先需要維護(hù)一個 APT 倉庫和一個 YUM 倉庫，確保不同系統(tǒng)的用戶都能方便獲取軟件包。 PGEXT.CLOUD 默認(rèn)通過 Cloudflare 提供全球 CDN 加速，但 Cloudflare 在中國大陸訪問緩慢，因此我們專門搭建了位于國內(nèi)的鏡像站來提供高速下載。

雖然，，但建立自有倉庫鏡像并不是最棘手的問題。 更大的難題在于：除了 Pigsty 自己的擴(kuò)展倉庫鏡像，俺還需要維護(hù) PostgreSQL 官方 PGDG 倉庫的國內(nèi)鏡像！

在我之前的文章 和 中， 我曾提到：PostgreSQL 官方 PGDG 倉庫自今年5月起停止了 ftp/rsync 同步通道，這導(dǎo)致全球范圍內(nèi)的大部分鏡像站從那時起就不再更新了。

對于海外用戶來說影響尚不明顯，但對于中國大陸用戶而言，這意味著如果不翻墻就無法獲取 PG 的最新軟件包。 大家常用的阿里云、清華 TUNA 鏡像源目前都停留在 2025-03-31 的版本，倉庫連今年 9 月發(fā)布的 PG 18 都影子無蹤。

目前，能持續(xù)更新 PGDG 倉庫鏡像的我所知道也就只有老馮維護(hù)的 Pigsty、俄羅斯的 Yandex，以及歐洲 Xtom。 我每周都會手動同步上游 PGDG 倉庫，確保國內(nèi)用戶也能拿到最新的更新。 順帶一提，老馮還在 PGDG 鏡像里幫 PGDG YUM 倉庫修復(fù)了一些陳年舊 bug（比如 patroni 3.0.4 這個釘子戶版本）。

總而言之，如今只要你使用主流 Linux 發(fā)行版，無論身在國內(nèi)還是海外，都可以通過 PGEXT.CLOUD 享受絲滑順暢的 PostgreSQL 及其擴(kuò)展安裝體驗，再也不用為網(wǎng)絡(luò)和環(huán)境問題操心。

PG擴(kuò)展維基百科

擴(kuò)展插件如此眾多，對于普通用戶來說，安裝使用時難免會被各種配置、源站、鏡像等細(xì)節(jié)搞得頭大。 許多初學(xué)者只是想用上 PostgreSQL 及其擴(kuò)展，這些繁瑣細(xì)節(jié)實在沒必要成為絆腳石。 這正是老馮在倉庫之外，又額外提供 擴(kuò)展目錄 和 包管理器工具 兩項服務(wù)的原因。

PGEXT.CLOUD 的擴(kuò)展目錄（即通過 https://pgext.cloud[1] 訪問的網(wǎng)頁），匯集了前述 431 個擴(kuò)展的詳細(xì)信息。 我們?yōu)槊總€擴(kuò)展整理了元數(shù)據(jù)、在各操作系統(tǒng)和 PG 版本上的可用性矩陣，以及完整的安裝、配置與加載使用說明。

我們還按功能、許可證、開發(fā)語言等多個維度對擴(kuò)展進(jìn)行分類索引。一些重要擴(kuò)展甚至配有專門的說明章節(jié)和教程。PGEXT.CLOUD 的目標(biāo)很明確 —— 打造 PostgreSQL 擴(kuò)展界的維基百科，讓用戶對可用的擴(kuò)展“一覽無余”，也為開發(fā)者提供展示自己作品的平臺。

簡單易用命令行

當(dāng)然，更令人興奮的是，我們還提供了簡單易用的命令行工具 pig。這個用 Go 語言編寫的小巧工具（僅 4 MB），將 PostgreSQL 的安裝和擴(kuò)展交付過程簡化到了極致。

例如，只需下面三行命令，就可以分別完成下載 pig、配置倉庫以及安裝 PG 內(nèi)核和擴(kuò)展插件：

curl -fsSL https://repo.pigsty.io/pig | bash
pig repo set
pig install -y -v 18 pgsql postgis pg_duckdb 

無論您使用的是哪種 Linux 發(fā)行版，配置了什么軟件源，所處地域網(wǎng)絡(luò)如何，使用 dnf/yum 還是 apt，這個工具都能替您處理好所有細(xì)節(jié)。

值得一提的是，pig 并非另起爐灶造輪子，而是對現(xiàn)有 Linux 包管理器的“一層薄皮封裝”（PiggyBack）。 換言之，您依然可以使用經(jīng)典的 apt/yum 來直接訪問 PGEXT.CLOUD 的軟件倉庫 —— pig 只是讓這一切變得更簡單，但并不是不可替代的強(qiáng)制依賴，更不會引入任何供應(yīng)商鎖定。

它不關(guān)心你運(yùn)行在什么 Linux 上，配置了什么倉庫，在什么區(qū)域，用的是 dnf ，yum，還是 apt，它可以幫助你處理好所有細(xì)節(jié)。

最重要的是，這個 pig 包管理器并非是什么新發(fā)明的土鱉輪子，而是 PiggyBack （依托）于現(xiàn)有 Linux 包管理器的上層抽象。 這意味著你還是可以直接用經(jīng)典的 apt / yum 方式直接訪問倉庫 —— pig 并非必須，不會引入任何供應(yīng)商鎖定。

開源、供應(yīng)鏈與信任

此前有些國外用戶對老馮表示過顧慮：“你是中國人，你搞的這個倉庫看上去很好，但我們怎么知道沒被你偷偷做手腳呢？” 面對這樣的質(zhì)疑，老馮也被噎過。說到底，這是典型的軟件供應(yīng)鏈信任問題。坦白講，沒有絕對的解決辦法。 即便是 PGDG 官方倉庫，比如其 YUM 倉庫，也是憑借維護(hù)者 Devrim 的個人聲譽(yù)來背書運(yùn)轉(zhuǎn)的。

老馮的回答是，構(gòu)建這些二進(jìn)制產(chǎn)物的所有工具，規(guī)范，文檔，細(xì)節(jié)都是開源的，你自己也可以在本地輕松的自己構(gòu)建出這些擴(kuò)展來。 這樣如果你不放心，完全可以用同樣的工具箱在離線情況下直接構(gòu)建自己的 RPM/DEB 倉庫。

例如，你只需要使用下面這個簡單的 Dockerfile，就可以立刻拉起標(biāo)準(zhǔn)構(gòu)建環(huán)境，然后當(dāng)你想要構(gòu)建擴(kuò)展的時候，只需要使用 pig build pkg 命令，就可以了！

是的就是這么簡單，比如你想要編譯 timescaledb，這條命令會自動下載源代碼，安裝依賴，然后生成 deb 和 rpm 包：

目前 PGEXT.CLOUD 收錄的所有擴(kuò)展包，都是通過上述流程構(gòu)建而成 —— 這意味著您也可以在任何支持的平臺上，輕松從源代碼構(gòu)建出同樣的擴(kuò)展包！

目前的進(jìn)展

PGEXT.CLOUD 其實并不算是 “新項目”，這套倉庫基礎(chǔ)設(shè)施已經(jīng)運(yùn)轉(zhuǎn)五年了，包管理器和擴(kuò)展目錄有兩年了。 這個新版本的網(wǎng)站目錄倒確實是最近一個月新搞出來了的。所以從成熟度上來說，是已經(jīng)“久經(jīng)考驗”，沒啥問題的。

目前，這個倉庫完全開源并免費向公眾提供服務(wù)。托賽博佛祖 Cloudflare 慷慨免費套餐的福，最大的流量開銷得以減免； 至于國內(nèi)服務(wù)器托管，每月幾百塊的流量費，這點錢老馮還是掏的起的，哈哈。

老馮承諾會長期維護(hù)這個倉庫。畢竟，這本來就是 Pigsty PostgreSQL 發(fā)行版自身需要的一部分，我也樂于將這份成果回饋社區(qū)。 我注意到，不少用戶乃至業(yè)內(nèi)同行其實只想方便地安裝 PG 和各種擴(kuò)展，所以我選擇將 pig 工具和 PGEXT.CLOUD 倉庫從 Pigsty 項目中抽離出來， 作為以 Apache 2.0 寬松許可證開源的獨立項目服務(wù)大眾。

有人問我，難道擴(kuò)展不是 Pigsty 的一個核心價值點與壁壘嗎？你就這么開源免費給別人白嫖打白工？ 老馮的觀點是 —— 一流的企業(yè)與開發(fā)者，應(yīng)該通過構(gòu)建生態(tài)的方式，這樣所有參與者都能互惠共贏。

這一舉措也已經(jīng)初見成效。例如，業(yè)內(nèi)同行 Omnigres 和 Autobase 在他們的 PostgreSQL 發(fā)行版中引入了這個擴(kuò)展倉庫，不費吹灰之力就讓他們的發(fā)行版與用戶獲得了 431 個 PG 擴(kuò)展的強(qiáng)大能力。 再比如，一些擴(kuò)展開發(fā)廠商（ParadeDB、TensorChord、MooncakeLab 等）也能夠借助 Pigsty 倉庫，輕松將自己的擴(kuò)展作品分發(fā)給全球用戶。

不僅如此，我們的倉庫還收錄并分發(fā)了多款不同風(fēng)味的 PostgreSQL 內(nèi)核分支[2] —— 從瀚高的 IvorySQL、阿里云的 PolarDB、Supabase 的 OrioleDB、Percona 的 TDE 內(nèi)核， 到晨章科技的 openGauss（openHalo）等，都可以通過這個倉庫一鍵安裝啟用。 可以說，PGEXT.CLOUD 不僅服務(wù)于擴(kuò)展作者和使用者，同樣助力各路 PG 廠商為用戶創(chuàng)造價值。

放眼未來

目前在 PostgreSQL 擴(kuò)展這條賽道上，除了老馮的 pig 項目可謂高歌猛進(jìn)之外， 其他方案似乎反響平平：原本聲勢浩大的 Tembo Cloud 也跑去湊 AI 的熱鬧，棄坑不干，還坑了 PGXN 作者 David 一把； pgxman、pgxn 等也都一直不溫不火，沒有什么進(jìn)展。

真正還能在容器化場景下提供擴(kuò)展分發(fā)能力、與我們一較高下的，大概只有歐盟 StackGres（Alvaro 提供的 Kubernetes 方案）。 不過 StackGres 走的是 Cloud-Native 路線，而老馮專注的是 Linux-Native，本就是井水不犯河水，各取所需。

順帶一提，Pigsty 和 StackGres 還是 Supabase 官方唯二兩個支持三方開源自建 Supabase 的發(fā)行版，也是一個 K8S， 一個 Linux。 就是因為也只有我們兩家把 Supabase 的核心 —— 擴(kuò)展問題給解決好了。

PostgreSQL 的成功離不開其極致的可擴(kuò)展性和繁榮的擴(kuò)展生態(tài)。 老馮真心希望通過 PGEXT.CLOUD 為這個生態(tài)添磚加瓦，樹立起擴(kuò)展分發(fā)的事實標(biāo)準(zhǔn)，讓擴(kuò)展作者、用戶以及 PG 廠商都能享受到更多增值紅利，擁有更卓越的使用體驗。

作為一個完全開源的項目，PGEXT.CLOUD 熱忱歡迎來自各方的貢獻(xiàn)！如果您發(fā)現(xiàn)還有哪些擴(kuò)展遺漏未收錄， 或者在使用過程中遇到任何問題，歡迎隨時提出 Issue。作為擴(kuò)展作者，如果您因缺少跨平臺打包分發(fā)能力而煩惱，老馮也很樂意幫您解決這些難題； 作為 PG 產(chǎn)品廠商，我們更鼓勵您直接采用 PGEXT.CLOUD 的倉庫與工具，將 PostgreSQL 豐富的擴(kuò)展生態(tài)無縫交付給用戶。

寫到這里，不禁有些感慨——從個人興趣的小項目，到如今服務(wù)全球 PG 社區(qū)的一項基礎(chǔ)設(shè)施，PGEXT.CLOUD 的成長離不開每一位開源同行的支持。 未來，老馮將繼續(xù)保持初心，與大家攜手推動 PostgreSQL 生態(tài)更上一層樓！讓我們共同解鎖 PG 生態(tài)的全部潛力，暢想更加精彩的數(shù)據(jù)庫未來！

專欄：數(shù)據(jù)庫老司機(jī)