SQLite 的复兴：为什么越来越多的生产系统选择它

SQLite 不再只是「玩具数据库」

曾几何时，SQLite 被认为只适合移动端和嵌入式场景。但 2024-2026 年，一股「SQLite 复兴」浪潮正在席卷整个后端开发圈。

Turso、LiteFS、Litestream、Cloudflare D1——这些项目都在围绕 SQLite 构建生产级基础设施。

为什么是现在？

1. 硬件变了

现代服务器的 NVMe SSD 随机读取延迟在 10-50μs 级别。SQLite 的单文件架构在 SSD 上的性能已经远超通过网络访问的 PostgreSQL：

• SQLite 本地读取：~10μs
• PostgreSQL 同机房网络：~500μs-2ms
• PostgreSQL 跨区域：~50-200ms

对于读密集型应用，SQLite 快了 50-100 倍。

2. 架构变了

微服务 → 单体回归。Rails 创始人 DHH 公开倡导回归单体架构，37signals 把整个业务从云迁回自有服务器。在单体架构下，SQLite 的「嵌入式」特性反而成了优势——零网络开销、零运维复杂度。

3. 分布式方案成熟了

SQLite 最大的短板是「单节点写入」，但现在有了解决方案：

LiteFS（Fly.io 出品）：

# litefs.yml
fuse:
  dir: /litefs
  allow-other: true
data:
  dir: /var/lib/litefs
lease:
  type: consul
  advertise-url: "http://${HOSTNAME}:20202"

LiteFS 通过 FUSE 文件系统拦截 SQLite 的写操作，实时复制到其他节点。读可以在任何节点，写路由到主节点。

Turso（libSQL）：

# 创建数据库
turso db create my-app

# 在边缘创建只读副本
turso db replicate my-app --location nrt  # 东京
turso db replicate my-app --location sin  # 新加坡

Turso 基于 libSQL（SQLite 的开源 fork），支持边缘副本，读延迟低至个位数毫秒。

实际应用模式

模式一：每用户一个数据库

import sqlite3
import os

def get_user_db(user_id: str):
    db_path = f"/data/users/{user_id}.db"
    if not os.path.exists(db_path):
        init_user_db(db_path)
    return sqlite3.connect(db_path)

每个用户的数据完全隔离，天然实现多租户。Turso 的 Platform API 就是基于这个模式，支持单个集群管理数万个数据库。

模式二：读写分离 + WAL 模式

PRAGMA journal_mode=WAL;
PRAGMA synchronous=NORMAL;
PRAGMA busy_timeout=5000;

WAL 模式下，SQLite 支持并发读取（多个 reader + 一个 writer），适合大部分 Web 应用的读写比例。

什么时候不该用 SQLite？

• 写入 QPS > 10000（单 writer 瓶颈）
• 需要复杂的 JOIN 跨多个大表
• 多节点强一致写入
• 数据量超过 1TB

结论

SQLite 的复兴不是炒作，而是技术演进的必然结果。硬件更快了，架构更简单了，生态更成熟了。对于 80% 的 Web 应用来说，SQLite 可能是最被低估的选择。