SQLite 为什么在 2026 年成了最被低估的数据库

很多人对 SQLite 的印象还停留在"嵌入式小数据库"、"开发环境用用就行"的阶段。但事实上，SQLite 在 2026 年已经悄悄成了很多生产系统的核心组件。

先看几个数据

• SQLite 是世界上部署量最大的数据库，没有之一（每台手机、浏览器、操作系统里都有）
• Cloudflare D1、Turso、LiteFS 等云服务都基于 SQLite 构建
• Rails 8 默认支持 SQLite 作为生产数据库
• Litestream 实现了 SQLite 的实时流式备份到 S3

为什么 SQLite 越来越香

1. 零运维成本

不需要数据库服务器，不需要连接池，不需要 DBA。一个文件就是一个数据库：

# 你的整个数据库
ls -la myapp.db
# -rw-r--r-- 1 user user 42M Mar 24 10:00 myapp.db

对于中小项目来说，省掉的运维成本是巨大的。不用操心 PostgreSQL 的连接数限制、MySQL 的主从同步延迟、Redis 的内存溢出。

2. 性能出乎意料地好

在单机场景下，SQLite 的读性能可以吊打大多数 C/S 架构数据库：

import sqlite3
import time

conn = sqlite3.connect("bench.db")
conn.execute("PRAGMA journal_mode=WAL")  # 关键优化
conn.execute("PRAGMA synchronous=NORMAL")
conn.execute("PRAGMA cache_size=-64000")  # 64MB 缓存

# 简单查询：10 万次 SELECT 只需 0.3 秒
start = time.time()
for i in range(100000):
    conn.execute("SELECT * FROM users WHERE id = ?", (i % 1000,)).fetchone()
print(f"100K reads: {time.time() - start:.2f}s")

原因很简单：没有网络往返。数据就在本地磁盘，读操作直接走内存映射。

3. WAL 模式解决了并发写入

SQLite 最大的历史槽点是"写入锁全库"。但 WAL（Write-Ahead Logging）模式改变了这个局面：

PRAGMA journal_mode=WAL;

开启后：

• 多个读操作可以和一个写操作并发执行
• 写入不会阻塞读取
• 对于大多数 Web 应用的读多写少场景，完全够用

4. 云原生 SQLite 生态爆发

2026 年最令人兴奋的是 SQLite 的云端生态：

Turso (libSQL)

# 创建一个全球分布式的 SQLite 数据库
turso db create myapp
turso db replicate myapp --location nrt  # 东京副本
turso db replicate myapp --location sin  # 新加坡副本

基于 libSQL（SQLite 的开源 fork），支持多副本、边缘分发、实时同步。

Cloudflare D1

// Workers 里直接用 SQL
export default {
  async fetch(request, env) {
    const result = await env.DB.prepare(
      "SELECT * FROM posts WHERE published = 1 ORDER BY created_at DESC LIMIT 20"
    ).all();
    return Response.json(result);
  }
};

LiteFS + Fly.io

# litefs.yml
fuse:
  dir: "/litefs"
data:
  dir: "/var/lib/litefs"
lease:
  type: "consul"
  advertise-url: "http://${FLY_ALLOC_ID}.vm.${FLY_APP_NAME}.internal:20202"

通过 FUSE 文件系统实现多节点 SQLite 透明复制。

什么时候不该用 SQLite

说了这么多好话，也得说说局限：

• 高并发写入：每秒几千次写入的场景，还是老老实实用 PostgreSQL
• 多服务共享数据库：微服务架构下多个服务访问同一个库，SQLite 不合适
• 超大数据集：TB 级别的数据，SQLite 的单文件架构会很吃力
• 复杂查询优化：SQLite 的查询优化器比 PostgreSQL 简单很多

我的实际使用建议

日访问量 < 10万 PV → SQLite 大概率够用
写入 QPS < 100 → SQLite WAL 模式搞定
需要全球分布 → Turso / D1
需要高可用 → LiteFS + 多副本
其他 → PostgreSQL 永远是安全选择

总结

SQLite 不是 PostgreSQL 的替代品，但对于大量中小项目来说，它是更好的选择。零运维、高性能、极致简单——这些特点在云原生时代反而变成了巨大优势。

下次启动新项目时，不妨先问自己："我真的需要一个数据库服务器吗？"答案可能会让你意外。