SQLite 能不能当服务端数据库用

后台服务上线那阵子，有人看到我的数据存在一个本地文件里，问我这能扛住线上吗。SQLite 适合做服务端数据库吗，我的回答是：能，前提是你的服务只有一个实例，写入量也不高。超出这两条，它就不合适了。

一、两种负载下它完全是两个东西

| 维度 | 单实例 + 低写入 | 多实例 或 高写入 |

|---|---|---|

| 读写方式 | 进程内直接读文件，省掉一次网络往返 | 需要独立的数据库服务来协调 |

| 写入并发 | 排队即可，体感不明显 | 排队会变成可见的等待和报错 |

| 扩展方式 | 换台更强的机器就行 | 需要横向加机器，SQLite 给不了 |

| 故障影响 | 文件坏了服务就停，恢复靠备份 | 可以有多副本和主从 |

| 运维负担 | 基本没有 | 要管账号、连接、磁盘、版本 |

| 结论 | 可以用，而且是划算的 | 不该用 |

表里真正起决定作用的是第一列和第二列这两条：实例数，和写入并发。其他几行都是这两条的后果。

二、什么时候它确实能用

单实例部署、写入不密集的服务，用它是对的。

我自己的后台就是这种：一个进程，定期写日志，偶尔手动触发几个操作。这种负载下，SQLite 的写入排队根本感觉不到。

好处很实在：部署就是把文件带上，本地开一个测试环境也是把文件拷过来。省掉的是一整块运维工作，不是省掉一点性能。

还有一点常被忽略：进程内直接读文件，省掉了一次网络往返。在数据量不大、查询简单的情况下，这个差别是正的。所以「SQLite 一定比 MySQL 慢」这个说法并不成立，取决于场景。

三、什么时候它不该用

三种情况我建议直接换。

一是你要跑两个及以上实例，且它们共享数据。SQLite 没有网络协议，多个进程同时写同一个文件，冲突会一直跟着你。

二是写入持续密集，比如大量用户同时在提交。写入排队会变成实打实的接口等待。

三是数据丢失的代价很高、需要多副本。文件级备份能防误删，但给不了主从那种容错。

这几种情况下，用它是给自己埋问题。判断的时候别看单点指标，关键是问「写入会不会来自多个地方」，这一条几乎决定了一切。

四、SQLite 适合做服务端数据库吗，中间地带怎么判断

有一类情况不好判断：现在是单实例，但业务在涨。

我的做法是设一个明确的观察指标，而不是靠感觉。看报锁频率和写入耗时的趋势，按周对比。趋势在涨、优化手段用完了，就准备迁移。

迁移之前还有一步值得做：把数据访问收拢到一个接口层。做完这一步，换数据库就是换一层实现，而不是翻遍业务代码。

这一步的成本很低，但回报很确定。即使你最后没换，收口本身也让代码更好维护。

五、我的答案和我不改主意的条件

我现在还在用 SQLite，理由就是我的服务只有一个实例。

这不是因为它更好，是因为我的场景不需要服务端数据库提供的那些能力，而它带来的部署便利是立刻兑现的。

我也没打算一直用它。哪天我需要开第二个实例共享同一份数据，那天就是切换的日子。这不是件需要提前焦虑的事。

常见问题

Q：SQLite 能扛多少并发请求？

A：没有通用数字，取决于读写的比例和事务长度。别拿别人的数字做决策，先看自己的报锁频率和写入耗时趋势。

Q：用 SQLite 做服务端，数据丢了怎么办？

A：靠备份。它是单文件，备份和恢复都不复杂，但前提是你真的在做备份，并且验证过能还原。

Q：上线时用 SQLite，以后想换 MySQL 麻烦吗？

A：取决于你有没有把数据访问收口。收口了就是换一层实现；SQL 散落在业务代码里，就得挨个找。

相关阅读

• SQLite 和 MySQL 的区别，小项目怎么选
• SQLite 快撑不住时，会先出现这几条
• Go 里用 SQLite 最省事的写法
• SQLite 报 database is locked 怎么解决
• Go 里 channel 和 mutex 该用哪个

本文作者西米，37 岁程序员，一个人加五个 AI 员工在跑一家公司。踩过的坑和真实账本都写在公众号「西米分享」。