「SQLite 只适合做原型」——这个印象已经过时很久了。
WAL 改变了一切
默认的回滚日志模式下，写操作会阻塞所有读操作。开启 WAL 后两者互不干扰：
PRAGMA journal_mode=WAL;
PRAGMA synchronous=NORMAL;
PRAGMA foreign_keys=ON;
对博客这种读多写少的场景，这几乎消除了唯一的性能瓶颈。
它真正的优势是运维成本
| 维度 | SQLite | MySQL / PostgreSQL |
|---|---|---|
| 部署 | 一个文件 | 独立进程 + 配置 + 账号 |
| 备份 | cp blog.db backup.db |
mysqldump / pg_dump |
| 网络延迟 | 零（同进程） | 每次查询一次往返 |
| 内存占用 | 几 MB | 数百 MB 起 |
一个日均几千 PV 的博客，数据量可能还不到 10 MB。为它单独跑一个数据库进程， 付出的复杂度远大于收益。
什么时候该换掉它
- 需要多台机器同时写同一份数据
- 单表数据量到了千万级且查询复杂
- 需要逻辑复制、在线 DDL 这类企业级能力
在此之前，SQLite 都是更划算的选择。