Pigsty 是一個開箱即用、開源且本地優(yōu)先的 PostgreSQL 數(shù)據(jù)庫發(fā)行版，最近發(fā)布的 v4.0 是一個史詩級的大版本，整體有了一個整體的質變與飛躍。

也正好借這個發(fā)布窗口，我把一件惦記很久的事落地了：把 Pigsty 的許可證從 AGPLv3 改回 Apache 2.0。

（我看完確實笑出了聲）。你可以先讀他的版本，再來看我作為作者的第一人稱心路歷程： 為什么改、改了意味著什么，以及我對開源、生態(tài)、服務與商業(yè)化的整體判斷。

前生今世

Pigsty 剛誕生的時候，用的就是 Apache 2.0。

動機很樸素：我做個自己用得爽的作品，順手開源出來讓大家也能用上，順便把業(yè)界使用 PostgreSQL 的姿勢整體往前推一點。既然是這種心態(tài)，選 Apache 很自然：開放、寬松、少糾結。

后來到 2.0 版本，我把許可證改成了 AGPLv3。表面理由是：當時一些知名項目（Grafana / MinIO）從 Apache 轉向了 AGPLv3，Pigsty 也跟著受了傳染。 但老實說，這只是“好解釋”的版本。后來我認真研究過：它們的 AGPL 并不會“傳染”到 Pigsty —— 我既沒有把它們當庫去鏈接，也沒有去修改它們的代碼。

更真實的原因其實是：那時我開始拿投資創(chuàng)業(yè)，要認真對商業(yè)結果負責，自然會考慮商業(yè)利益保護，于是選擇了開源譜系里約束最強的許可證之一：AGPLv3。 同時我們也在許可與聲明中明確表達過：對普通用戶不追索、執(zhí)行效果等同 Apache-2.0；AGPLv3 更像是“為同行/云廠商的極端白嫖場景保留一個選項”。

但實踐證明：這個選項既沒帶來我想要的保護，反而帶來了新的采用阻力。

AGPLv3 的糟糕實踐

AGPL 的第一類問題很直觀：它會在商業(yè)公司內部直接觸發(fā)“法務紅燈”。不少公司對 AGPL 的默認策略就是：先別碰——成本高、風險不清、審批慢。 你解釋“我不追普通用戶”“我實際不傳染”，很多時候也沒用。規(guī)則是規(guī)則，流程是流程。

我就遇到過很典型的對話：某云上數(shù)據(jù)庫團隊的人跟我聊方案，我提議他們在云服務器上直接用 Pigsty 自建，結果對方的反饋很干脆：

去年 PG 大會的時候，我就跟 OxAI 的朋友聊過這個問題。我提議說：“你們在 Azure 上搞這個 PG，不如直接用他們的服務器上用 Pigsty 自建啊。” 他跟我說：“開源的可以考慮一下，但你這個用 AGPLv3 就不行啊”。

這類對話聊多了，你就會意識到：AGPLv3 是在給自己制造采用門檻 —— 不是技術門檻，是流程門檻，而流程門檻通常更難打穿。

第二類問題是：AGPL 也未必真能阻止你想象中的“白嫖”。 我舉個真實出現(xiàn)的交付模式：某云廠商/集成商把算力與資源賣給客戶，客戶在自己的環(huán)境里部署 Pigsty，遇到問題再來找我做付費支持。 對方確實借 Pigsty 完成了交付。但在法律層面，AGPL 對這種“顧問 / 交付 / 私有部署”的模式殺傷力很有限：代碼沒以 SaaS 方式對外提供，不等于就觸發(fā)你腦補的“云白嫖反制”。

于是你會看到一個很尷尬的結果：AGPL 在很多場景里更像是——把認真合規(guī)想用你軟件的人勸退了，卻未必能約束真正想繞過去的人。 更糟的是，它會體現(xiàn)在增長曲線上：當許可切換到 AGPL 后，我能明顯感到采用節(jié)奏變“別扭”了。

第二類問題是：AGPL 可能也并不能真正阻止被 “白嫖”。 我舉個現(xiàn)實例子：OCI 人找我做過咨詢。他們在給客戶交付 PostgreSQL 時，用的是 Pigsty： 客戶買他們的機器（或資源），在上面自己部署 Pigsty，遇到問題再來找我付費解決。 云廠商確實借 Pigsty 完成了交付。但在法律上，AGPL 對這種“顧問/交付/私有部署”的模式其實沒什么殺傷力：代碼沒公開賣 SaaS，不等于就觸發(fā)你想象中的“云白嫖反制”。

