生产环境中的 SQLite：何时最简单的数据库才是正确的选择

发布: 1个月前 (2026年3月30日 GMT+8 08:18)

6 分钟阅读

原文: Dev.to

Source: Dev.to

（请提供您希望翻译的正文内容，我将为您翻译成简体中文。）

介绍

多年来，这条建议几乎是默认的：SQLite 适用于原型、移动应用和测试套件。如果你在构建任何真实的东西，就需要 PostgreSQL。这条建议在 2015 年还算合理，但在 2026 年越来越不对。

SQLite 为每部 iPhone、每台 Android 设备、每个 Firefox 和 Chrome 安装提供动力。该引擎每天处理的查询数量超过所有其他数据库引擎的总和。变化的不是 SQLite 的可靠性——而是其周边生态系统。

生产级工具

Litestream

Litestream 解决了 SQLite 在生产环境中最关键的缺口。Ben Johnson 的工具通过近实时流式传输 WAL 更改，将 SQLite 数据库持续复制到兼容 S3 的存储中。恢复点目标降至秒级。无需 cron 任务、pg_dump 窗口或备份间隔的担忧——只需一个 sidecar 二进制文件和一个存储桶策略。

LiteFS (Fly.io)

LiteFS 使用基于 FUSE 的文件系统在多个节点之间复制 SQLite。主节点负责写入；位于东京、伦敦或圣保罗的副本在本地提供读取。对于读密集型应用，相比集中式 Postgres 实例，延迟提升是可衡量且真实的。

libSQL / Turso

libSQL/Turso 分支添加了网络协议、原生复制原语以及无需重新编译的用户自定义函数。你可以保持嵌入式本地性能，同时获得通过 HTTP 访问数据库进行工具和管理的能力。

并发模型

最常见的关于 SQLite 的误解是它无法处理并发访问。在 WAL 模式——这应该是任何生产部署的默认模式——并发的读取永远不会阻塞写入，写入也永远不会阻塞读取。

真正的限制是 序列化写入：SQLite 一次只处理一个写事务。在现代 NVMe 存储上，这个单一写入者可以维持每秒数万次写事务。对于绝大多数 Web 应用（读取远多于写入，比例 10:1 或更高），这并不是瓶颈。

基本 WAL 配置

PRAGMA journal_mode = WAL;
PRAGMA busy_timeout = 5000;      -- milliseconds
PRAGMA synchronous = NORMAL;
PRAGMA cache_size = -64000;      -- ~64 MiB
PRAGMA foreign_keys = ON;

busy_timeout pragma 非常关键——如果没有它，并发写入尝试会立即返回 SQLITE_BUSY，而不是进行重试。

典型使用场景

读密集型单服务器应用

当数据集可以放入内存或快速 NVMe 时，每个查询都是本地函数调用。延迟从毫秒级降至微秒级。

边缘部署

在 Fly.io、Cloudflare Workers 或类似平台上的应用，从数据库与应用位于同一机器上受益巨大。

内部工具和仪表盘

为五人管理面板维护专用 Postgres 实例的运维成本难以令人信服。

有界数据量

如果你的 SaaS 工具每个租户最多产生几 GB 数据，SQLite 的理论上限（TB 级）并不相关。

何时选择 PostgreSQL

写入密集型事务工作负载（支付、库存），需要高并发写入吞吐量。
多服务器水平扩展，拥有大量写入者。
包含 CTE、窗口函数或高级分析的复杂查询。

选择并非意识形态驱动——而是基于工作负载的具体需求。

结论

WAL 模式改变了并发方程。默认的日志模式 SQLite 与 WAL‑mode SQLite 是有意义的不同工具；在生产环境中始终使用 WAL。

Litestream 解锁了持续备份和灾难恢复，解决了历史上“SQLite 还不适合生产” 的说法。将数据库与部署模型匹配：SQLite 在单服务器或边缘部署中表现出色，而真正的多写入水平扩展则需要 PostgreSQL。

阅读完整文章以获取详细的工作负载比较表、LiteFS 设置演练，以及对 SQLite 仍然不足之处的诚实评估。