SQLite 作为唯一数据库 - 生产调优指南

用简单的语言来说。 一篇新的工程帖文认为，如果配置得当，SQLite——嵌入在您的应用程序中的嵌入式数据库——可以承担真实的生产负载。它介绍了将玩具默认值转变为低延迟服务器后端的pragmas、日志记录模式和虚拟文件系统层。

上下文

该帖文——《SQLite生产环境：优化WAL模式、并发性和VFS层以实现低延迟应用服务器》（micrologics.org，2026年7月29日）——读起来像是实践者的蓝图。它针对的是那些习惯性选择Postgres的团队，并想问问数据库的网络跳转是否曾经是最便宜的部分。

幕后

三个杠杆做了大部分工作：

WAL模式。PRAGMA journal_mode=WAL; 用单独的-wal文件替换了回滚日志。读者和写入者不再在页面缓存上相互阻塞；只有写入者仍然串行化。但是：如果不加以注意，WAL文件会增长。您需要一个检查点策略——PRAGMA wal_autocheckpoint，或者从应用程序中显式调用PASSIVE/FULL/RESTART/TRUNCATE。

竞争形状。 SQLite是一个单写入引擎。该帖文的基线是：PRAGMA busy_timeout = 5000; 用于自动重试，以及任何计划写入的事务的BEGIN IMMEDIATE;——避免了两个BEGIN竞争时的经典升级死锁。

内存。PRAGMA cache_size = -64000;（64 MB）和PRAGMA mmap_size = 1073741824;（1 GB）将大多数读取转变为指针算术。

分析

该帖文值得一读的不是pragmas——那些都是旧新闻。而是框架：SQLite的VFS是改变架构的扩展点。Litestream（异步复制到S3）和LiteFS（基于FUSE的分布式层）在不触及查询代码的情况下，将本地文件假设转变为能够容忍网络的假设。在短暂的云磁盘上，VFS层是您实际上设计的对象，而不是pragmas。

帖文所拥有的权衡

显式限制：多太字节数据集、地理分布式写入、需要真正MVCC的工作负载，跨多个写入者。在这些天花板以下，该帖文认为操作表面比托管的Postgres要小——并且p99延迟是内存复制，而不是套接字往返。

所以呢

对于构建AI时代后端的团队，其中“数据库”通常是每个租户的blob，热路径是1-5 ms，问题不再是为什么在生产环境中使用SQLite，而是使用哪个VFS。该帖文最好被视为您粘贴在main.go旁边的检查表——而不是承诺您可以退休您的集群。