系统与基础设施beets.io
我们对 SQLite 很满意，不急于换更花哨的数据库
We’re pretty happy with SQLite and not urgently interested in a fancier DBMS
2016 — 2018，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
beets（音乐库管理工具）团队撰文解释为什么他们坚持使用 SQLite 而不急于换用更“高级”的数据库：数据量小、读多写少、零配置、易于嵌入，SQLite 完全够用。文章强调优化查询比更换数据库更能带来实际性能提升。
为什么经久不衰：它是对“换数据库就能解决性能问题”这一惯性思维的清醒反驳，多年后仍是评估是否需要引入重型数据库时的经典参考。
HN 评论精选
换数据库常是 cargo cult 式的迷信，小数据集下 SQLite 反而更快
我总惊讶于人们会轻易得出“换用 MySQL 就会更快”这类站不住脚的结论。见过太多邮件服务器为了“性能”把用户数据放进 MySQL，却没意识到 /etc/passwd 和 Postfix 自带的查找文件本来就完全在内存里，加一层 MySQL 反而慢了几个数量级。一知半解是危险的：MySQL“快”不代表它适合所有场景。SQLite 在小数据集上极快，数据小意味着更多内容能放进内存，我想不出这个场景下 MySQL 怎么可能更快。
SwellJoe查看英文原文
I never stop being impressed at how often people will jump to odd, unsupportable, conclusions like, "using MySQL will make this thing faster". I've seen it so many times over the years regarding users and email configurations. I can't count the number of times I've dropped into someone's badly behaving mail configuration and found they had MySQL hosting the users, and explained it was for "performance" reasons. Somehow they didn't grasp that /etc/passwd fits entirely in memory, and the map files Postfix uses for various lookups and stuff are already a database (just one specifically designed for the task at hand) and also fit entirely in memory. Putting that MySQL layer in there is disastrous if performance matters; it is orders of magnitude slower for any case I've seen...still plenty fast for most cases, but it's ridiculous that this idea gets cargo-culted around that if you store your mail users in MySQL your mail server will be faster. A little knowledge is a dangerous thing, is what I'm trying to say, and people who know MySQL is "fast" may not know enough to know that it's not the right tool for the job in a lot of cases...and is probably slower for many use cases. I'm pretty confident this is one of those cases. SQLite is wicked fast on small data sets, and being smaller means more of it will fit in memory; I can't think of any way MySQL could be a more performant choice for this workload. Also, I don't even want to try to imagine shipping an installable desktop application for non-technical users that relies on MySQL!
称赞作者基于实际需求而非流行趋势做技术选型
这篇文章让人耳目一新，因为作者展现了常识：为场景选最合适的工具、写少读多、零配置、易嵌入，并明白优化查询才是性价比最高的性能手段。我自己也在 Bacula 和 Postfix 上用 SQLite，体验很好；回头看 PowerDNS 用 SQLite 会比 Oracle 更合适。很高兴看到有人基于正确理由而非流行趋势做技术选型。
Annatar查看英文原文
Wow, the article is such a fresh breath of air, primarily because the author demonstrates common sense. He (they?) picked SQLite for all the correct reasons: - best tool for the job for their situation; - write-light and read-heavy; - zero configuration; - easy to embed; - understanding that optimizing queries by far gives the best performance in the shortest amount of time. As an aside, I'm currently using SQLite for Bacula and Postfix, and it's a joy to use; the only drawback I found so far is lack of REGEXP REPLACE in the SQL dialect which the database supports (must be loaded with .load /path/to/lib/libpcre.so, but it is not part of the language). I used the Oracle RDBMS for my PowerDNS deployments, but in retrospect, the way PowerDNS works, SQLite would have been an even better match. All in all, it is great to read that someone picked it for all the correct reasons, rather than some fashion trend, as is often the case in computer industry.
数据量达到数百万条时 SQLite 性能会急剧下降，大场景应预防性选型
过早优化是恶，但预防性优化是必要的，否则会把自己逼进死角。我在实现比特币全节点时，把区块链分别存进 SQLite、Postgres 和 LevelDB 做了基准测试：LevelDB 上 300-400ms 的查询，Postgres 要 1.6 秒，SQLite 要超过 30 秒。数据达到几百万条记录后 SQLite 慢得惊人。如果预期数据超过 50 万到 100 万条，我会建议作者考虑换 Postgres，或者试试用 LMDB 做后端的 SQLightning。
chjj查看英文原文
Premature optimization is evil, but preemptive optimization is necessary unless you want to paint yourself into a corner. I realized this after implementing a bitcoin full node. In my bitcoin implementation, as an experiment, I tried storing the blockchain in sqlite, postgres, and leveldb. I gathered up a bunch of data from the first ~200k blocks of the blockchain and benchmarked all three databases. I queried for something like 30,000 utxos out of a set of a couple million. What took 300-400ms in leveldb took 1.6 seconds in postgres (on the repl. in my actual node it would have taken longer due to deserialization of the utxos). What took 1.6 seconds in postgres took over 30 seconds in SQlite. Now, you can tell me I did the benchmarks wrong, and "oh, if you just did this it would be faster!", but 30+ seconds is slower to an absolutely insane level. Needless to say, I went the key-value store route, but I was still astounded at how slow sqlite was once it got a few million records in the database. I actually like sqlite, but when you know you're going to be dealing with 70gb of data and over 10 million records, preemptive optimization is the key. If I were the author, I would consider switching to postgres if there are over 500k-1m records to be expected. That being said, if they're partial to sqlite, SQLightning (https://github.com/LMDB/sqlightning) looks pretty interesting (SQLite with an LMDB backend). edit: To clarify, these weren't particularly scientific benchmarks. This was me timing a very specific query to get an idea of the level of data management I was up against. Don't take my word for it.
SQLite 把运维成本降到几乎为零，不够用再升级也不迟
我们在一个约 1000 活跃用户的应用里用 SQLite：备份、种子数据和测试夹具都是“cp”搞定，配置、安全、部署脚本、监控全部为零工作量，故障切换只需 rsync。我以前的项目光是把这些“做对”就至少要花 100 小时。真不够用了再迁去 RDS 也不迟。
batmansmk查看英文原文
We use SQLite in an app with about 1,000 active users. It took us: - 0h to manage backups ("cp"), - 0h to manage seeds and tests fixtures ("cp"), - 0h to configure and secure (void), - 0h to write the deployment scripts (void), - 0h monitoring/watchdog jobs (void), - 1h to rsync for failover ("rsync") My last projects always spent at least a good 100h to do all of this the right way. Then, if it is not good enough, we'll move to RDS or equivalent.
历次讨论
同类还值得读
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编辑精选