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

很多后端团队有一个很顽固的默认值：能上 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：它要解决的不是写性能，而是可用性

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

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

很多人第一次听到“SQLite + Raft”，会本能地把它理解成：这是不是把 SQLite 做成分布式数据库了？

是，但要小心这句话。

rqlite 不是 SQLite 的 drop-in replacement。它的 FAQ 写得很直白：访问数据库主要通过 HTTP API；它是为了 fault tolerance 和 high availability，不是为了把 SQLite 的写入性能变强。

这点很关键。

Raft 不是魔法加速器。写请求要经过 leader，要进入日志，要复制到节点。你得到的是一致性和故障切换，不是无限写吞吐。拿 rqlite 去替代一个高并发写入的业务主库，大概率是误用。

但它在另一类场景里很顺手：配置存储、小规模控制面、边缘集群、IoT 设备、内部系统状态。你不想为了几张关系表上一个沉重的分布式数据库，又不想单节点 SQLite 裸奔。rqlite 卡在这个中间地带。

它给后端选型提了一个问题：如果你真正需要的是“关系模型 + 容错 + 好部署”，是不是非得先搬出一套大数据库？

这也是 SQLite 文艺复兴里最容易被误读的部分。它不是把小数据库伪装成大数据库，而是在承认限制之后，把一个很具体的能力补上：节点坏了，服务还能继续。

LiteFS：好想法也会撞上维护现实

LiteFS 的路线更诱人。

它是 Fly.io / superfly 做的 FUSE-based SQLite replication。简单说，应用仍然面对一个 SQLite 文件，复制逻辑藏在文件系统层。这个想法对开发者太友好了：少改代码，甚至不改代码，就让 SQLite 文件跟着应用实例复制。

这类方案的吸引力不难理解。

你原本喜欢 SQLite 的简单，又想要跨机器复制；你不想把应用改成访问一个 HTTP 数据库，也不想放弃文件数据库的开发体验。LiteFS 试图把这两件事都留下来。

但它也给这波热潮泼了一盆冷水。

LiteFS Cloud 在 2024 年宣布关停，开源 LiteFS 本身没有被 sunset，GitHub 仓库也没有归档。维护者在 issue 里说项目处于 stable、working state，不是 abandoned，但开发资源已经转移，未来什么时候恢复没有时间表。

这句话比“项目死了”更值得认真看。

因为它说明 SQLite 复制并不是一个只靠技术巧思就能赢的题。文件系统层、故障恢复、主从切换、数据一致性、商业服务、用户支持、长期维护，每一项都会消耗真实资源。

很多基础设施项目最难的不是证明 demo 能跑，而是证明你愿意陪它跑很多年。

LiteFS 的价值不只在于它做过什么，也在于它提醒我们：当一个方案看起来“透明”“零改动”“兼得一切”时，先别急着鼓掌。透明的代价，通常会藏到运维、故障和维护资源里。

Turso / libSQL：本地读，远程写，不等于所有东西都本地优先

Turso/libSQL 是另一条更产品化的路线。

这里要先分清几个名字。libSQL 是 SQLite 的开源 fork，由 Turso 团队维护，加入了 embedded replicas、remote access 等能力。2026 年的 Turso database 已经和 libSQL 分成两个项目：Turso database 是 SQLite-compatible、用 Rust 从头重写的数据库，不是 SQLite fork。

这几个层次如果混在一起，文章看起来会很热闹，事实会很危险。

libSQL/Turso 最容易让后端开发者眼前一亮的，是 embedded replicas。

它的默认模式大概是这样：应用进程里有一个本地数据库文件，读请求从本地 replica 走；写请求默认发到远程 primary，再同步回本地。Turso 文档说得很明确：reads are always served from the local replica；writes are sent to the remote primary，默认不是先写本地文件。

这解决的是 Web 应用里很常见的读多写少问题。

如果 99% 的请求都在读配置、读页面数据、读权限信息，那每次都跨网络找远端主库，确实有点浪费。把读放回本地文件，延迟会漂亮很多，部署也更贴近边缘和多区域。

但这里也有一个容易被宣传词带偏的地方：embedded replicas 默认不是“所有写都本地完成，然后自由同步”。它更像“本地读 + 远程主写 + 同步回来”。如果你要的是真正 local-first writes、显式 push / pull，Turso 文档也把新项目引向 Turso Sync。

这不是坏事。

工程上最怕的不是方案有边界，而是你不知道边界在哪里。Turso/libSQL 有价值的地方，正是把 SQLite 的文件体验和云服务能力放到一个可消费的产品形态里；但你不能因为它叫 embedded replica，就把冲突解决、离线写、多端同步这些复杂问题当成已经自动消失。

DuckDB：它不是 SQLite 亲戚，但继承了同一种气质

DuckDB 经常被叫作 “SQLite for Analytics”。

这个说法好记，但也容易误导。DuckDB 不是 SQLite fork，它是独立的嵌入式 OLAP 数据库。SQLite 更像应用身边的事务账本，DuckDB 更像应用身边的分析引擎。

它的关键不是复制 SQLite，而是把“数据库就在进程里”这件事搬到了分析场景。

你可以直接查 CSV、Parquet、JSON，可以从本地文件或云数据源里跑 SQL，不一定先搭一个 ClickHouse、BigQuery 或数仓管道。Go 里也有 github.com/duckdb/duckdb-go/v2，走 database/sql 接口，对后端开发者很友好。

这件事的意义不在于 DuckDB 能替代所有 OLAP 系统。

真正有价值的是，它降低了“我只是想分析一批文件”的启动成本。很多内部工具、日志排查、运营报表、一次性数据分析，并不需要一上来就接入完整数仓。你需要的是把数据放在原地，马上能查。

DuckDB 放在这篇文章里，不是因为它属于 SQLite 生态，而是因为它证明了同一个工程审美正在扩散：不要所有数据问题都先变成远程服务问题。能嵌进应用、能贴近文件、能少部署一个东西，本身就是竞争力。

下次选型，先别问“能不能用 SQLite”

这个问题太粗。

更好的问法是：你到底想解决哪个问题？

所以 SQLite 文艺复兴最值得带走的判断，不是“以后都用 SQLite”。

那太蠢了。

真正值得带走的是：不要把数据库选型默认折叠成“玩具 SQLite vs 正经 Postgres”。中间已经长出了一片很大的工程地带：本地读、边缘复制、小集群高可用、按租户切文件、进程内分析。

这些场景以前也存在，只是我们经常用一套大数据库默认值把它们盖过去。

现在工具链把它们重新暴露出来了。

下次有人在评审会上提 SQLite，不要先笑。先问四个问题：写多还是读多？数据要不要跨节点一致？故障时能不能接受只读或短暂停顿？这份数据本质上属于一个全局服务，还是属于某个应用单元、租户、边缘实例？

问完这些，答案可能仍然是 Postgres。

但如果答案不是，你就不该因为“SQLite 看起来不够后端”而错过一个更简单的设计。

SQLite 没有突然变成万能数据库。它只是把一个老问题重新摆到后端开发者面前：有些数据，可能本来就不该离应用那么远。