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

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

總結(jié)一句話：沒有完美替代。

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

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

MinIO 替代品速覽

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

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

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

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

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

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

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

RustFS 是否可以替代 MinIO

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

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

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

RustFS 是否會重蹈 MinIO 覆轍

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

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

我用的 Prompt 如下：

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

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

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

RustFS 這些風(fēng)險信號與當(dāng)年的 MinIO 幾乎一模一樣：Apache 2.0 + 版權(quán)轉(zhuǎn)讓型 CLA + 單一商業(yè)公司控制。 考慮到這些因素，老馮對 RustFS 的評級從 “樂觀期待”，下調(diào)為 “謹慎觀望”。

所以，應(yīng)該怎么做？

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

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

老馮覺得目前最優(yōu)的方案，還是繼續(xù)使用 MinIO 的最新版本，鎖定版本，做好網(wǎng)絡(luò)隔離。 等待半年左右，看看社區(qū)生態(tài)的發(fā)展再做打算。如果那時候 MinIO 有人接手，或者 RustFS GA 可用了，再做調(diào)整也不遲。

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

繼續(xù)使用 MinIO 的注意事項

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

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

這個漏洞允許低權(quán)限用戶創(chuàng)建一個新的賬戶實現(xiàn)權(quán)限提升。不過如果是在內(nèi)網(wǎng)環(huán)境中，并且做好網(wǎng)絡(luò)隔離的話，這個漏洞的風(fēng)險也是相對可控的。 這個漏洞已經(jīng)在 MinIO 20251015 版本中修復(fù)了，但是 MinIO 很雞賊的從這個版本開始移除了二進制，只提供源代碼。

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

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

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

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

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