MinIO 已死，誰能接盤？

前天 MinIO 宣告進入維護模式，老馮寫了一篇《》聊了聊這個話題。 很多朋友也問我，MinIO 既然擺爛躺平了，有誰能接 MinIO 的班？

大方向的話，臺面上的替代品無非就那幾個：Ceph、RustFS、SeaweedFS、Garage…… 老馮把這些方案都打好了 Linux 上的 RPM/DEB 包，挨個試了一遍。

總結一句話：沒有完美替代。

老馮給這些方案都打好了 Linux 上的 RPM/DEB 包（https://pgext.cloud），都試驗了一把。總體的結論是，沒有一個能完美替代 MinIO 的方案。

各有各的問題 —— Ceph 功能全但太復雜；SeaweedFS 針對小文件優化但需要獨立元數據庫；Garage 小巧玲瓏但功能簡陋；RustFS 兼容 MinIO 但竟然還是 Alpha。

MinIO 替代品速覽

MinIO 是 AWS S3 的開源替代，所以從單純的 對象 CRUD 功能 上來講，任何兼容 S3 API 的對象存儲系統都可以作為 MinIO 的替代品。 但如果考慮到非功能類特性 —— 可靠性，可運維性，復雜度，工具鏈，生態成熟度，運維 SOP 這些，想要 “平替” 掉 MinIO 確實不容易。

這里我們不聊商業存儲，云廠商的對象存儲服務，只聊開源項目的話，大體上會有這些選擇：

Ceph 可能是企業用戶的最佳選擇，但學習曲線陡峭，適合有專人運維的團隊，不像 MinIO 一個二進制走天下。 很多用戶并不需要分布式塊存儲和分布式文件系統的功能，而且運行還需要額外的 Podmon，不如 MinIO 爽利。

SeaweedFS 質量不錯，針對海量小文件場景做優化，O(1) 磁盤尋址，小文件場景性能碾壓。 但它需要一個獨立的元數據庫來存儲文件元信息，這就帶來了外部依賴。如果你需要一個"通用對象存儲"，它不是最佳答案。

Garage 是歐洲 Deuxfleurs 團隊的作品，拿過歐盟 NGI 資助，適合自托管愛好者和邊緣計算場景。 非常輕量（10MB），但 S3 兼容性太弱，沒有版本控制，跨區域復制，IAM 這些，不適合企業場景。

RustFS 是唯一一個瞄準"MinIO 替代"生態位的項目，但成熟度不足 —— 竟然還是 Alpha。

結果，沒有一個能 “完美” 取代 MinIO 生態位的。細節的話，就用下面這個 Claude 4 Opus 深度研究報告吧（粗略參考）

RustFS 是否可以替代 MinIO

在所有號稱"MinIO 開源替代"的項目中，老馮本來最看好 RustFS，所以特地花了些時間測試。 我在 Pigsty 中嘗試將 MinIO 換成 RustFS，大部分邏輯可以復用，但還是有些區別：

?RustFS 對證書名稱有特殊要求?RustFS 的健康檢查接口與 MinIO 有所不同?RustFS 不支持 mc admin 管理命令，無法配置詳細的 IAM 策略。這一點對企業用戶而言比較重要。

總的來說，跑起來了，但老馮思考再三，還是把這個分支給放棄掉了。因為把 Alpha 版的軟件用在生產環境實在是太不像話了。 我是比較期待 RustFS GA 版本出來之后，再來做一次評測。

RustFS 是否會重蹈 MinIO 覆轍

當然，RustFS 這個項目雖然看上去很有潛力，但也存在一些問題。例如，RustFS 是否會重蹈 MinIO 覆轍？ 特別是，RustFS 在很多雷點上，跟 MinIO 十分相似。

老馮請 AI SOTA 三件套（GPT5-pro, Claude4-Opus, Gemini3-pro）對 RustFS 的風險進行了全面的分析評測。

我用的 Prompt 如下：

