Lobste.rs 是一个老牌编程社区。它最近完成了一次数据库迁移：从 MariaDB 迁走。
按常见路径，这类迁移的终点通常是 PostgreSQL。更强的数据库、更完整的服务端能力、更符合标准生产架构的选择。Lobste.rs 最早在 2018 年开始讨论迁移时，目标也确实是 PostgreSQL。
结果 8 年过去，项目最后落到 SQLite。
八年后的终点更轻：项目没有再加一层数据库服务，而是删掉了一台需要长期照看的机器。迁移完成后，Lobste.rs 运行在一台 VPS 上，主内容 SQLite 文件大约 3.8GB，另有缓存、队列和限流用的几个数据库文件。维护者反馈 CPU 和内存都下降，站点体感更快，等 MariaDB VPS 下线后，VPS 成本可以减半。
被删掉的一层复杂性
Lobste.rs 的迁移重点是数据库能力和站点规模重新对齐。
数据库服务不是免费存在的。它带来网络连接、进程管理、备份策略、监控项、版本升级和故障排查。对大型系统来说，这些成本值得支付；对一个中小型社区来说，它们可能只是长期利息。
SQLite 的价值不在于“更简单”三个字本身。它依然需要迁移、测试、索引、并发写入验证和部署预案。Lobste.rs 这次最终合入的迁移 PR 有 30 个 commit，改动 188 个文件，新增 735 行、删除 593 行。这次改动的规模不小，本质上是在把复杂性搬回应用边界内。
差别在于，改造完成后，系统少了一台必须长期照看的机器。
可靠性来自匹配规模
很多架构讨论默认把“升级”理解成更强的外部组件。流量更大，引入缓存；数据更多，引入集群；可靠性不足，引入托管服务。这个方向没有错，但它有一个隐含前提：系统的问题确实来自能力不够。
Lobste.rs 的案例提醒另一种可能：有些系统的问题来自部件太多。每多一层服务，就多一组状态、多一种失败方式、多一项需要长期值守的运维责任。
适用边界可以压缩成一个更清楚的对照：内部工具、社区站、后台系统这类读多写少、单机能承载、维护人手有限的服务，SQLite 值得认真评估；需要多写节点、跨地域容灾、复杂权限隔离或已有 DBA 流程的系统，PostgreSQL 和 MySQL 仍然更稳。
迁移前最该验证的是生产流量形态。Lobste.rs 维护者在 issue 里提到，希望基准测试接近真实流量：大量首页和单页阅读，再混入少量评论新增和编辑。对这类系统来说，能否承受真实读写比例，比数据库名称更重要。
工程系统长到一定阶段，成熟不一定表现为继续加东西。当主要瓶颈来自过大的运维面，简化组件比升级组件更接近可靠性。
