SQLite 用于生产环境：Julia Evans 在实际运行后的学习心得

朱莉娅·埃文斯发布了她关于SQLite的笔记：没有什么惊天动地的内容，但对那些犹豫是否要在小文件上运行真正应用程序的人来说，这些笔记非常实用。

具体案例

Julia Evans（其 zines 和文章培养了一代开发者对 Linux、HTTP、DNS 内部机制的理解）于 2026 年 7 月 17 日在其博客 jvns.ca 上发布了一篇题为《Learning a few things about running SQLite》的文章。这既不是入门教程，也不是宗教式的宣传：而是一位将 SQLite 投入生产环境运行的开发者的实地笔记，记录了令她惊讶的发现。读来令人愉悦。

文章内容

我们不会剧透这篇文章——去读原文吧，它虽短但用英文写成——但 SQLite 在生产环境中常见的讨论话题反复出现，值得在此为好奇的读者们回顾：

1. WAL 模式：并发必备

默认情况下，SQLite 使用 DELETE 日志模式，其中写操作会阻塞读操作。而在 WAL（Write-Ahead Logging）模式下，读操作不再阻塞写操作，反之亦然：

PRAGMA journal_mode = WAL;
PRAGMA synchronous = NORMAL;

synchronous = NORMAL（而非 FULL）在发生突然断电时最多仅丢失最后一笔事务，但换来的是性能的大幅提升。这正是 Litestream 及大多数现代 SQLite 服务器所采用的配置。

2. 单写多读：一写多读模式

与 PostgreSQL 不同，SQLite 不支持并行写入。一种常见的 Rust 或 Go 模式是：保留一条连接专用于写入，另用连接池处理读取。例如 Rust 的 rusqlite crate 结合 deadpool-sqlite 实现此分离，或 Go 的 mattn/go-sqlite3 库通过 sql.DB 配置 SetMaxOpenConns(1) 限制写入连接数。

3. 实时备份：Litestream 或 LiteFS

在事务进行时通过“复制文件”的方式备份 SQLite，只会得到损坏的备份。目前有两大工具：

• Litestream（作者 Ben Johnson，也是 BoltDB 的作者）：持续流式复制至 S3、Backblaze B2 或 GCS。WAL 流式传输，恢复快速。
• LiteFS（同一作者，现已加入 Fly.io）：进一步支持多节点复制，可从任意副本读取数据。

4. 2026 年 SQLite 的真实上限

只要开启 WAL 模式并做好索引，SQLite 能轻松应对 每秒数万次请求，单文件即可胜任。真正的瓶颈不在 SQL 本身，而在磁盘：NVMe 本地盘 >> 网络盘，EBS gp3 >> EFS。许多 SQLite 在生产环境中的失败，源于将数据库文件放在网络共享（如 NFS——SQLite 在其文档 sqlite.org/faq.html#q5 中明确不建议这样做）。

关键点

Julia Evans 的观点一贯如此：尝试、测量、记录发现。没有“SQLite 可扩展”这种口号，也没有“你需要 PostgreSQL 来做任何正经事”。只有：“这个行为让我惊讶，原因在此，我做了哪些调整。”

对于任何对单服务器应用或个人项目是否该动用重型关系数据库犹豫不决的开发者，这类文章比一百个合成基准测试更有价值。