SQLite 不是小玩具了，但也别急着替掉 Postgres

Mon, 06 Jul 2026 19:40:00 +0800

很多后端团队有一个很顽固的默认值：能上 Postgres，就上 Postgres。

配置表放 Postgres，后台任务状态放 Postgres，内部仪表盘也查 Postgres。哪怕那张表一天写不了几次，哪怕服务只是读几个本地状态，大家还是会觉得：这才像“正经后端”。

SQLite 在很多人的脑子里一直不太体面。

它像移动端缓存，像桌面软件本地存储，像 demo 里的临时方案。评审会上你说“这个服务我想用 SQLite”，对面很可能第一反应不是问场景，而是问：以后撑得住吗？

可到了 2026 年，这个直觉开始不够用了。

SQLite 官方一直把自己称为“小、快、自包含、高可靠、全功能”的 SQL 数据库引擎，还说它可能是世界上使用最广的数据库引擎。它不是这两年才突然变强。真正变化的是应用形态：边缘节点更多，本地优先应用更多，一个用户、一个租户、一个 agent 拥有自己小数据库的场景更多。

过去你默认把数据放到一个远程数据库服务里。现在越来越多场景会反过来问：这份数据，真的需要先离开应用吗？

这就是 SQLite 重新值得看的原因。

不是 Postgres 不行了。Postgres 仍然是很多系统的稳妥答案。变化在于，SQLite 不再只能扮演“小项目玩具”的角色。rqlite、LiteFS、Turso/libSQL、DuckDB 这些项目，把“嵌入式数据库”这件事推向了四个完全不同的方向。

SQLite 没变，是我们的系统变重了

SQLite 的老问题大家都知道。

它是单文件数据库，没有一个独立的 server 进程；并发写有天花板；默认没有网络协议；WAL 能让读写并发好一些，但同一个 WAL 仍然只有一个 writer，而且不适合网络文件系统。

这些限制都是真的。

问题是，很多后端项目并没有先问自己：我现在面对的到底是不是这些限制。

一个 read-heavy 的内部仪表盘，可能只是反复读几十张小表；一个边缘节点，可能更在意本地延迟和断网可用；一个 AI agent 的会话状态，可能天然适合跟着进程和文件走；一个多租户 SaaS 的小租户，可能更想要隔离、迁移、备份简单，而不是所有租户挤在同一个大库里。

在这些地方，SQLite 的“文件属性”反而变成优点。

文件可以复制，可以随应用部署，可以按租户切分，可以直接备份，可以在本地读。它不需要你先拉起一个数据库服务，也不要求每个简单查询都跨一次网络。

这不是说 SQLite 突然适合所有后端。

更准确的说法是：当应用被拆得更小、更靠近用户、更强调本地状态时，过去那个被嫌弃的“单文件”，重新变成一个很有工程价值的单位。

rqlite 是这条线里很早的代表。

它从 2014 年开始做，Go 写的，底下用 SQLite 存数据，外面套一层 Raft。到 2026 年 7 月，GitHub stars 大约 17.6K，仍然有新 release。