对象存储正在吞掉数据湖：RustFS 1.0 GA 与 MinIO AIStor Tables 把 2026 风向说清楚

1. 问题背景：数据团队的两套存储越来越别扭

过去十年，搞数据的团队基本是两套系统在并行跑。对象存储（S3 及兼容方案）放图片、日志、模型权重、备份这些非结构化 blob；另一边再养一套独立的元数据和表引擎（Hive Metastore、Delta Lake、Iceberg catalog）去管结构化的表。两套系统意味着两份权限、两份治理、两份账单，还要写一堆把对象路径和表元数据对齐的胶水管道。

这个缝在 AI 时代被扯得更大了。模型训练和推理既要喂非结构化数据，又要读特征表、向量、标注，还得反复 checkpoint。数据来回搬一次，延迟和成本就涨一截。于是 2026 年出现了一个很明确的行业动作：大家不再把对象存储和表引擎分开养，而是直接把表能力塞进对象存储内核。谁先把这件事做得干净，谁就离"一个存储底座喂饱所有 AI 负载"更近一步。

2. 风向变了：对象存储开始内置表引擎

这条主线其实三家都在走，只是姿势不同。

AWS 最早动手，S3 Tables 把托管的 Apache Iceberg 表直接挂到 S3 上，算是把"对象 + 表"的抽象第一次摆到云用户面前。但在自建和私有化场景里，真正把这件事推向开源社区的，是今年两家做 S3 兼容存储的玩家。

MinIO 在 2026 年 2 月 3 日宣布 AIStor Tables 正式 GA，把完整的 Apache Iceberg V3 Catalog REST API 内置进数据平面，主打"对象与表同一套数据平面、同一套安全模型"。它甚至更进一步，在 2026 年 8 月推出 AIStor Memory，用对象存储给 AI agent 提供持久化记忆，把存储的边界又往外推了一层。

RustFS 则在 2026 年 9 月 16 日发布的 1.0.0 GA 里，把 S3 Tables（Apache Iceberg REST Catalog）作为内核级能力放进了存储引擎。注意它和 MinIO 的关键区别：RustFS 这条路是走在 Apache 2.0 的开源内核上，而 MinIO 的 Tables 落在商业版 AIStor 里。这个区别后面会反复出现。

3. RustFS 1.0.0 GA 做了什么

RustFS 1.0.0 的"GA"定义很克制，官方把它限定在一条：核心对象存储引擎（PUT/GET、分片上传、版本、复制、S3 API 面）已经稳定、可上生产。从 2024 年 2 月第一行代码，到 2025 年 7 月开源，再到 2026 年 9 月 GA，团队花了两年七个月。

几个值得记的数字（来源：RustFS 官方 GA 公告）：

GitHub Stars 超过 32,000
Docker Hub 镜像拉取超过 1,000 万次
全球部署实例超过 270 万
全球贡献者超过 160 位
9 次登上 GitHub Trending、50 多次登上 GitHub Rust Trending
加入 NVIDIA Inception 计划

在能力上，1.0.0 把数据面、多协议、安全、高可用几块都铺齐了：

数据管理：桶/对象生命周期、分片上传、纠删码（EC）、数据分层、S3 Tables
多协议：S3、WebDAV、Swift、FTP/FTPS、MCP
安全合规：IAM、OIDC、KMS 集成、SSE、STS、安全审计、mTLS
高可用：分布式部署、池扩容、数据再平衡、节点自愈、站点/桶复制

这里最值得拿出来讲的是 S3 Tables。和 MinIO 把表能力放进商业 AIStor 不同，RustFS 把它做进了开源内核，意味着你用一套 Apache 2.0 的自托管存储，就能同时拿到对象桶和 Iceberg 表两种语义，不用额外再养一个 metastore。

数据必须来自官方 benchmark / 文档 / 已验证来源，严禁编造或夸大。

4. 和 MinIO AIStor Tables 摆在一起看

把两张牌摊开，差别主要在"开放程度"和"成熟度"两个轴上。

