为什么 SQLite 够用的场景比你想的多

一台 2 核 4G 的云服务器频繁 OOM，排查下来发现 PostgreSQL 独占了近 1.5G 内存，而整个应用的日活不到 200 人。

选 Postgres 的理由是”生产环境不都得用正经数据库吗”。

大多数开发者对 SQLite 的认知还停留在”嵌入式专用”或”开发环境临时凑合”，但实际上 SQLite 能胜任的场景远比直觉告诉你的多。

先看一个数字

SQLite 官网上有一组经常被忽略的性能数据：在普通 SSD 上，SQLite 单线程每秒可以完成大约 40,000 次简单查询，写入吞吐在 WAL 模式下也能轻松达到每秒数千次事务。对于绝大多数 Web 应用来说，这个量级的性能根本不是瓶颈。

真正的瓶颈在哪？在网络。传统的 client-server 数据库每次查询都要走一次网络往返，延迟通常在 0.5ms 到几毫秒之间。而 SQLite 是进程内调用，查询延迟在微秒级别。当你的应用和数据库在同一台机器上时，SQLite 在读密集场景下反而比 Postgres 更快——因为它省掉了序列化、网络传输、反序列化这一整条链路。

那些”不够用”的担忧

反对 SQLite 的理由通常集中在三点：并发写入、水平扩展、高可用。逐个看。

并发写入。 SQLite 的写锁确实是库级别的，同一时刻只能有一个写事务。但 WAL 模式下，读写可以并发，多个读操作不会被写操作阻塞。如果你的写入量没有高到需要每秒处理上万次写事务，这根本不是问题。一个日活一万的内容社区，每秒的写入峰值可能也就几十次。

水平扩展。 这是个真实的限制——SQLite 跑在单机上，没法像分布式数据库那样横向扩容。但问题是，你的项目真的需要水平扩展吗？一台现代服务器配 NVMe SSD，跑 SQLite 支撑几十万日活并非天方夜谭。Pieter Levels 用单个 SQLite 文件支撑着多个月收入数万美元的产品，这已经不是个例而是一种被验证过的模式。

高可用。 Litestream 可以将 SQLite 的 WAL 持续流式复制到对象存储，恢复时间在秒级。LiteFS 提供了多节点只读副本的能力。这些工具不能完全替代 Postgres 的流复制方案，但对于大多数中小规模应用，已经足够可靠。

真正该问的问题

选数据库不应该从”行业标准是什么”出发，而应该从”我的实际需求是什么”出发。SQLite 的优势不仅仅是轻量——它是零运维的。没有独立进程要管理，没有连接池要调优，没有版本升级要协调，备份就是复制一个文件。这些隐性成本在小团队里往往比性能差异更重要。

如果你的应用确实需要多台服务器同时写入同一个数据库，或者需要复杂的权限管理和行级安全策略，Postgres 仍然是更合适的选择。

不过更值得关注的是：随着 Cloudflare D1、Turso 这类基于 SQLite 的分布式方案逐渐成熟，SQLite “不能水平扩展”这个最后的硬限制，还能成立多久？