PG擴展云，免翻免費解鎖PG完全體

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

PG 有 GIS 領域的事實標準 PostGIS，向量數據庫的瑞士軍刀 pgvector，還有可以替代 ElasticSearch 的 pg_search，以及使用 DuckDB 在 PG 內進行分析的 pg_duckdb / pg_mooncake 等等。 這些擴展為 PostgreSQL 賦予了超乎想象的能力。只有加裝了這些擴展，PG 才能稱得上是 “全盛完全體”。

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

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

PGEXT.CLOUD

PG 擴展云（PGEXT.CLOUD）提供了以下三樣基礎設施，幫助用戶更好的利用 PostgreSQL 擴展生態系統的協同超能力：

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

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

無可比擬的數量

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

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

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

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

良莠不齊的質量

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

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

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

總的來說， 目前在目錄里面的擴展，即使原作者棄坑不干了，老馮也能接手，持續將它們維護下去。當然也有極個別的頑固擴展實在搞不定，作者也失聯的，老馮也就只能將它標記為棄用了。

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

如何分發擴展

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

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

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

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

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

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

PG擴展維基百科

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

PGEXT.CLOUD 的擴展目錄（即通過 https://pgext.cloud[1] 訪問的網頁），匯集了前述 431 個擴展的詳細信息。 我們為每個擴展整理了元數據、在各操作系統和 PG 版本上的可用性矩陣，以及完整的安裝、配置與加載使用說明。

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

簡單易用命令行

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

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

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

無論您使用的是哪種 Linux 發行版，配置了什么軟件源，所處地域網絡如何，使用 dnf/yum 還是 apt，這個工具都能替您處理好所有細節。

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

它不關心你運行在什么 Linux 上，配置了什么倉庫，在什么區域，用的是 dnf ，yum，還是 apt，它可以幫助你處理好所有細節。

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

開源、供應鏈與信任

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

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

例如，你只需要使用下面這個簡單的 Dockerfile，就可以立刻拉起標準構建環境，然后當你想要構建擴展的時候，只需要使用 pig build pkg 命令，就可以了！

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

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

目前的進展

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

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

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

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

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

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

放眼未來

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

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

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

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

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

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

專欄：數據庫老司機