痛点：轻量应用的数据库选型困境
你有一个日活几千的内部工具、一个 side project、或者一个单节点部署的 API 服务。数据量不大，QPS 不高，但你依然被迫部署一套 PostgreSQL 或 MySQL —— 因为"SQLite 不能用于生产"这个根深蒂固的观念。
结果是：一个 RDS 实例每月 $30-60 的账单、额外的连接池管理、网络延迟、备份配置……这些复杂度对于一个本可以用 SQLite 搞定的场景来说，完全是过度工程。
核心矛盾：SQLite 性能够用、部署简单，但缺乏持续备份和灾难恢复能力。一旦磁盘故障或误操作，数据就没了。
方案：Litestream — SQLite 的流式复制引擎
Litestream 是一个独立运行的守护进程，通过监听 SQLite 的 WAL（Write-Ahead Log）文件变更，将增量数据实时流式复制到 S3、GCS、Azure Blob 或 SFTP 等远端存储。
核心设计理念：
- 零代码侵入 — 你的应用不需要做任何修改，Litestream 在 OS 层独立工作
- 秒级 RPO — WAL 变更实时同步，数据丢失窗口通常 < 1 秒
- 极简恢复 — 一条命令从远端还原完整数据库
- 成本趋近于零 — S3 存储 + 少量 PUT 请求，月费通常 < $0.10
实操步骤
第 1 步：安装 Litestream
# Debian/Ubuntu
wget https://github.com/benbjohnson/litestream/releases/download/v0.3.13/litestream-v0.3.13-linux-amd64.deb
sudo dpkg -i litestream-v0.3.13-linux-amd64.deb
# 验证安装
litestream version
# v0.3.13
或者使用 Docker：
docker pull litestream/litestream:0.3.13
第 2 步：配置复制目标
创建配置文件 /etc/litestream.yml：
dbs:
- path: /data/app.db
replicas:
- type: s3
bucket: my-backup-bucket
path: litestream/app.db
region: us-east-1
retention: 72h
sync-interval: 1s
关键参数说明：
| 参数 | 说明 | 推荐值 |
|---|---|---|
retention |
WAL 文件远端保留时长 | 24h-168h |
sync-interval |
同步检查间隔 | 1s（默认） |
snapshot-interval |
全量快照间隔 | 1h（默认） |
第 3 步：启动复制
方式 A：作为 systemd 服务运行
sudo systemctl enable litestream
sudo systemctl start litestream
# 查看复制状态
journalctl -u litestream -f
方式 B：包裹应用进程（推荐容器场景）
# Litestream 启动复制后再拉起你的应用，应用退出时优雅停止复制
litestream replicate -exec "python app.py" /data/app.db s3://my-backup-bucket/app.db
这种模式特别适合 Docker 容器，Dockerfile 示例：
FROM litestream/litestream:0.3.13 AS litestream
FROM python:3.12-slim
COPY --from=litestream /usr/local/bin/litestream /usr/local/bin/litestream
COPY litestream.yml /etc/litestream.yml
COPY app/ /app/
CMD ["litestream", "replicate", "-exec", "python /app/main.py"]
第 4 步：灾难恢复
数据库损坏或服务器丢失时，一条命令恢复：
# 从 S3 还原到本地路径
litestream restore -o /data/app.db s3://my-backup-bucket/app.db
# 还原到指定时间点（基于 WAL 重放）
litestream restore -o /data/app.db -timestamp "2026-06-15T00:00:00Z" s3://my-backup-bucket/app.db
恢复速度取决于数据库大小和 WAL 数量，100MB 以下的库通常 < 10 秒。
避坑指南
1. SQLite 必须使用 WAL 模式
Litestream 依赖 WAL 日志工作。确保数据库启用了 WAL 模式：
PRAGMA journal_mode=WAL;
如果你的应用使用 DELETE 模式（SQLite 默认），Litestream 无法正常复制。大多数现代 ORM（如 SQLAlchemy、Prisma）默认已启用 WAL。
2. 注意写并发限制
SQLite 的写锁是数据库级别的。如果你的场景是 读多写少（如配置中心、内容 CMS、内部工具），SQLite + Litestream 是最优解。但如果写 QPS > 100 且存在大量并发写事务，仍建议使用 PostgreSQL。
判断标准：单表写入 < 1000 次/秒 且无长事务 → SQLite 完全胜任。
3. S3 权限最小化
Litestream 只需要以下 S3 权限，不要给 s3:*：
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::my-backup-bucket",
"arn:aws:s3:::my-backup-bucket/*"
]
}]
}
适用场景速查
| 场景 | 是否适合 | 说明 |
|---|---|---|
| 内部工具 / Admin 面板 | ✅ | 低并发，SQLite 性能溢出 |
| 个人博客 / CMS | ✅ | 读多写少，极致简单 |
| IoT 数据采集 | ✅ | 单写入者，追加模式 |
| 高并发 SaaS API | ❌ | 写并发超出 SQLite 上限 |
| 多节点分布式应用 | ❌ | SQLite 不支持多节点写入 |
总结
Litestream 让 SQLite 从"开发用玩具"晋升为"生产可用的轻量级数据库方案"。对于大量单节点部署的中小型应用，它提供了一条极简路径：
- 省钱 — 砍掉 RDS/CloudSQL 账单，S3 存储成本忽略不计
- 省心 — 零代码修改，systemd 一拉即跑，RPO < 1 秒
- 省事 — 没有连接池、没有主从延迟、没有 vacuum 调优
一句话结论：如果你的应用写并发不高且单节点部署，SQLite + Litestream 是比托管数据库更优的选择。先跑起来，等真正需要 PostgreSQL 的那天再迁移也不迟。