SQLite 为什么在 2026 年重新火了？

一个「玩具数据库」的逆袭

很多人对 SQLite 的印象还停留在「嵌入式小数据库」「Android 本地存储」，但 2026 年的 SQLite 生态已经发生了翻天覆地的变化。

从 Turso 的分布式 SQLite（libSQL）到 Cloudflare D1、Fly.io 的 LiteFS，再到 Litestream 的流式复制，SQLite 正在从「嵌入式数据库」蜕变为「生产级数据库」。

为什么 SQLite 突然火了？

1. 边缘计算的崛起

传统数据库（PostgreSQL、MySQL）需要独立的服务器进程，在边缘节点部署成本高昂。SQLite 是进程内数据库，零配置、零依赖，天然适合边缘场景：

import sqlite3

# 一行代码就能用
conn = sqlite3.connect("app.db")
conn.execute("CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY, name TEXT)")

2. 单机性能被严重低估

大多数 Web 应用的数据量根本不需要分布式数据库。一台现代服务器 + SQLite 的 WAL 模式，轻松支撑每秒数万次读取：

PRAGMA journal_mode=WAL;  -- 开启 WAL 模式
PRAGMA synchronous=NORMAL; -- 平衡性能与安全
PRAGMA cache_size=-64000;  -- 64MB 缓存
PRAGMA busy_timeout=5000;  -- 5秒忙等待

实测数据：WAL 模式下 SQLite 读性能可达 100k+ QPS，写入性能约 5k-10k TPS，对 90% 的应用来说绰绰有余。

3. 运维成本趋近于零

• 不需要 DBA
• 不需要连接池
• 不需要备份脚本（直接 cp 文件或用 Litestream）
• 数据库就是一个文件，版本控制、迁移都很简单

2026 年的 SQLite 生态

Turso / libSQL

Turso 是 SQLite 的分布式版本，基于 libSQL（SQLite 的开源分支）。支持：

• 多节点读复制
• 嵌入式副本（embedded replicas）
• 边缘部署

import { createClient } from "@libsql/client";

const db = createClient({
  url: "libsql://your-db.turso.io",
  authToken: "your-token"
});

const result = await db.execute("SELECT * FROM users WHERE active = 1");

Litestream

持续将 SQLite WAL 流式复制到 S3/GCS/Azure Blob，实现近实时备份：

# litestream.yml
dbs:
  - path: /data/app.db
    replicas:
      - url: s3://my-bucket/app.db

Cloudflare D1

基于 SQLite 的 Serverless 数据库，运行在 Cloudflare 边缘网络，冷启动时间几乎为零。

什么时候不该用 SQLite？

别盲目跟风，以下场景 SQLite 不适合：

1. 高并发写入：SQLite 的写入是串行的（即使 WAL 模式），如果你的应用写入密集，考虑 PostgreSQL
2. 多服务器写入：SQLite 不支持多写者，如果你需要多个服务器同时写入同一个数据库，用 PostgreSQL + 连接池
3. 复杂查询 + 大数据量：超过 100GB 的数据，查询优化器不如 PostgreSQL 成熟
4. 需要高级特性：如 JSON 索引、全文搜索（虽然 SQLite 有 FTS5，但功能有限）、地理空间查询

我���建议

如果你在做：

• 个人项目 / 小团队产品 → SQLite + Litestream，够用了
• 需要边缘部署 → Turso 或 D1
• SaaS 产品早期 → SQLite 起步，等真正需要时再迁移
• 大型生产系统 → PostgreSQL 仍然是首选

「不要为你还没有的流量问题选择复杂的架构。」

总结

SQLite 的复兴不是偶然的。边缘计算、Serverless、简化运维这三大趋势的交汇，让这个 25 年历史的数据库焕发了新生。

下次开始新项目时，先问自己：我真的需要一个独立的数据库服务器吗？

答案可能会让你惊喜。