开发 · 文章
把 [blocked] SQLite 当主数据库的团队,运维成本接近零
九成内部系统不需要 Postgres 集群,需要一个文件加一条备份策略。SQLite 的测试规模、向后兼容承诺和 Litestream 等备份生态,已经足够支撑生产环境;单写者模型反而是它被低估的原因。
SQLite 以 GB 级测试套件验证,官方承诺文件格式兼容性维持到 2050 年WAL 模式下读写不再互相阻塞,普通硬件上读吞吐可达每秒数十万次Litestream 把 WAL 实时流到对象存储,恢复点缩小到秒级,成本只是一台热备机的零头
观点先说:九成内部系统不需要 Postgres 集群,需要一个文件加一条备份策略。SQLite 常被当成「玩具」或「嵌入式专用」,但它的测试套件规模以 GB 计,官方承诺兼容性维持到 2050 年——这不是玩具的履历,是基础设施的履历。 能力边界要先讲清楚。SQLite 是单写者模型:同一时刻只有一个写入者,写操作之间互斥;但配合 WAL 模式,读写不再互相阻塞,读并发吞吐在普通硬件上可达每秒数十万次。对写并发低、读放大的典型业务系统——后台、报表、内部工具——这个模型恰好够用。 生态已经把分布式这块短板补上:Litestream 持续把 WAL 流式推到对象存储,恢复点缩小到秒级;LiteFS 和 rqlite 提供只读副本与共识复制;Turso(libSQL)把 SQLite 做成了托管服务;分析负载可以交给 DuckDB 读同一批文件。围绕一个文件的运维面,确实可以做到接近零。 什么时候别用:多实例同时写入、多区域双向写、重度依赖自定义类型或扩展的场景,老实用 Postgres。判断标准很简单——如果写入方只有一台机器,SQLite 值得进入你的默认选型清单。