维度	RustFS 1.0.0 GA	MinIO AIStor Tables
表引擎形态	S3 Tables / Iceberg REST Catalog，做进开源内核	AIStor Tables / Iceberg V3，内置数据平面
许可证	核心 Apache 2.0（开源）	Tables 在商业版 AIStor；OSS 主线已转 AGPL 且停止维护
对象 + 表统一	同一内核，免独立 metastore	同一数据平面、同一安全模型
成熟阶段	S3 Tables 在官方能力矩阵中标为 preview	Tables 已 GA（2026-02），并延伸出 Memory（2026-08）
自托管定位	drop-in 替代 MinIO 的开源 S3 存储	企业 AI 数据底座，偏订阅制

读这张表要清醒：RustFS 把 Iceberg 放进开源内核，对不想被商业许可绑住、又想要"对象 + 表"统一语义的自建用户很有吸引力；但它在表引擎这条线上的打磨时间明显比 MinIO 短，官方自己也把 S3 Tables 标在 preview。MinIO 的 Tables 更成熟、还往前走了 agent memory，代价是你得接受它现在走的是商业 AIStor 路线，而不是当年那套可以随便自部署的免费 OSS。

选哪边，本质上是在"开源自由"和"功能成熟度"之间做取舍，不是谁把谁秒了。

5. 真实数据与边界

把能溯源的事实摆出来，也把短板说清楚，不替任何一方遮掩。

指标	RustFS 1.0.0 GA	MinIO AIStor Tables	来源
发布时间	2026-09-16	2026-02-03（Tables GA）	官方公告
GitHub Stars	32,000+	未单独披露（OSS 主线已转 AGPL）	RustFS 官方 GA 公告
全球部署实例	270 万+	未单独披露	RustFS 官方 GA 公告
表引擎成熟度	S3 Tables 标为 preview	Iceberg V3，已 GA 并延伸 Memory	RustFS 能力矩阵 / MinIO 公告
许可证	Apache 2.0 核心	商业 AIStor（OSS 转 AGPL）	双方发布材料

诚实的边界有两点。第一，RustFS 1.0.0 的"生产就绪"限定在核心对象存储路径，S3 Tables 还标在 preview，意味着你要拿它跑严肃的 Iceberg 分析负载，现阶段应该小范围验证、别直接顶生产主链路。第二，MinIO 这一侧虽然 Tables 成熟，但它已不是当年那个随便 docker run 就能用的免费开源件，迁移过去前得先算清楚许可证和订阅的账。

另外补一个背景数据：MinIO 对外宣称 AIStor 在 WARP 基准下峰值吞吐 23.5 TiB/s、比专有方案低约 40% TCO、77% 财富 500 强在用。这些是 MinIO 自家口径，当作参考即可，别当独立第三方结论。

6. 总结与下一步

2026 年对象存储最实在的变化，就是存储内核开始直接吃下表引擎，对象桶和 Iceberg 表从"两套系统"收敛成"一套底座"。RustFS 1.0 GA 把这条线用 Apache 2.0 开源内核的方式交到自建用户手里，MinIO 则用更成熟的商业 AIStor Tables 先走一步。

如果你想亲自看 RustFS 这条路线落地到什么程度，最快的方式是把 1.0.0 GA 用官方 docker-compose 起一个单节点，然后用 Spark 或 Trino 连它的 /iceberg/v1/config 端点，看表能不能直接建在对象存储内核里：

bash 复制代码

docker run -p 9000:9000 -p 9001:9001 \
  -v /data/rustfs:/data \
  rustfs/rustfs:latest server /data --console-address ":9001"

curl -s http://localhost:9000/iceberg/v1/config

下一步值得盯两件事：RustFS 把 S3 Tables 从 preview 推到 GA 的节奏，以及它路线图里提到的 S3 Vectors 和围绕 AI 的 2.0。前者决定它能不能真正在表引擎这条线和 MinIO 正面刚，后者决定它能不能从"对象存储"升级成"AI 数据底座"。这两步走稳了，2026 下半年的存储格局才会真正有意思起来。