Claude Opus 4: https://claude.ai/public/artifacts/eedd69db-c3cf-4e85-b213-47cf25b36ae4

Gemini 3 Pro: https://gemini.google.com/share/b024ed739ecb 則對 RustFS 提出了相當嚴重的指控：

其中 Gemini 對 RustFS 項目提出來了幾項相當嚴重的指控，老馮又請 Claude 核實了一遍。

RustFS 這些風險信號與當年的 MinIO 幾乎一模一樣：Apache 2.0 + 版權轉讓型 CLA + 單一商業公司控制。 考慮到這些因素，老馮對 RustFS 的評級從 “樂觀期待”，下調為 “謹慎觀望”。

所以，應該怎么做？

老馮的 PostgreSQL 發行版 Pigsty 里面集成了 MinIO 作為對象存儲的解決方案。 這完全是一個可選的模塊，主要作用是 —— 存儲 PostgreSQL 備份，以及在其他業務軟件需要對象存儲的時候提供一個 —— 比如自建 Supabase 。

考察了現有的生態替代品之后，老馮確實是不想再折騰換 MinIO 的事情了，也許會提供一個用 pgbackrest 自己的備份服務器替代掉 MinIO 的選項。

老馮覺得目前最優的方案，還是繼續使用 MinIO 的最新版本，鎖定版本，做好網絡隔離。 等待半年左右，看看社區生態的發展再做打算。如果那時候 MinIO 有人接手，或者 RustFS GA 可用了，再做調整也不遲。

當然，RustFS 也可以抓住這個機會，搶占 MinIO 的生態位，并真的實現一個更好，更安全，協議更友善的 MinIO 版本。機會不等人，老馮覺得這個窗口也就幾個月時間，錯過了就是錯過了。

繼續使用 MinIO 的注意事項

如果要繼續使用 MinIO，有這么幾個注意事項。第一是應該用什么版本。 雖然說，MinIO 20250422 版本是最后一個功能完整（帶有控制臺 GUI）的版本，但老馮還是建議使用最新的版本。

因為從 20250422 到現在（2025-12-08）這段期間，MinIO 有一個比較嚴重的 CVE 安全漏洞。CVE-2025-62506: Privilege escalation via session policy bypass (HIGH)

這個漏洞允許低權限用戶創建一個新的賬戶實現權限提升。不過如果是在內網環境中，并且做好網絡隔離的話，這個漏洞的風險也是相對可控的。 這個漏洞已經在 MinIO 20251015 版本中修復了，但是 MinIO 很雞賊的從這個版本開始移除了二進制，只提供源代碼。

不過老馮覺得還好，因為 MinIO 是一個 Go 語言項目，編譯就一條命令，跨平臺編譯 goreleaser 一把梭也很簡單。 流程我已經跑通了，其實很簡單，這個事老馮可以整，等測一陣沒問題了就發到 Pigsty 倉庫里去，把 MinIO 重新從一個 “源碼發行版” 恢復成一個二進制發行版。

但安全漏洞和BUG還是得有人來修的。老馮覺得，社區里如果有人愿意接手 MinIO 的話，現在還真是一個非常好的機會。 從 20250422 版本作為基礎，CherryPick 重要的 Bug 和安全修復的話，然后開始維護一個 MinIO 社區版本。

說到底，MinIO 經過這么長時間的社區打磨，已經是一個相當成熟穩定的對象存儲系統了 —— 基本上算是一個 “已完成的軟件”。 需要的不是更新跟進S3各種花里胡哨的新功能（S3 Vector/S3 Table），而是扎扎實實的修 Bug 和安全漏洞。

這種維護狀態的軟件，搞一個 LTS，社區自發維護起來并不難。如果 MinIO 團隊不愿意繼續維護， 老馮覺得社區里會自發涌現出接棒的人選 —— 畢竟現在有很多商業存儲硬件公司都在用 MinIO。 比起自己從零瞎搞一個對象存儲，接手一個成熟的項目，反而是更省事的選擇。

專欄：數據庫老司機