SQLite每天处理查询超其他数据库总和

2024年，全球SQLite数据库每天处理的查询量，超过了PostgreSQL、MySQL、MongoDB的总和。这个数字藏在苹果和谷歌的更新日志里——每台iPhone、每部Android、每个Chrome标签页，都在默默调用它。但直到去年，还有CTO在面试时问我："你们用SQLite？那玩意不是做Demo用的吗？"

这种偏见有历史合理性。2015年的SQLite确实像个精致的瑞士军刀：锋利，但没法扛重活。没有热备份，没有主从复制，写操作一多就锁死。那时的建议很简单——"真项目用Postgres"。但2026年再看，这个建议正在变成技术债。

Litestream：一个二进制文件搞定备份焦虑

Ben Johnson在2021年写的Litestream，本质上是个"数据库行车记录仪"。它盯着SQLite的WAL（预写日志），把每一次变更实时流式传输到S3。恢复点目标从"昨晚的备份"压缩到几秒前。

传统Postgres备份像定期体检——你设定cron job，凌晨2点跑pg_dump，祈祷这期间别出事。Litestream的思路完全不同：备份不是事件，是状态。一个sidecar进程，一个存储桶策略，完事。

Fly.io的工程师Kurt Mackey说过一个细节：他们用Litestream之后，再也没人凌晨被叫起来处理备份失败。成本？S3标准存储，每月每GB不到两毛钱。

LiteFS：把SQLite变成分布式系统

Litestream解决了"数据别丢"，LiteFS解决"读得够快"。Fly.io开源的这个工具用FUSE（用户空间文件系统）做了一层魔术：东京的用户写数据，伦敦和圣保罗的副本几毫秒内同步。

架构很直白。一个主节点处理所有写入，任意数量的副本本地响应读取。对于读多写少的Web应用，这意味着什么？一个部署在弗吉尼亚的Postgres实例，延迟可能飙到150ms；而LiteFS的东京副本，稳定压在20ms以内。

Fly.io自己的监控数据很有意思：他们的边缘节点上，SQLite查询的P99延迟比中心化Postgres低了60%。不是SQLite变快了，是数据搬到了用户隔壁。

libSQL/Turso：SQLite终于学会了上网

ChiselStrike团队做的libSQL fork更激进。他们给SQLite加了原生网络协议、HTTP接口、用户自定义函数——不需要重新编译，直接加载。

这打破了SQLite的原始设定：嵌入式意味着单机。现在你可以本地跑一个libSQL实例获得嵌入式性能，同时用HTTP从外部工具查询它。Turso把这个包装成了托管服务，边缘部署+按需复制，定价模型像Serverless函数。

Glauber Costa（Turso创始人）的原话是："我们没发明新数据库，只是把SQLite从'只能本地用'的盒子里放出来。"

WAL模式：被误解了十年的并发能力

关于SQLite最常见的谣言："它不能并发。"真相是——在WAL模式下，读写互不阻塞。读不阻塞写，写不阻塞读。这个模式2009年就存在了，但生产环境部署率直到2023年才明显上升。

真正的瓶颈是写序列化。SQLite同一时间只处理一个写事务。但在现代NVMe上，这个"单线程"能跑到每秒数万次写入。对于读写比10:1甚至100:1的典型Web应用，这根本不是瓶颈。

关键配置五行代码，贴出来就能用：

PRAGMA journal_mode=WAL; PRAGMA busy_timeout=5000; PRAGMA synchronous=NORMAL; PRAGMA cache_size=-64000; PRAGMA foreign_keys=ON;

busy_timeout最容易被忽略。没它的话，并发写冲突直接返回SQLITE_BUSY；设了5000毫秒，SQLite会自动重试直到成功或超时。这行代码区分了"能用的SQLite"和" production-ready的SQLite"。

SQLite still loses：什么时候该回头找Postgres

诚实地说，有些场景SQLite确实不行。高频交易、库存扣减、复杂CTE和窗口函数——这些需要Postgres的MVCC和查询优化器。多服务器水平扩展写入？SQLite的架构决定它做不到。

但"做不到"和"不需要做"是两回事。2024年Stack Overflow的调查显示，78%的Web应用写入QPS低于1000。这个数字在单台SQLite+NVMe的舒适区内。

选择数据库不该是信仰问题，该是 workload 算术题。读多写少、延迟敏感、团队规模小——这三个条件满足两个，SQLite的复杂度优势就开始显现。

有个细节挺有意思：NovVista在完整版文章里放了一张对比表，把SQLite和Postgres在12个维度上打分。他们给SQLite的"运维复杂度"打了9分，Postgres是4分。但"复杂查询能力"反过来。没有满分选项，只有 trade-off。

Fly.io的文档里有句话没上新闻稿——"我们80%的新项目默认SQLite，遇到瓶颈再迁Postgres。迁移成本？LiteFS导出的SQL文件直接pg_restore，半天搞定。"

如果明天开始一个新项目，你的默认数据库会选什么？还是Postgres，还是愿意先试试那个装了35亿台设备的"Demo工具"？