在 2026 年的系统架构讨论中，一个反复出现的议题是「你真的需要数据库吗？」这个问题看似简单，背后却涉及成本、运维复杂度、性能可预测性以及开发速度的多维权衡。对于许多现代 serverless 应用而言，传统数据库并非唯一选择，文件系统、对象存储甚至简单的键值存储往往足以支撑业务初期的发展，直到数据模型复杂度达到必须引入数据库的时刻。
serverless 存储的吸引力与代价
对象存储（如 S3、Cloudflare R2）和键值存储（如 DynamoDB、Redis）之所以成为 serverless 架构的默认选项，核心原因在于它们的运维成本极低且具备近乎无限的弹性伸缩能力。当业务流量趋近于零时，存储成本可以缩放到几乎不产生费用，这对于初创项目、原型验证和内部工具来说是极具吸引力的特性。相比之下，传统 RDS 数据库即使在闲置状态下也会产生固定的计算资源占用费用，这在成本敏感的业务早期阶段是不可忽视的负担。
然而，serverless 存储的代价同样明确。首先是查询能力的限制 —— 对象存储本质上是 blob 存储，不支持复杂查询、JOIN 操作或事务语义。其次是性能可预测性问题：虽然峰值吞吐量可以很高，但冷启动延迟和突发流量下的响应时间波动较大，对于延迟敏感型业务可能造成用户体验波动。根据行业实践建议，serverless 存储最适合的场景是突发流量业务、原型快速迭代、内部工具以及流量模式不规则的工作负载。对于持续高负载且流量可预测的场景，预置资源往往更具成本效益和稳定性。
何时可以暂时跳过数据库
判断是否需要数据库，需要审视业务数据的本质特征。如果你的数据满足以下条件，文件系统或对象存储可能是更务实的选择：数据以只读或追加写为主，几乎不需要更新历史记录；查询需求简单，仅通过主键或单一维度检索；不存在多用户并发修改同一数据的场景；数据的完整性由上游系统保证，存储层仅负责持久化。
以日志收集与分析平台为例，早期阶段完全可以将结构化日志以 JSON 文件形式存入对象存储，通过分区路径实现时间范围过滤，配合 Athena 或 ClickHouse 等查询引擎按需分析。这种方案的写入吞吐量远高于传统数据库的 INSERT 性能，且成本随数据量线性增长而非受限于连接数。另一个典型场景是用户上传的媒体文件存储，业务系统只需要记录文件标识符与元数据的映射关系，元数据可以直接存入键值存储或简单的 JSON 清单文件，只有当查询复杂度上升到需要多维度筛选、关联分析时，才有必要迁移到具备 ACID 能力的数据库。
迁移临界点的量化判断
工程团队需要建立明确的迁移信号指标，而非凭直觉决策。以下几个量化阈值可作为参考：首先，单表数据量超过数千万条且查询延迟开始明显增长；其次，业务需求出现多表 JOIN、聚合统计或复杂过滤条件；再次，需要支持多用户并发写入且对数据一致性有严格要求；最后，审计日志与历史版本追溯成为合规必需。当上述任一条件出现时，即应启动数据库引入评估。
对于仍处于犹豫阶段的团队，建议采用「先文件系统、后数据库」的两阶段策略。第一阶段使用对象存储加键值存储快速上线，验证产品假设和用户需求；第二阶段根据实际数据规模和查询模式选择合适的数据库技术。如果业务发展顺利，数据量自然会给出答案；如果业务模式被验证为不可行，也避免了为不需要的数据层投入运维精力。
参考资料
- Hacker News 讨论：数据库在现代应用中的必要性探讨
- 2026 年数据库技术趋势分析