AGPL 在很多場景里更像是：把想認真用你軟件的人勸退了，卻未必能起到你想象中的效果。 這個變化更是體現(xiàn)在數(shù)據(jù)層面上：從切到 AGPL 開始，Pigsty 的開源采用增速明顯放緩 —— 以前像指數(shù)曲線那樣飛，現(xiàn)在更像線性爬坡。這種“別扭”的狀態(tài)本身就說明了問題。

幾年前《DDIA》的作者 Martin Kleppmann 也提過類似觀點：GPL/AGPL 并不能很好解決云時代的價值分配問題。 如果你真想限制云廠商，你需要的往往不是開源許可證，而是“源碼可用”體系（ELv2、SSPL、BSL 之類）， 甚至需要的是產品路線本身（比如本地優(yōu)先、可分發(fā)、生態(tài)綁定），而不是寄希望于 GPL 家族在云上替你伸張正義。

所以我后來越想越確定：AGPL 既不夠開源友好，也不夠反云有效。兩頭都不討好。

那為什么不用 ELv2 / SSPL / BSL？

既然 AGPL 不好使，那一個很自然的追問就是：你不是一直喊“下云”嗎？那你直接上 ELv2（Elastic License v2）這種 “對普通用戶幾乎等同 Apache、但明確限制云廠商”的許可證，不就完事了嗎？

說實話，我認真考慮過。尤其是現(xiàn)在這個時間點：Pigsty 趨近“完成軟件”。我并不缺 PR，也不靠開源協(xié)作才能推進功能。 今天的現(xiàn)實是：你給我一個 idea，我用 Claude 之類的工具，能非常快地把它做出來。對我來說，社區(qū)最重要的價值不是代碼貢獻，而是：

?真實場景的反饋與問題暴露?可復用的模板與最佳實踐?案例、口碑、傳播與生態(tài)連接

在這種前提下，“我到底需不需要一個嚴格意義上的 OSI 開源許可證”，這個問題就變得很尖銳。 但我最后還是沒走 ELv2。

原因只有一個核心：那不是我想做的事。

老馮真正想做的，是把 Pigsty 做成“數(shù)據(jù)庫世界的 Debian”。 Debian 不是靠“限制誰不能用”成為 Debian 的。它靠的是：開放、包容、可復用、可分發(fā)， 最后長成了一個生態(tài)位 —— 主流發(fā)行版、上游、標準、基礎設施。

做數(shù)據(jù)庫世界的 Debian

我在公開演講《》里說過： Pigsty 的目標是成為 PostgreSQL 世界里的 Debian —— 一個面向全球、真正好用、可分發(fā)、可復用的主流發(fā)行版。

我判斷：最近這兩年將是數(shù)據(jù)庫世界與軟件形態(tài)劇烈變化的窗口期。 AI、Agent、基礎設施范式遷移，會把 “誰是默認選項” 這件事重新洗牌。

PostgreSQL 已經成為數(shù)據(jù)庫世界的 Linux 內核，而發(fā)行版之爭才剛剛拉開序幕。 這種歷史窗口并不常見。Pigsty 已經拿到了一張參賽門票，我不打算錯過這場大戲。

而要在這個窗口期里抓住機會，成為一個主流數(shù)據(jù)庫發(fā)行版，靠的不是 “許可證當武器”，而是：

?讓用戶用得爽、用得穩(wěn)?讓廠商能集成、能二次分發(fā)?讓 ISV 有錢賺、有路走?讓開發(fā)者/運維/DBA 都能有收益

這套激勵結構要成立，寬松許可證幾乎是必選項。 它代表姿態(tài)，也代表誠意：歡迎使用、歡迎集成、歡迎分發(fā)、歡迎做你自己的版本。

說得更直白一點：歡迎來“白嫖”。

當然邊界要講清楚：拿去賣無所謂，千萬別瞎吹什么 100% 自研國產數(shù)據(jù)庫。

開源何須懼白嫖？

很多人問我：在大家都從開源轉 “源碼可用”、許可證越來越收緊的大背景下，你為什么反而逆勢回到 Apache？你不怕被白嫖嗎？你還怎么賺錢？

