在 Dr. Raphael A. Bauer 发表《PostgreSQL for Everything》之后，JoeCode 发表了一篇《SQLite for Everything》调侃式回应（作者强调自己同样喜欢 PostgreSQL，但认为 SQLite 被严重低估）。
参考：PostgreSQL 适用一切场景
作者的核心观点：很多团队为了"看起来像生产系统"而引入的一整排基础设施（搜索、队列、缓存、向量库、图库、微服务……），在大多数项目里其实一个 SQLite 单文件就能顶替。
开发新项目的时候，先判断"它能跑在单机+单文件上吗"——能就先上 SQLite，真撞到写并发或分布式天花板再换重的。大多数业务比开发者以为的更晚才会撞墙，而期间你省掉的是大量运维工作。
SQLite 三大底层优势
- 坚如磐石：2000 年发布，公有领域（public domain，不是普通开源），MC/DC 100% 分支覆盖、测试代码是库代码的约 500 倍，官方支持承诺到 2050 年；手机/浏览器/汽车/飞机里都在跑，部署量超过其他数据库总和。
- 零运行成本：没有 daemon、没有端口、没有 Docker。已绑定在 Linux/Python/Go/Rust/.NET/Android/iOS 里；测试用
:memory:微秒级拉起，和生产同库同二进制。 - 极大简化 IT 拓扑：它不止是 RDBMS，还能当全文搜索引擎、文档库、队列、时序库、向量索引、缓存、文件格式、图存储——"少装一个服务"就是少一个要监控/升级/背锅的系统。
"SQLite 替代 X" 对照表
| 原本的组件 | SQLite 怎么顶 | 关键机制 |
|---|---|---|
| Solr / Elastic | 全文搜索 | FTS5（BM25、短语、NEAR、高亮），索引与数据同事务，不会"索引是旧的" |
| MongoDB | JSON 文档存 | jsonb、生成列、严格表 |
| Kafka / RabbitMQ | 任务队列 | 一张表 + BEGIN IMMEDIATE + UPDATE…RETURNING 抢单条作业，WAL 下读写不互锁 |
| ClickHouse | 时序数据 | 按时间分区单文件，中等体量够用 |
| 向量数据库 | AI 检索 | sqlite-vec 扩展做 embedding 相似度 |
| Redis | 非持久/高性能缓存 | 进程内点查 ~1µs，比 localhost 跑 Redis 的 ~100µs 快约 100 倍 |
| 文件系统 | 存小文件/BLOB | 官方基准：<100KB blob 比裸文件系统更快、省空间 |
| 图数据库 | 关系遍历 | 递归 CTE |
| 微服务 | 跨函数调用 | 直接同进程函数调用 + 本地事务 |
| （彩蛋）PlayStation 5 | — | 纯玩笑章节 |
SQLite 的天花板
- 不支持并发写入：高并发写入（每秒几万条以上）会卡在写锁；多机多写、跨机房分布式写不适合原生 SQLite。
- 规模边界：超 TB 级数据、百万点/秒时序、需要用户/角色级 ACL 的多租户 SaaS，应换 Postgres/MySQL/ClickHouse 等。
- 扩展方案：Litestream（WAL 流式备份到 S3）、LiteFS（分布式读）、Turso / Cloudflare D1 / rqlite（托管 SQLite）可缓解部分限制，但不改变单写本质。
