SQLite 已足够：2026 年的单人技术栈

Source: Dev.to

默认堆栈太沉重

在过去的十年里，如果你运行 rails new，几乎会立刻把默认数据库换成 PostgreSQL，然后为 Sidekiq 启动一个 Redis 实例，甚至可能再加上 Elasticsearch 用于搜索。
在写下任何业务逻辑之前，你已经在管理 三个独立的服务。

• 对于 10 人的团队？没问题。
• 对于 “单人框架”？这就是技术债务。

随着 Rails 8 的发布以及现代存储硬件的出现，规则已经改变。是时候不再把 SQLite 当作玩具，而是把它当作生产级的强大引擎来使用了。

硬件转变：NVMe 改变了一切

我们为什么在 2000 年代抛弃基于文件的数据库？旋转硬盘。 在旋转磁盘上的随机 I/O 极其缓慢，并发写入更是噩梦。

如今，即使是 $5 VPS 也使用 NVMe SSD——速度惊人，读取速度约为 3 GB/s，IOPS 达到数十万。当存储如此之快时，瓶颈不再是磁盘，而是网络。

• Postgres: 应用 → TCP 连接 → 套接字 → Postgres 进程 → 磁盘 → 网络 → 应用。
• SQLite: 应用 → 直接系统调用 → 磁盘。

Rails 8 “Solid” 革命

Rails 8 已经全面采用“数据库后端”架构。Rails 团队意识到仅为缓存和作业而管理 Redis 对单独开发者来说是个障碍，于是推出了 “Solid” 三部曲，让 SQLite 负责传统上交给 Redis 的职责。

Solid Queue

后台作业存储在普通的 SQLite 表中——无需 Redis。

Solid Cache

HTML 片段和数据缓存于 SQLite 表中。由于读取是本地的（没有网络延迟），这可以比网络化的 Redis 实例更快。

Solid Cable

WebSocket 的发布/订阅通过数据库处理。

你的基础设施图从一张服务蜘蛛网简化为 单服务器单文件。

但是… “SQLite 不能扩展”，对吗？

最常见的反对意见是 SQLite “无法处理并发”。**错误。**启用 WAL（预写日志）模式 使 SQLite 更加能够处理并发的读取和写入。

# config/database.yml
production:
  adapter: sqlite3
  database: storage/production.sqlite3
  timeout: 5000
  pool: 5
  # Enable WAL mode for better concurrency
  pragmas:
    journal_mode: wal
    synchronous: normal

除非你在构建下一个 Twitter，否则不太可能触及现代 SQLite 的写锁限制。在普通的 VPS 上每秒数百个请求是可行的。如果真的碰到这个限制，恭喜你——你的业务已经足够成功，可以负担迁移到 Postgres。不要为尚未出现的问题进行优化。

“N+1” 超能力

我们花费数小时在 Rails 中优化 N+1 查询，以避免对 Postgres 的“啰嗦”网络调用。

• 请求 1：10 毫秒
• 请求 2：10 毫秒
• …

在 SQLite 中，N+1 查询只是一次 函数调用——惊人地快。遍历 100 条记录并查询关联数据总共大约只需要 2 毫秒。迁移到 SQLite 让你可以编写 更简洁 的代码，因为你不必过于担心数据库往返的开销。

备份怎么办？（关键！）

“如果服务器挂掉，我的文件就丢失了。”

这可以通过 Litestream（或 LiteFS）来解决。Litestream 作为 sidecar 进程运行，挂接到 SQLite 的 WAL 更新，并实时将它们流式传输到 Amazon S3（或任何对象存储）。如果你的服务器着火了，你可以从 S3 拉取数据，将数据库恢复到宕机的那一秒——这在很多情况下比使用 Postgres pg_dump 的定时任务更简单。

摘要：单人堆栈

独立开发者的目标是 速度。

• 没有需要编排的 Docker 容器。
• 没有连接池错误。
• 没有 Redis 版本不匹配。
• 只需 rails server。

复杂性是大脑的克星。简化你的技术栈，你将拥有更多的脑力来真正构建产品。

你敢在生产环境中使用 SQLite 吗？在下方告诉我你的想法！