我的想法很簡單：如果你害怕被白嫖、又指望靠許可證直接變現(xiàn)，那干脆別開源，賣商業(yè)軟件就好了；如果你選擇了真開源，就要接受它的基本現(xiàn)實：它會被使用、會被集成、會被二次分發(fā)。 應該把這個東西當成一個送給世界的禮物。把開源當成一種娛樂與公益來做 —— 更符合它本來的樣子。就像 Linus 祖師爺自傳說的 —— Just for Fun。

當然，道德層面，我也看不上某些云廠商今天搞個 “ClxxdBot”，明天嫖個 “SxxxBase”， 拿開源項目套殼引流，賣自家服務器和服務，看起來很“聰明”，其實掉價的行為 —— 但 Pigsty 對這一招免疫，它不是云廠商的菜，它就是云數(shù)據(jù)庫飯碗本身。

頭部云廠商本身都有自己的 RDS/PG 服務，深度綁定自家云底座。他們真要把 Pigsty 拿去做成 RDS，反而很別扭 —— 這等于用別人的旗子砸自己的招牌。

老馮雖然倡導 “下云”，但主要針對的是云數(shù)據(jù)庫這樣的 PaaS。你能下到 IDC 自建當然好，但是用云上的服務器自建也不錯； 云 IaaS 除了云盤實在太拉垮，其他東西并沒有什么大問題 —— 也有那種 NVMe 實例存儲的機器，合適就用沒毛病。

所以對于那些沒有成熟托管 PG 服務、但想把“自建 PG 交付”做成能力的廠商與集成方，我的態(tài)度很明確：歡迎。把朋友搞得多多的，比“拿許可證當棍子”更重要。

新定位：從“發(fā)行版”進化成“元發(fā)行版”

使用寬松的許可證，還有一個考慮是 —— Pigsty 的定位已經從 “一個 PG 發(fā)行版”，逐漸變成了一個元發(fā)行版（Meta Distribution）。

Pigsty 在設計之初的理念就是 —— 一切皆可定制。你可以根據(jù)自己的需求，通過簡單的配置，輕松實現(xiàn)各種定制化場景。 Pigsty 可以提供完整的工具箱與基礎設施，以及 PG 生態(tài)最大，最全面的二進制擴展分發(fā)目錄與倉庫。 你可以基于 Pigsty 定制出滿足自己需求的子發(fā)行版，就像 Linux 世界從 Debian/Red Hat 這類主干發(fā)行版，長出無數(shù)定制分支一樣。

我最近做的新項目： PIGLET.RUN（小豬快跑/PIGSTY 輕量 AI 沙箱運行時）就是一個例子， 在 Pigsty 單機模板的基礎上添加了 Vibe Coding 工具箱，讓你在云端一鍵拉起 Claude Code，VS Code 等全家桶服務。這就是一個 PIGSTY 的第一方子發(fā)行版。

你可以把內核換掉，把這個 PG 內核換成你自己的；或者你自己做了一些擴展、開發(fā)了一些軟件，把它們打進去，做成你自己的 PG 發(fā)行版。 老馮覺得對于 PG內核廠商 來說這是個大好事 —— 本來一個光板無毛的 RPM 內核包，現(xiàn)在變成了“高可用、備份恢復、監(jiān)控、IaC、離線交付”全套齊活，交付給客戶價值直接上一個量級。

其實之前在 v3 的時候，我們就提供了使用定制 PG 內核的能力。你可以使用好幾種不同風味的 PostgreSQL 內核一鍵拉起。 其實嚴格來說，這每一個內核的支持都可以作為一個新的子發(fā)行版。Percona TDE，Supabase，OrioleDB，PolarDB，IvorySQL，AlloyDB 等等。

你可以把他們做成 PolarStyle，IvoryStyle，HaloStyle 這樣的發(fā)行版。你甚至可以用 Claude Code 在里面寫個 MySQL 的 Ansible 模塊劇本，做一個 MysqlStyle 的發(fā)行版。

要讓“元發(fā)行版”這件事成立，許可證必須足夠寬松。否則你一邊喊“歡迎分發(fā)”，一邊寫“分發(fā)會觸發(fā)義務”，生態(tài)是長不起來的。 我理想中的終局是：Pigsty 未來形成某種治理結構，甚至像 Debian 那樣出現(xiàn)委員會與共建機制。目標很大，但大才有趣。

