系统与基础设施antonz.org
SQLite 不是玩具数据库
SQLite is not a toy database
2021 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章反驳“SQLite 只是玩具数据库”的成见，说明它是一个功能完整、可靠的嵌入式关系数据库，支持事务、完整 SQL、窗口函数等许多正式数据库特性，适合大量单机与嵌入式场景。作者同时强调 SQLite 的定位是嵌入式数据库，是否选用要看并发写入、高可用和运维需求，而不是简单地和服务器数据库比拼。
为什么经久不衰：它用具体能力清单纠正了对 SQLite 的低估，也提醒读者按场景选型；对今天大量单机应用、边缘部署和小型服务仍有参考价值。
HN 评论精选
SQLite 的真正短板不是并发性能，而是多客户端生产环境所需的高可用与管理能力；这是其嵌入式定位决定的。
开发者中流行一种说法，认为 SQLite 不适合 Web，因为它不支持并发访问。不对，问题在于它缺少高可用功能：故障转移、快照、并发备份等。（更正：有人指出它确实支持并发备份。）SQLite 不是玩具 DBMS，而是非常强大的嵌入式 DBMS。嵌入式 DBMS 面向单一用途客户端，适合桌面应用可靠存储用户数据。一旦有多个客户端并发开发运行，并且有生产数据（客户账户实际上必须始终保留的法律文件），你会希望 DBMS 是独立组件。关键不是并发性能，而是管理任务。这需要一种与 SQLite 嵌入式使命相悖的配置和控制水平。他们不会也不应该添加这类功能。
ben509查看英文原文
> There is a popular opinion among developers that SQLite is not suitable for the web, because it doesn’t support concurrent access. No, the issue is it doesn't have high availability features: failover, snapshots, concurrent backups, etc. (Edit: oops, comment pointed out it does have concurrent backups.) SQLite isn't a toy DBMS, it's an extremely capable embedded DBMS. An embedded DBMS is geared towards serving a single purpose-built client, which is great for a desktop application that wants a reliable way to store user data. Once you have multiple clients being developed and running concurrently, and you have production data (customer accounts that are effectively legal documents that must be preserved at all times) you want that DBMS to be an independent component. It's not principally about the concurrent performance, rather it's the administrative tasks. That requires a level of configuration and control that is contrary to the mission of SQLite to be embedded. They don't, and shouldn't, add that kind of functionality.
真实生产案例说明 SQLite 足以支撑不少业务系统，不应在盈利前过度工程化。
我建了一个复杂 CRM，每年处理 210 万美元交易，跑在 SQLite 上，加一个简单的内存 LRU 缓存（就是个 dict），执行变更查询（INSERT/UPDATE/DELETE）时清空。非常简单，速度也足够。友情提醒：在赚钱之前，别花时间微调 k8s 水平自动扩缩容。
michaelmcmillan查看英文原文
I've built a complex CRM that handles 2.1 million USD in transactions every year. It is running sqlite with a simple in-memory lru cache (just a dict) that gets purged when a mutating query (INSERT, UPDATE or DELETE) is executed. It is very simple and more than fast enough. Friendly reminder that you shouldn't spend time fine tuning your horizontal autoscaler in k8s before making money.
SQLite 的类型约束弱且写入锁全库，不适合高写入负载；它更像 fopen 的替代品而非服务器 RDBMS。
我对 SQLite 有两个主要不满：1. SQLite 并不真正强制列类型，这个选择让我很困惑，因为模式强制类型检查本是 SQL/关系数据库数据方案的强项。2. 写操作锁整个数据库，这让它不适合高写入场景，比如日志和指标记录。WAL 模式有帮助但只是缓解，最终你需要基于行锁的方案。正如官方 FAQ 所说，SQLite 竞争的是 fopen，而不是 RDBMS 系统。
doomleika查看英文原文
Two major gripe I had with SQlite 1. SQLite doesn't really enforce column types[0], the choice is really puzzling to me. Since schema enforced type check is one of the strong suit of SQL/RDMBS based data solution. 2. Whole database lock on write, this make it unsuitable to high write usages like logging and metric recording. WAL mode will help but it will only alleviate the issue, you will need row based lock solution eventually. Just like the offical FAQ said, SQLite competes with fopen[1] instead of RDBMS systems. -- [0]: https://sqlite.org/datatype3.html [1]: https://www.sqlite.org/whentouse.html
SQL 方言差异和迁移成本使 Postgres 在可预见扩展时更省心，低成本托管也降低了选择门槛。
它当然有很好的用例，也不是玩具，但有些关键 SQL 功能（比如 `last_at < NOW() - INTERVAL '10 minutes'`）与 SQLite 不容易兼容，而在 Postgres 中没问题；如果日后要向上扩展，需要大量重写代码。针对多个数据库测试很难，迁移到 Postgres 也不轻松。在 GCP 等平台托管小型 Postgres 每月约 8 美元……为什么不提前省去未来的痛苦？
latchkey查看英文原文
It certainly has some good use cases and is not a toy, but there are some critical SQL features (like say: `last_at < NOW() - INTERVAL '10 minutes'`) that are not easily compatible with SQLite and are with postgres, that would require a lot of code rewrite in case you need to scale upwards. Testing against multiple databases is hard, so migrating to postgres wouldn't be trivial either. Hosting small postgres databases on things like GCP are ~$8 a month... why not just save yourself from future pain?
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选