2026年7月11日，一个叫Lobsters的网站做了一件听起来反直觉的事：他们把运行了十多年的付费数据库系统（一套叫MariaDB的商业软件，需要单独租一台服务器来跑），换成了一个完全免费的数据库——SQLite。你可以把后者理解成一种「文件型」数据库：不需要单独的服务器，不产生额外的账单，几行代码就能跑。
两天后的周一早晨，网站的维护者之一在站内发帖说：CPU使用率降了，内存占用降了，页面加载更流畅了。最关键的一句：「等MariaDB那台服务器彻底下架，每月的VPS费用直接减半。」
在程序员圈子里，这条帖子炸了。384个赞，92条评论。不是因为技术有多炫酷——恰好相反，是因为这件事太朴素了。
一场持续七年的数据库纠结
在讲这次迁移之前，先简单说一下Lobsters是什么。它是一个程序员用的「链接分享+讨论」网站，类似一个更安静、更硬核的Hacker News。用户在上面分享技术文章，其他人投票、评论。网站不大——数据库文件大约500MB，日常流量一个普通服务器就能应付——但它已经稳定运行了十多年。
问题出在它用的数据库上。早年间，Lobsters选择了MariaDB——一套需要独立服务器来运行的商业数据库系统。随着时间推移，团队逐渐觉得这套方案太重了：多一台服务器意味着多一份月度账单，多一个需要维护的潜在故障点。2018年8月，主要维护者pushcx在GitHub上开了一个讨论帖，标题是「讨论迁移到PostgreSQL」——另一个付费数据库。
讨论贴躺了七年，方向从PostgreSQL飘到了SQLite。真正的转折出现在2025年初：投资集团K1收购了MariaDB，这让社区对MariaDB的长期前景产生了疑虑。同时，一位叫Rahul的社区成员在讨论串里问了一句：「Lobsters能在SQLite上跑吗？」
SQLite是什么？一句话：一个把所有数据存在本地文件里的免费数据库。不需要安装、不需要配置、不需要单独的服务器。它被内置在Chrome浏览器里、微信里、你手机上的每一个App里——是世界上装机量最大的数据库引擎。但在很长一段时间里，它被默认认为「不适合网站」，因为它的设计和传统的需要独立服务器的数据库系统（MariaDB、PostgreSQL、MySQL）思路不同。
Rahul的那一问，把这个默认假设推翻了。
第一次迁移：CPU飙到100%，紧急回滚
2025年6月，一位叫thomas0的社区贡献者正式接手了迁移工作。他在帖子里记录了一段罕见的坦诚自述：整个过程经历了三次代码提交尝试、一次失败的上线、然后修正三个问题后才最终成功。
第一次上线发生在2026年2月21日。thomas0和pushcx通了一个电话，制定了详细的部署清单，一切按计划推进——直到新代码上线那一刻。站点进入了只读模式（一种保护措施，防止数据被写坏），但仅仅是处理用户的浏览请求，服务器的所有CPU就被打到了100%。卡死了。两个人排查了半天，找不到原因。最终决定：回滚。
thomas0在帖子里写道：「那次失败后我感觉不太好。」因为他在事前就知道，由于没有生产数据库的访问权限，性能问题可能是个隐患——但他的猜测被证实了。
事后复盘，问题出在三处。其中两处，是SQLite对数据库里最大的两张表执行了「全表扫描」——就像在图书馆里找一本书，从第一排书架开始一本一本翻过去，不走目录查编号。数据量小的时候没事，数据量大了，每次有人打开网页，服务器就得把整张表从头到尾读一遍，CPU直接拉满。第三处是一种叫「N+1查询」的低效模式：每次查一条数据，程序又额外多发N条查询。正确做法是一次性把需要的数据全拉出来。
三处问题，两处在SQL的写法上，一处在程序的逻辑上。都不是SQLite本身的缺陷——是两种不同数据库系统之间，同样的代码会产生截然不同的执行效率。
第二次迁移：一个安静的周一早晨
2月21日回滚之后，thomas0只用了两天就提交了第三次修改。他做了什么？
首先，修复了第一次上线时发现的两个全表扫描问题：给查询语句加了合适的索引——相当于给那几张「大表」建了一个快速查找的目录。对于熟悉数据库的人来说，这是基本功；但对于迁移场景来说，关键点在于：原来在MariaDB上，这些查询可能走了不同的执行路径，所以从来没有暴露过性能问题。换到SQLite之后，同样的查询语句，SQLite选择了另一种执行策略——扫全表。数据库一换，原来的「好代码」变成了「坏代码」。
其次，修复了N+1查询：把循环查询改成了批量查询。程序不再一条一条地问数据库，而是一次性把需要的数据全捞出来。
第三，他花了一周时间，用自己写的脚本在本地生成了一半Lobsters真实数据量的测试数据——因为没法拿到真实的生产数据，只能用这种方式模拟流量。这个脚本本身就是一个额外的工程量。
第四，为了保险，他在上线前加了一个「慢查询日志」开关：万一还有没发现的性能问题，系统会自动记录执行时间超过100毫秒的查询，方便快速定位。
2026年7月11日，第二次上线。这次结局不同了。站点保持正常运行，CPU和内存曲线平稳。他们在聊天频道里盯着用户反馈，处理了两个小问题，然后就等待周一——流量高峰的真正考验。
周一上午，一切平静。pushcx在内部聊天里说了一句：「我们过了一个安静的周一。」
为什么一个「更简单」的数据库反而更好？
这个故事的反直觉之处在这里：SQLite比MariaDB「简陋」得多——它没有用户权限系统、不支持同时大量写入、不能通过网络远程访问、很多高级查询语法也不支持。但Lobsters换上去之后，一切反而更好了。
原因有三层。
**第一层：少一台服务器，少一堆麻烦。**在原来的架构里，Lobsters的网站程序跑在一台服务器上，MariaDB数据库跑在另一台服务器上。两台机器之间需要网络通信，需要分别维护、分别备份、分别监控。SQLite把数据库变成了网站程序内部的一个文件——数据存在同一台机器上，备份就是复制一个文件。对Lobsters这种「一台服务器就能撑住所有流量」的网站来说，独立的数据库服务器不是资产，是负债。
**第二层：去除延迟。**每次用户打开一个页面，网站程序需要查询数据库。在MariaDB架构里，这个查询要经过「程序→网络→数据库服务器→网络→程序」一个来回。换成SQLite后，查询变成了「程序→本地文件」，网络延迟这个变量被彻底消除了。对于读多写少的网站——比如一个链接分享站——这个变化带来的响应速度提升是实实在在的。
**第三层：费用。**这是最直观的。MariaDB那台服务器每个月的租金，现在不用付了。VPS费用直接减半。这不是一个抽象的「降本增效」，是账单上少了一个数字。
thomas0在帖子里还列了一些技术细节：SQLite不支持无符号大整数，所以某些ID字段的类型要改；SQLite的排序规则比MariaDB弱，只支持ASCII字符的大小写忽略，不支持全UTF-8的写法处理；用了用户自定义函数来补上SQLite缺失的几个计算功能。这些细节对普通读者不重要，但它们说明一个道理：迁移的本质，是在两套系统之间找到一组让所有功能照常工作的新路径。
「够用就好」与软件行业的「复杂度崇拜」
这个故事真正值得被更多人知道的原因，不在技术层面。它触及了软件行业一个根深蒂固的习惯：默认选择「大而全」的方案，而不是「够用」的方案。
Lobsters最初选择MariaDB，是因为当时做网站的标准做法就是「应用程序+独立数据库服务器」。这套架构在十多年前是合理的——那时网站的增长预期高、流量波动大、需要数据库有缓冲能力。但十多年过去了，Lobsters的规模并没有发生质变。它仍然是一个中小型社区网站，日均流量一台普通服务器就能承受。然而那台「以防万一」的数据库服务器，一直在产生每月的固定开支。
这不是孤例。在软件行业，有一个被称为「过早优化」的常见错误：为一个还没有到来的规模提前买单。创业团队前三个人就搭起了Kubernetes集群、微服务架构、主从数据库——只为「将来好扩展」。这些选择本身没错，但代价是运维复杂度、月度账单和故障排查难度的三重上升。
更深一层，笔者想指出的是：技术的「先进」和「合适」是两回事。一个免费的、把数据存文件里的轻量数据库，在功能表上确实不如商业数据库华丽。但如果你不需要那些多出来的功能——比如多用户权限、异地复制、海量并发写入——那么那些功能就不是资产，是包袱。
当然，这不意味着SQLite适合所有场景。thomas0本人也在评论区和网友讨论中坦承：如果网站有大量同时写入的需求、需要多台服务器同时访问同一份数据、或者需要复杂的用户权限管理，SQLite不是合适的选择。它的并发模型是「多读单写」——多人同时看没问题，但同一时刻只能有一个人在写数据。对Lobsters这种「用户浏览远多于发言」的社区来说，这不是问题。对淘宝或者微信来说，这会是灾难。
关键藏在审视自己真正需要什么这个动作里。这个判断，比选择哪个数据库版本号更重要。
最后
从2018年8月pushcx开了那个讨论帖，到2026年7月11日第二次上线成功，Lobsters的数据库迁移横跨了将近八年时间。中间经过了一次失败、三次代码修改、一个自己写的测试脚本、一个自己写的数据库迁移工具，以及无数次的讨论和在聊天频道里的「要不咱们再试一次」。
最终结果简单到可以用一句话讲完：一个运行了十多年的老牌技术社区，把数据库从一套需要独立服务器的商业系统，换成了一个免费的文件型数据库。服务器账单砍半。周一早晨很安静。
这不是一个关于「颠覆」的故事。这是一个关于「回归够用」的故事。
参考链接
- Lobsters 站内帖：现已运行在 SQLite 上（thomas0 发布）
- GitHub issue #539：从 MariaDB 迁移到 PostgreSQL/SQLite 的完整历史
- Simon Willison 的报道：Lobsters 已迁移至 SQLite
- pushcx 的部署清单 Gist：两次上线的完整操作步骤
- Lobsters 开源代码仓库（GitHub）