MinIO 社区版从 2025 年开始一步步收紧——先砍掉社区版免费的 Web 控制台，再停发 Docker 镜像，最后宣布进入维护模式。对还在自托管对象存储的人来说，这意味着得认真想"下一个用什么"。我顺着这条线摸到了 RustFS：一个用 Rust 重写的、S3 兼容的对象存储，定位明显是冲着 MinIO 去的。它没什么融资故事，GitHub 仓库 2023 年底就建了，但真正被社区注意到，是 2025 年下半年 MinIO 退场之后。我花了一晚上把能查的都查了，下面是我的判断——它接不接得住，以及哪些地方还差口气。

先把地基钉死：GitHub 实拉的数据

能直接查的，我用 API 拉真实数据，不靠任何二手转述。下面是 2026-09-21 从 GitHub API 拿到的实况：

项目实拉数据
rustfs/rustfs33,509 stars · Rust · Apache-2.0 · 未归档 · 1,501 forks
最新 releaseRustFS 1.0.0，2026-09-16 发布
rustfs/mcp存在，26 stars，Apache-2.0，2026-04-17 建
rustfs/operator存在，125 stars，Rust，2025-07-10 建

关于时间线有个细节值得留意：GitHub 显示仓库 created_at 是 2023-11-23，但默认分支最早的有效提交都在 2024 年中之后，而作为 MinIO 平替公开活动的 operator 仓库是 2025-07 建的。我的判断是，2023 那个日期更像是早期私有或改名仓库的创建时间，"2025 年 7 月开源"指的应该是它作为 MinIO 平替公开登场的节点。

有些官方宣传数字——比如"镜像拉取超 1000 万、装机 270 万、160+ 贡献者"——我无法独立核验，下文不引用为结论。

MinIO 退场：为什么我在看平替

RustFS 起势的真实背景，我交叉了多个来源：2025-05 砍掉社区版控制台管理功能（约 11.4 万行代码）、2025-10 停发 Docker 镜像与预编译二进制、2025-12 宣布进入维护模式、2026 年春季仓库被归档锁定。大方向属实。

这里有个时间线细节要校准："维护模式"和"仓库归档"不是同一天发生的——归档实际发生在 2026 年 2 月到 4 月，而不是 2025 年 12 月。背景是真的，但把两件事压到同一个时间点，会让人误判 MinIO 退场的紧迫程度。

能力清单：哪些是真能用的

我逐项读了 README，大部分能力是站得住的，但有两处措辞要校准：

  • S3 兼容 + 完整免费控制台：README 原话是 "combines the simplicity of MinIO with the memory safety and raw performance of Rust"，定位就是 MinIO 平替。相对 MinIO 被砍的管理控台，这是真卖点。
  • 协议：S3 / WebDAV / FTPS / Swift / SFTP 都标了 Available。注意官方标的是 FTPS（不是明文 FTP）。MCP 不是内核内置协议，而是独立仓库 rustfs/mcp（我确认过存在），别当成开箱即用的一个开关。
  • 安全：IAM/Policies、OIDC/SSO、RustFS KMS（支持 Vault KV2/Transit 与 AWS KMS）都是 Available。
  • 可靠性：Bitrot Protection、Object Lock (WORM)、Versioning 都 Available；纠删码机制 README 多次出现（Erasure Set / parity），但"比三副本省一半盘"是 EC 的通用属性，不是 RustFS 独有的测试结论。
  • rc 客户端：README 确认有名为 rc 的 S3 兼容客户端，"对标 mc" 我没能从 README 找到原话，但客户端确实存在。
RustFS 能力全景图：核心 S3 兼容存储层之上是协议层、安全与管控层、完整控制台，以及标记为 Preview 的 S3 Table（Iceberg REST）
图：RustFS 能力分层（基于 README 与官方文档逐项核验）

S3 Table 这个最大卖点，我特意扒了官方文档

S3 Table（Iceberg 表）是它最大的卖点之一，也是和 AWS / MinIO AIStor 拉开差异的地方。我去读了官方的 S3 Tables Support Matrix，发现它确实可用，但状态比"正式上线"要保守：

  • README 把 S3 Tables (Iceberg REST) 标为 🧪 Preview。
  • Catalog 接口挂在 /iceberg/v1（另有 /_iceberg/v1 兼容 MinIO AIStor 别名），和 S3 object data plane 构建在同一数据平面之上。所以"一个 9000 端口同时提供 S3 和 Iceberg REST"这个架构描述是成立的。
  • 但状态不是 GA：核心 Catalog API 是 Supported，维护/迁移类很多是 Preview / controlled；引擎覆盖是 bounded——PyIceberg 和 DuckDB 只有 smoke 级覆盖，Spark 明确需要手动实测（文档原话 "needs recorded live evidence"）。文档自己写了 Do not claim: "RustFS is fully compatible with AWS S3 Tables."

我的判断：能跑通建表、写数、查数的 demo，但别当成生产级 S3 Tables 来用。想在测试环境尝鲜 Iceberg 是可以的，真要上生产，先把引擎兼容性这一段啃完。

S3 Table 双接口架构：RustFS 进程在 9000 端口同时暴露 S3 object data plane 与 /iceberg/v1 REST Catalog，上层 Spark/DuckDB/PyIceberg 引擎标注了各自的覆盖程度
图：S3 Table 双接口架构与引擎覆盖程度（官方 support matrix 梳理）

迁移 MinIO，怎么落地才稳

如果你打算把 MinIO 的数据迁过来，思路很直接：用 mc mirror 或 rclone 做 S3→S3 同步，老数据分批搬，全部搬完后再跑一次增量同步补齐，验证没问题再切流量。这条路是通的。

但有一个硬坑：README 明确写 "Objects MinIO encrypted are not readable by RustFS"——MinIO 磁盘格式兼容目前是 Preview，且加密对象 RustFS 读不出来。如果你的桶开了服务端加密（SSE-C / SSE-KMS 等），迁移前一定要先搞清楚加密方式，否则历史对象可能搬过去也读不了。

什么场景我建议用，什么不建议

场景结论
适合新项目要 S3 兼容存储、不想碰被砍的 MinIO 控台；信得过 Apache-2.0 + Rust 内存安全；已在用 mc / rclone，迁移成本低；想先在测试环境尝鲜 S3 Table / Iceberg。
不建议生产强依赖 S3 Tables 且要和 AWS 100% 对齐（还是 Preview/bounded）；MinIO 桶里有服务端加密对象又要整盘迁移（加密对象读不了）；对"社区版会不会哪天又变卦"零容忍——RustFS 背后是商业公司，路线和 MinIO 一样有商业化变量；需要 1.0.0 之外长期稳定 LTS 承诺的（项目还年轻）。

一句话总结：RustFS 是目前形态上最接近 MinIO 平替的开源选项，S3 兼容和控台都到位；但 S3 Table 与 MinIO 磁盘兼容都还在 Preview，生产落地前请先在测试环境把"加密对象迁移"这条路验明白——这是我在读文档时最想提醒自己的一点。

说明：本文写作时我的环境没跑起来 Docker 守护进程，没能在本地把 RustFS 真正启动验证，因此上面的能力判断来自 GitHub API 实拉数据、官方 README 与 S3 Tables Support Matrix 文档。star 数、release 版本、仓库创建时间、协议与能力清单都可以在上述来源复核。如果你想看一次真实实跑，我可以另开一轮把 Docker 拉起来，把 9000 / 9001 端口和 rc 客户端都探一遍。