← #790

你真的需要数据库吗？

文章摘要

这篇文章直接挑战了一个在现代软件开发中几乎被奉为默认选项的假设——应用一定需要数据库。作者提出的核心观点是：”数据库本质上只是文件”，真正的问题并非是否要使用文件，而是你是否愿意使用数据库为你提供的结构化能力，还是自行管理文件。

为了验证这个观点，作者使用 Go、Bun 和 Rust 三种语言，对三种存储方案在 1 万到 100 万条记录的数据集上进行了基准测试。三种方案分别是：线性扫描（每次请求读取整个文件，复杂度为 O(n)）；内存映射（启动时加载到内存，查询为 O(1)）；以及在磁盘上使用固定宽度索引的二分查找（O(log n)）。

测试结果相当令人意外。内存方案以每秒约 9.7 万次请求占据主导地位，二分查找可达到约 4 万次每秒，而 SQLite 的成绩仅为每秒约 2.5 万次。只有线性扫描在数据集增长后彻底崩盘，变得完全不实用。

作者指出，真正需要数据库的场景其实很具体：数据集超过内存容量、需要跨多字段查询或连接、多进程并发写入、以及需要跨实体的原子事务。反过来倒推一下性能数字：即便是最慢的方案也足够支撑数百万日活用户。一个典型的拥有 1 万客户的 SaaS 在高峰期也只有每秒 3 次请求的负载。

文章的结论颇具启发意义：”你是否需要数据库？诚实的回答是：可能还不需要。” 大多数早期阶段的应用其实远远低于数据库复杂度所能带来收益的性能门槛。

HN 评论精华

SQLite 成为新的默认起点：最高赞的观点认为应当”从简单开始但要对增长有现实预期”。多位评论者提到 “SQLite 已经成为我启动任何需要数据库的项目时的首选”。普遍共识是纯文件方案只适合极简场景，一旦出现多进程并发写入或者需要超出简单查询的能力，数据库几乎立刻变得必要。
最终都会重新发明数据库：资深开发者一致表示，那些一开始回避数据库的项目，最后都会重新发明数据库的各种特性。一位开发者分享：”我会重做设计用 SQLite”，而不是手工处理原子文件写入。另一位提到自己曾在平面文件上搭建查询引擎，过程非常痛苦——这说明早期采用数据库反而能避免后期的架构复杂度。
文件真正合适的场景：评论中列举了一些有效的文件方案用例——读多静态数据（一位开发者的影院排片网站使用零成本的 JSON 文件）、客户端加载压缩数据、以及单文件原子操作。但这些都属于具备特定约束的例外情况。
真正的成本不是性能而是可靠性：令人意外的是，速度并非核心顾虑。可靠性、一致性、事务安全和查询体验才是更重要的考量。一条评论一针见血地指出：数据损坏风险和原子性挑战使得数据库在几乎所有”玩具项目”之外的场景中都物有所值。
讽刺的是作者身份：一家做数据库 GUI 工具的公司发表这样的文章引发了许多读者的赞赏——在当今的技术写作中，这种诚实坦率的工程讨论相当罕见。