单文件搞定社交网：SQLite 就是全部
SQLite Is All You Need
上周读了 Evan Hahn 关于 SQLite 的文章后，我决定验证它的极限。我们构建了一个名为 Chirp 的社交网络，将 5 万用户和 100 万帖子塞进一个 343MB 的 SQLite 文件中。整个后端仅由一个 Node 进程支撑，没有数据库服务器，也没有容器。在 Apple M1 笔记本上，开启 WAL 模式后，最复杂的动态流页面竟能支撑每天 3.15 亿次请求。测试表明，只要配置得当，SQLite 足以应对绝大多数场景，那些出于习惯而启动的 Postgres 容器可能根本不需要。当然，我们也诚实地列出了它的局限：单写锁机制和缺乏自动故障转移。但对于大多数产品而言，这种极简架构带来的运维优势远超其理论上的扩展瓶颈。
"对于你正在构建的几乎所有东西，开启 WAL 模式的 SQLite 都绰绰有余，而你出于习惯启动的那个 Postgres 容器其实从未真正需要过。"
HN 评论区
- 在分布式文件系统中使用 SQLite 会遭遇严重的文件系统竞态条件，导致生产环境不得不紧急迁移至 MySQL。
- 直接复制文件备份 SQLite 存在数据损坏风险，官方文档明确指出在写入事务期间使用 cp 命令可能导致备份不一致，应使用 VACUUM INTO 确保原子性。
- SQLite 的写入锁机制在多进程高并发场景下性能极差，尽管支持多进程访问，但全文件锁定使其难以应对真正的写密集型负载。
- SQLite 作为嵌入式数据库的设计初衷决定了其缺乏原生 datetime 类型，这是为了保持对象轻量，而非架构缺陷。
- 对于需要高可用性和多节点部署的场景，Postgres 等成熟客户端/服务器数据库的复制方案比 SQLite 的 WAL 同步方案更可靠且经过充分验证。