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。 比起自己从零瞎搞一个对象存储，接手一个成熟的项目，反而是更省事的选择。

专栏：数据库老司机