我今天看到一篇文章，重建了我的世界观，让我对 普通人 有必要使用数据库 这个问题产生疑问了。
有意思的是，这是一个海外的 数据库运维产品 dbpro 的官方博客里发的，自己给自己数据库行业打脸哈哈： Do You Even Need a Database? - DB Pro Blog 《你真的需要数据库吗》
其实数据库，就是一个文件，但是其实很多时候，自己在本地对文件来增删查改，其实也不是不行。
虽然可能没法用那让人头疼的丑陋的 SQL 语言去操作了，但是使用编程语言来提取自己想要的数据也不是不行。而且其实使用编程语言来提取数据，更直观，更易于维护。
然后有个叫 杰伊 的大佬，就去探索文本增删查改，能实现的极限是多远！看看 数据库 和 文本 增删查改 的性能分界线是在哪里！！！看完这文后，我发觉，其实我这辈子挣 100 万可能也用不到数据库哇。
我个人感觉，数据库更像是过去古代，电脑性能低下，不得不使用一个高度算法优化的特殊储存结构来维持数据读取速度，到了现在，抖音 4K 直播都是畅饮的高性能时代，数据库确实很鸡肋了。
作者使用了 GO BUN RUST ，三个在 高性能 上颇有建树的语言，进行压力测试。
然后就是 JSON 文件储存数据，类似这样：
{
"id": "a3f1...",
"name": "Alice Chen",
"email": "alice@example.com",
"created_at": "2026-04-15T..."
},
{
"id": "b7d2...",
"name": "Bob Torres",
"email": "bob@example.com",
"created_at": "2026-04-15T..."
}然后，开发两个 API ，一个用于创建用户 POST /users ，另一个是按照 ID 查询 GET /users/:id 。之后进行压力基准测试。
读取方面的策略：
第一个策略是【线性扫描】，收到请求，就打开文件，逐行扫描解析 JSON ，然后查找 ID 返回数据。复杂度O(n) ，直来直去嘛。
第二个策略【内存映射】，先读取完文件，然后把记录放到哈希表里，就是内存里，然后读取只需要映射查找就 OK 了！这个是典型的 O(1)复杂度 ，很快！Go 语言中的sync.RWMutex和 Rust 中的RwLock允许多个读取器并行执行，因此并发请求不会相互阻塞。缺点就是费内存。
第三个策略【二分查找】，比较复杂，就是使用索引，在查询时二分法查找（对于 100 万条记录大约 20 次），然后就能够以比较少的内存，实现尽可能快的读取了。这个是典型的 O(log n) 复杂度。缺点就是需要定期重建索引。（这个只测试了 GO 语言）
测试设备是 M1 Mac mini 。现在来看看结果。
每秒请求数（越高越好），你可以理解为极限每秒并发数：
一目了然，百万数据下，二分法 和 内存映射法 ，和使用数据库差不多。当然，内存肯定高了，废内存，能不高吗？
但是真正值得关注的，是线性扫描。百万数据，并发可以达到 23 ，这个场景相当少见了，我的几个个人出海的 AI SaaS 站，每月给我带来几千美刀的收入，每月的流量也不过才几十万次，并发... 很罕见。顶多也就 2 个人并发。在这里，23 简直是一个天文数字。
换成日活，大概 280w 的日活，也就是月访问量 9000w 的产品，就可以应付了。
大不了，换成 二分法 ，比数据库还快。又不损失什么。。。
当然看看这里的 25085 ，这个是数据库 sqlite 的成绩，这个数字是什么含义呢？大概能撑得起 9000w 的日活啊！比知乎还高！笑着问一下，您配使用数据库吗？
更别提下面的内存了，其实最吊的 rust 内存大法，让一个 M1 的 Mac ，169106 的并发成绩，能撑得起更让人惊讶的 6 亿日活！抖音、微信体量，就一个淘宝上 1000 元的二手 M1 芯片的 Mac mini ，就撑起来了！
每个请求的平均延迟（越低越好）：
（注意，里面有微秒，1000 微秒等于 1 毫秒）
论延迟的话，线性扫描确实很慢，但是二分法依然比数据库还快。
虽然看起来，数据库 在请求延迟上、每秒并发上，基本完胜，但是 二分法 真的完全出乎我的意料！太厉害了。始终压数据库一头。当然，线性扫描，1S 的延迟，大部分场景还是能接受的。
更厉害的，还是内存大法，不管怎么玩儿，都是微秒。其实如果是普通用户，数据就几个文本的话，内存撑死也就几十 mb ，完胜啊！其实，也可以使用 Redis 。
那么，使用场景：
所以说，现在这个时代，真的是性能过剩了。
99％的初创项目死于没流量，而不是死于流量太大把服务器冲垮。我建议创业公司不要搞这些东西，直接买个鸡前后端分离，最多就做一下local first,如果需要回国就上个优化线路。等到真的全球化推广了，你可以最前端的那一小部分上一下Cloudflare。（我们项目就是为了极致的边缘和弹性计算，被折腾来折腾去上线一次又一次的推迟，都是血和泪的实战教训）
所以，如果你不是在不缺钱的大厂工作，学历和工资之高，能让你发愁并发动不动上 1w ，那其实在这个时代，纠结一个数据库、数据表有点杞人忧天了 ~
其实，当年 Instagram 还没被扎克伯格买走时，4亿的日活，就运行了一个 PostgreSQL 就 OK 了。
换言之，我们永远也达不到性能瓶颈，敞开用吧！而且，JSON 格式的文件，能导入任何数据库。即便你发大财了，也难不到你！
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。