SQLite 到底够不够用
在单机、单进程、读多写少的场景里，答案几乎总是「够」。
很多人一听 SQLite 就皱眉，觉得那是「玩具数据库」。但对于一个博客，它可能是最正确的选择。
它省掉的不只是一个进程
一个 PostgreSQL 实例空闲时也要占 30–50 MB 常驻内存，再算上连接池和容器开销，很容易翻倍。SQLite 是库，不是服务：
import sqlite3
conn = sqlite3.connect("blog.sqlite3")
conn.row_factory = sqlite3.Row
conn.execute("PRAGMA journal_mode = WAL")
conn.execute("PRAGMA synchronous = NORMAL")
conn.execute("PRAGMA busy_timeout = 15000")
四行 pragma，就得到了：读写并发不互相阻塞、崩溃安全、锁等待有上限。
WAL 模式是关键的开关
默认的 rollback journal 模式下，写操作会阻塞读。开启 WAL 之后：
| 模式 | 读并发 | 写并发 | 适用 |
|---|---|---|---|
| rollback journal | 阻塞 | 单写 | 极少读 |
| WAL | 不阻塞 | 单写 | 读多写少 ✅ |
博客正是典型的读多写少。
什么时候该换掉它
诚实地说，下面这些情况下 SQLite 会开始难受：
- 需要多台机器同时写同一个库；
- 写入 QPS 长期超过几百；
- 需要细粒度的行级权限。
一个博客一条都不占。
数据库选型的第一问不是「哪个更强」，而是「哪个刚好」。