对象存储S3 发布已经20 年了，已经成为现代数据基础设施的默认持久层,这不是偶然,而是几个独立趋势汇合的结果。

1️⃣ 云原生经济学对存储层提出了新的要求。

Kubernetes 把计算做成了弹性资源,EBS 没跟上。如果需要按用量付费、scale to zero、多租户共享的经济模型,最终只能落到 S3。S3 的延迟劣势并未消失;它的定价模型是目前几乎唯一匹配现代 workload真实形态的——尖峰、不可预测、长时间空闲。

2️⃣ S3 自身的演进。

2020 年 strong read-after-write consistency 全面落地; 2023 年 Express One Zone(single-digit ms 延迟)和 Mountpoint for S3 GA; 2024 年补上 conditional writes(IfNoneMatch / IfMatch,让 manifest commit 等协调操作可以lock-free 直接做在 S3 上); 2025 年 12 月 S3 Vectors GA,原生支持向量存储和查询; 2026 年 4 月 S3 Files GA,通过 NFS v4.1+ 把 bucket 暴露为共享文件系统。今天可以在其上构建数据库的 S3,已经不是 2008 年那个用来放静态图片的对象桶了[点赞]。

把数据库直接构建在 S3 上的不再是少数实验:Snowflake、Databricks、ClickHouse Cloud、WarpStream、Turbopuffer、Iceberg/Delta/Hudi 等。Postgres 的代表是 Neon——存储引擎完整下沉到对象存储,这在几年前对一个 OLTP系统而言并不是一个会被认真讨论的方向。

3️⃣ Workload 形态本身改变了,且不局限于某一垂直领域。

新增的高吞吐数据主体上是半结构化或非结构化的:向量、JSON、events、logs、traces。它出现在可观测性、业务分析、customer 360、AI 训练语料等多种场景。

仪表盘加离线 ETL 的模式正在让位给即席分析、RCA,以及越来越多由 agent 发起的开放式查询;operational 数据与 business 数据被并入同一个查询界面。这种 workload 是 append-heavy、吞吐密集、无法 capacity-plan的。对象存储在这种特征下天然占优,因为不需要为未到来的峰值预付容量。

几点必须明确:这不是免费方案。OLTP 的热路径仍然依赖本地 NVMe。小对象 API 调用费用在高频场景下可能超过存储本身的成本。Listing 仍然慢。跨云 egress 在规模上是不可忽视的支出。任何只讲"放在 S3 上"而不讨论caching、compaction、catalog 的方案,不构成完整的系统设计。

方向是确定的。2026 年新建一个数据系统,如果不把对象存储作为 source of truth,这应该是一个需要被解释的选择[思考]。

GreptimeDB 从第一天就是这个方向。Time-series 和可观测性恰好是这套经济学最早能够算明白的 workload 之一,但 pattern 不止于此。

OLTP 方向的同行如有不同看法,欢迎讨论。

更多请阅读 《S3 二十年编年史：如何成为现代数据系统的默认持久层》 http://t.cn/AX6j7VLn

References:
1. Snowflake SIGMOD 2016: http://t.cn/AX6j7VLu
2. Lakehouse CIDR 2021: http://t.cn/AX6j7VLm
3. S3 强一致性: http://t.cn/A6GFqRAD
4. S3 Express One Zone: http://t.cn/AX6j7VLB
5. Mountpoint for S3: http://t.cn/AX6j7VLr
6. S3 Vectors: http://t.cn/AX6j7VL3
7. S3 Files: http://t.cn/AX6j7VLg
8. Neon: http://t.cn/AX6j7VLd
9. WarpStream: http://t.cn/AX6j7VL1
10. GreptimeDB: http://t.cn/AXxT1qoA

#对象存储##数据库#