SQLite 上生产：这个博客就是这么跑的

上次在技术群说我博客生产环境用的 SQLite，好几个人以为我在开玩笑。没开玩笑——这个博客跑了半年，SQLite 稳得一批，还省了一台数据库服务器的钱。

这篇讲讲我对 SQLite 生产化的思考。

先破除偏见

"SQLite 是玩具数据库"的印象大概来自它的名字带个 Lite。实际数据：

SQLite 是世界上部署量最大的数据库（每台手机、每个浏览器里都有）
单文件、零配置、零进程，整个数据库就是一个 .db 文件
支持事务、外键、JSON 函数、全文搜索（FTS5）、CTE、窗口函数
官方测试用例覆盖率高达 100%（航空级质量标准）

它不是玩具，是嵌入式场景的王者。问题只在于适不适合你的场景。

什么时候 SQLite 完全够用

判断标准就两条：并发写入量和是否需要网络访问。

适合的场景：

个人博客、文档站、小型 CMS（读多写极少）
内部工具、管理后台（并发用户几十个封顶）
桌面应用、CLI 工具的本地存储
边缘计算/单机部署的小服务

我的博客：日 PV 几千，写入只有我发文章和评论审核，一天几次。这种负载用 MySQL 属于杀鸡用牛刀，还得养着牛的饲料钱。

什么时候千万别用

高并发写入：SQLite 写锁是库级的，同一时刻只能一个写事务。每秒几十次写入就开始排队
多机部署：应用要横向扩成多实例？SQLite 文件在一台机器上，多个实例没法共享
数据量巨大：官方说单库 TB 级也能跑，但备份、迁移、运维的成本会直线上升。几十 GB 以内比较舒适

生产化姿势

决定用了之后，几个关键配置让 SQLite 发挥真正实力。

1. 开 WAL 模式（必做）

PRAGMA journal_mode = WAL;

默认的 rollback journal 模式下读写互斥。WAL（Write-Ahead Logging）模式让读不阻塞写、写不阻塞读，并发能力质变。这是生产化的第一步。

2. 其他推荐的 PRAGMA

PRAGMA synchronous = NORMAL;   -- WAL 模式下足够安全，性能更好
PRAGMA foreign_keys = ON;      -- SQLite 默认不开外键约束，手动开
PRAGMA busy_timeout = 5000;    -- 遇到锁等待 5 秒而不是立刻报 SQLITE_BUSY
PRAGMA cache_size = -64000;    -- 64MB 缓存

用 Prisma 的话，在连接初始化后执行这些即可。

3. 备份 = 复制文件？没这么简单

不能直接在数据库被写入时 cp 文件（可能复制到半个事务）。两种方式：

# 方式一：sqlite3 命令行的在线备份
sqlite3 /data/blog.db ".backup '/backup/blog-$(date +%F).db'"

# 方式二：VACUUM INTO（还能顺便整理碎片）
sqlite3 /data/blog.db "VACUUM INTO '/backup/blog-$(date +%F).db'"

挂个 cron 每天跑一次，配合对象存储上传，备份方案齐活。一个文件的数据库，备份恢复都比 MySQL 简单一个数量级。

4. 升级和迁移

ORM 的 migration 工具（Prisma Migrate、Drizzle Kit）对 SQLite 一样好使。唯一注意：SQLite 的 ALTER TABLE 能力弱（改列类型基本靠重建表），ORM 会帮你处理，但大表重建时留意锁表时间。

和 Litestream / LiteFS 的组合拳

担心单文件的可靠性？社区的答案：

Litestream：持续把 WAL 变化流式备份到 S3，实现准实时灾备，RPO 秒级
LiteFS：基于 FUSE 的分布式 SQLite，多节点复制，让 SQLite 也能玩主从

我的博客目前 Litestream 定时备份到对象存储，成本一个月几分钱。rqlite（SQLite + Raft）则是另一个方向的探索。

真实体验总结

半年下来的感受：

部署爽：不用装数据库、不用管连接池配置，应用启动即就绪
速度快：同进程内直接读写文件，没有网络开销。简单查询的延迟比走 MySQL 还低
心智负担低：备份=复制文件，迁移=替换文件，本地开发直接把生产数据拉下来调试

当然也有局限：哪天博客火了、评论并发写入上来了，我会第一时间迁 MySQL。但那一天到来之前，SQLite 就是这个场景的最优解。

小结

SQLite 不是玩具，是嵌入式王者：事务、JSON、全文搜索都有
适用判断：读多写少、单机部署、几十 GB 以内
生产三件套：WAL 模式、busy_timeout、定时 .backup
高并发写入、多实例部署的场景才需要 MySQL/PostgreSQL
Litestream 提供准实时灾备，成本约等于零

技术选型没有鄙视链，只有合不合适。对小流量应用来说，"不上 MySQL"恰恰是对架构复杂度的尊重。