SQLite 不只是嵌入式数据库：2026 年生产环境实战指南

很多人提到 SQLite，第一反应是「那不是移动端用的小数据库吗？」

但在 2026 年，SQLite 正在经历一场「逆袭」。从 Cloudflare D1、Turso 到 Litestream，越来越多的生产级服务选择 SQLite 作为核心存储。今天我们来聊聊为什么，以及怎么用。

为什么 SQLite 突然「香」了？

1. 零运维成本

不需要单独的数据库进程、不需要连接池、不需要 DBA。一个文件就是一个数据库：

# 你的整个数据库
ls -la app.db
# -rw-r--r-- 1 app app 12M Mar 23 14:00 app.db

对于中小型项目，这意味着：

• 部署成本降低 80%
• 备份 = 复制文件
• 迁移 = 移动文件

2. 性能远超预期

SQLite 在单机读密集场景下的性能非常惊人：

读取性能对比（单机，100 并发）：
SQLite (WAL 模式)    : 50,000+ QPS
PostgreSQL (本地)     : 30,000 QPS
MySQL (本地)          : 25,000 QPS

关键在于 SQLite 没有网络开销、没有协议解析、没有连接管理。数据直接从磁盘（或 page cache）到你的进程内存。

3. WAL 模式改变了游戏规则

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

开启 WAL（Write-Ahead Logging）模式后：

• 读写可以并发（读不阻塞写，写不阻塞读）
• 写入性能提升 5-10 倍
• 崩溃恢复更安全

生产环境最佳实践

连接配置模板

import sqlite3

def get_connection(db_path: str) -> sqlite3.Connection:
    conn = sqlite3.connect(db_path)
    conn.execute('PRAGMA journal_mode=WAL')
    conn.execute('PRAGMA busy_timeout=5000')
    conn.execute('PRAGMA synchronous=NORMAL')
    conn.execute('PRAGMA cache_size=-64000')  # 64MB
    conn.execute('PRAGMA foreign_keys=ON')
    conn.execute('PRAGMA temp_store=MEMORY')
    conn.row_factory = sqlite3.Row
    return conn

写入并发的正确处理

SQLite 的写入是串行的，这是它最大的限制。解决方案：

import threading

class WriteQueue:
    def __init__(self, db_path):
        self._conn = get_connection(db_path)
        self._lock = threading.Lock()
    
    def execute_write(self, sql, params=None):
        with self._lock:
            cursor = self._conn.execute(sql, params or [])
            self._conn.commit()
            return cursor.lastrowid
    
    def batch_insert(self, sql, records):
        """批量写入，性能提升 10-100 倍"""
        with self._lock:
            self._conn.executemany(sql, records)
            self._conn.commit()

关键原则：用单个写连接 + 锁，多个读连接并发。

备份与复制

使用 Litestream 实现实时流式备份到 S3：

# litestream.yml
dbs:
  - path: /data/app.db
    replicas:
      - type: s3
        bucket: my-backup
        path: app.db
        retention: 72h

启动后，每一次写入都会被流式同步到 S3。恢复时间 < 1 秒。

什么时候不该用 SQLite？

说了这么多优点，也要诚实：

场景	推荐
写入 > 1000 TPS	PostgreSQL
多节点写入	CockroachDB / TiDB
复杂查询 + 大数据量	PostgreSQL / ClickHouse
单机读密集 + 适度写入	SQLite ✅
边缘计算 / 嵌入式	SQLite ✅
个人项目 / MVP	SQLite ✅

真实案例

我在一个日活 5 万的内容平台上用 SQLite 跑了 6 个月：

• 数据库大小：800MB
• 读 QPS：平均 2000，峰值 8000
• 写 QPS：平均 50，峰值 200
• 故障次数：0
• 运维时间：接近 0

这个量级，PostgreSQL 当然也能搞定，但 SQLite 让我省掉了数据库服务器的费用和运维精力。

总结

SQLite 不再只是「小玩具」。配合 WAL 模式、正确的并发策略、Litestream 备份，它完全可以支撑中小规模的生产服务。

下次启动新项目时，不妨先问自己：「我真的需要一个独立的数据库服务吗？」

也许答案是一个 12MB 的文件。