關鍵契機：完成的軟件

為什么選在 v4.0 這個時間點切回 Apache？因為 v4.0 這個版本，是一個里程碑式的版本，達到了一個 “完成軟件”（Finished Software） 的狀態(tài)。

如果我以自己能達到的巔峰水準為 100 分基準，那么 Pigsty 本體已經達到了 90 分的水平，作為參照的話，我給 AWS RDS 大概能打個 80 分。

當然這事老馮自己說你們肯定覺得王婆賣瓜。所以我還特意后來我也特意找了 SOTA AI 三件套（GPT、Claude、Gemini）， 要求他們客觀公正地進行分析，不要拍馬屁給我一個評估對比，結果基本也是這樣的（可以自己問問試試）。

https://claude.ai/public/artifacts/9535eaad-817d-4749-91c5-1b21b2534b3e

https://claude.ai/public/artifacts/9535eaad-817d-4749-91c5-1b21b2534b3e

這個評價代表在主流 AI 的認知中，Pigsty 的水平表現(xiàn)，那么問題就來了？ 如果你把一個免費的產品，做到了 90 分的水平，那收費的 80 分服務咋辦。

所以差不多了，再做下去，別說把云數(shù)據(jù)庫和同行都卷死了，自己說不定也卷沒了 —— 畢竟老馮賣的就是把 90 分自助免費服務提升到 100 分的專家咨詢服務呀。

當然，老馮是非常歡迎 ISV 與 DBA 專家個體基于 Pigsty 打造自己的商業(yè)服務的。 這個市場大的很，俺怎么吃的完？你服務你的客戶，我可以提供上游支持 —— 你要能搞定就自己搞，搞不定就找我兜底，這不就是一個健康的生態(tài)分工嗎。

商業(yè)模式：站著掙錢

很多人也好奇：既然開源了，你靠什么掙錢？ 我特別欣賞的一種模式，是 。

這位大神程序員單槍匹馬寫出了 VictoriaMetrics，性能質量橫掃了可觀測性世界。 隨后他搞了一家公司，主要提供企業(yè)技術支持，并將幾個專業(yè)模塊放在企業(yè)版里面。 不融資，沒有壓力，過的美滋滋。基本上 Pigsty 也是走的這種路子。

Pigsty 也有一個商業(yè)版，和開源版是同一套代碼庫，不過可以支持更多操作系統(tǒng)和更老的 PG 大版本。 里面有一個強力的命令行，DBA Agent，SKills 與 SOP，以及不開源的測試套件，里面有各種故障場景用例 —— 有點像 SQLite 的方式。

當然商業(yè)版不是重點，企業(yè)不會為你已經開源的部分付費，而只會為你提供的實際價值付費 —— 你能幫他把服務質量從 90 分做到 100 分，客戶就很樂意為此付費。 這包括質保，答疑，疑難雜癥兜底，以及把 PostgreSQL 干到超過 OpenAI 量級的實戰(zhàn)經驗，不會出現(xiàn)在 AI 語料中的 Know-How 知識與驗證能力。

說到底，老馮賣的不是產品，產品都開源當禮物送給大家了，還賣什么。賣的還是老馮自己的經驗與時間 —— 你可以白用 Pigsty，但總不能白嫖老馮吧？ —— 好在有了 AI 的幫助，大部分時候我只要負責問出正確的問題，并判斷結果的正確性就行了，相當于加了幾十倍時間杠桿，日常還是比較輕松的。

如果您在使用 Pigsty，覺得我做的事情對您有幫助，也歡迎用訂閱支持一下。一來有商業(yè)承諾與契約，二來這也是對軟件自由與開源生態(tài)的一種支持。

結語：Apache-2 不是妥協(xié)，是路線選擇

所以概括起來，從 AGPLv3 回到 Apache 2.0，不是老馮變軟了，也不是我天真了。

這是一個路線選擇：Pigsty 要做數(shù)據(jù)庫世界的 Debian —— 要做到這件事，開放與包容不是口號，是工程上的必需條件 —— 降低摩擦、擴大分發(fā)、建立生態(tài)。

Pigsty v4.0 已經正式發(fā)布可用，它我希望它能讓更多人更輕松地享受 PostgreSQL 的樂趣：用好、管好、省錢、省心。