Jersey's Blog

外观

第十一章 SQLite 的适用边界与架构建议 ​

11.1 SQLite 能支撑多大的应用？ ​

很多人对 SQLite 有一个误解——觉得它只是个"玩具数据库"。实际上，SQLite 的能力常常超出你的想象。

理论上限 ​

┌─────────────────────────────────────────────────┐
│           SQLite 的理论上限                       │
│                                                 │
│  最大数据库大小：281 TB（2⁴⁷ 字节）               │
│  最大行数：无硬性限制（受文件大小限制）            │
│  最大列数：2000 列（编译选项可调整）              │
│  最大 SQL 语句长度：1,000,000,000 字节            │
│  最大 ATTACH 数据库：125 个                       │
│  单表最大行数：2⁶⁴ 行（理论值）                  │
│                                                 │
│  实际上，大多数应用在数据库达到 1 GB 之前          │
│  就已经轻松满足需求了。                          │
└─────────────────────────────────────────────────┘

真实案例 ​

谁在用 SQLite怎么用的规模
每部 iPhone / Android 手机通讯录、短信、照片库、浏览器历史全球数十亿设备
Chrome / Firefox / Safari浏览器书签、Cookie、历史记录、LocalStorage数十亿用户
Airbus A350飞行软件数据存储航空安全级别
微信 / WhatsApp本地聊天记录存储十亿级用户
Expensify生产环境 Web 应用单库 16 GB
Pieter Levels（Nomad List 等）独立开发者的多个百万流量产品月流量百万级
LitestreamSQLite + 流式复制 = 生产数据库中小型 Web 应用

SQLite 能轻松搞定的应用类型 ​

✅ 嵌入式 / IoT 设备应用
✅ 移动端 App（iOS / Android）
✅ 桌面应用（Electron / 原生）
✅ 命令行工具和脚本
✅ 单元测试的数据库替身
✅ 数据分析 / 科研（替代 CSV 文件）
✅ 中小型网站和 API（< 10 万日活）
✅ 个人项目 / 独立开发者产品
✅ 应用配置和元数据存储
✅ 本地缓存层

性能参考数据 ​

在一台普通笔记本上（SSD，WAL 模式）：

  写入性能：
  - 事务内批量 INSERT：~50,000~100,000 行/秒
  - 单条 INSERT（自动事务）：~50~100 行/秒
  - 差距原因：每个自动事务都要 fsync 一次磁盘

  读取性能：
  - 主键查询：< 1 微秒
  - 索引查询：< 10 微秒
  - 全表扫描（100 万行）：约 0.5~1 秒
  - COUNT(*)（100 万行）：约 0.1~0.3 秒

  并发性能（WAL 模式）：
  - 读并发：无限制（多连接同时读）
  - 写并发：1 个写者（其他写者排队等待）

11.2 什么时候该切换到 PostgreSQL / MySQL ​

SQLite 不是万能的。以下是一些明确的信号，提示你该考虑迁移到客户端-服务器架构的数据库了。

该迁移的信号 ​

🚨 明确需要迁移的场景：

  1. 高并发写入
     → 多用户/多服务同时大量写入
     → SQLite 同一时间只允许一个写者

  2. 多服务器部署
     → 微服务架构，多个后端实例需要共享数据库
     → SQLite 不支持网络访问

  3. 数据库超过 100 GB
     → VACUUM 等维护操作变得耗时
     → 备份和恢复变得复杂

  4. 需要复杂的权限管理
     → SQLite 没有用户/角色/权限系统
     → 无法限制不同用户的访问权限

  5. 需要高级复制功能
     → 主从复制、读写分离
     → 跨地域数据同步

SQLite vs PostgreSQL vs MySQL ​

维度SQLitePostgreSQLMySQL
架构嵌入式（无服务器）客户端-服务器客户端-服务器
部署零配置需要安装配置需要安装配置
并发写入1 个写者多个写者（MVCC）多个写者（InnoDB）
多服务器❌ 不支持✅ 支持✅ 支持
权限管理❌ 无✅ 完善✅ 完善
复制❌ 原生不支持✅ 流复制 / 逻辑复制✅ 主从复制
JSON 支持✅ 好✅ 非常好（JSONB）✅ 好
全文搜索✅ FTS5✅ ts_vector✅ FULLTEXT
运维成本⭐ 几乎为零⭐⭐⭐ 需要 DBA⭐⭐ 相对简单
适合规模嵌入式~中型中型~超大型中型~大型

决策流程图 ​

你的应用需要什么？

  需要多服务器共享数据库？
  ├── 是 → PostgreSQL / MySQL
  └── 否 ↓

  需要高并发写入（> 100 写/秒持续）？
  ├── 是 → PostgreSQL / MySQL
  └── 否 ↓

  需要细粒度权限控制？
  ├── 是 → PostgreSQL / MySQL
  └── 否 ↓

  数据量可能超过 100 GB？
  ├── 是 → PostgreSQL / MySQL
  └── 否 ↓

  → ✅ SQLite 完全够用！
    不要过早优化，不要过度设计。

黄金法则：先用 SQLite 开始。等到确实遇到瓶颈时，再考虑迁移。过早引入 PostgreSQL 只会增加不必要的复杂性。

11.3 混合架构：SQLite + 远程数据库 ​

在现代架构中，SQLite 不一定要"单打独斗"。它可以和远程数据库配合使用，各取所长。

架构一：SQLite 作为本地缓存 ​

┌────────────┐        ┌──────────────┐
│  客户端     │  ←───→ │ SQLite       │  ← 本地缓存 / 离线数据
│  (App)     │        │ (本地)       │
└──────┬─────┘        └──────────────┘
       │
       │  网络
       ↓
┌──────────────┐
│ PostgreSQL   │  ← 服务端主数据库
│ (远程)       │
└──────────────┘

  场景：移动 App 需要离线使用
  → API 数据缓存在本地 SQLite
  → 联网后同步到远程数据库
  → 典型应用：笔记 App、TODO、离线表单

架构二：SQLite 作为边缘数据库 ​

      ┌───────────┐  ┌───────────┐  ┌───────────┐
      │ 边缘节点 A │  │ 边缘节点 B │  │ 边缘节点 C │
      │ (SQLite)  │  │ (SQLite)  │  │ (SQLite)  │
      └─────┬─────┘  └─────┬─────┘  └─────┬─────┘
            └───────────────┼───────────────┘
                            │ 同步
                     ┌──────┴──────┐
                     │ 中心数据库    │
                     │ (PostgreSQL) │
                     └─────────────┘

  场景：边缘计算、CDN 节点、多区域部署
  → 每个节点用 SQLite 处理本地请求（低延迟）
  → 定期同步到中心数据库

Litestream —— SQLite 的流式复制 ​

Litestream 是一个开源工具，可以把 SQLite 数据库实时复制到 S3 等对象存储，实现类似传统数据库的灾备能力。

bash
# 安装 Litestream
brew install litestream  # macOS

# 配置复制到 S3
# litestream.yml
# dbs:
#   - path: /path/to/my_app.db
#     replicas:
#       - url: s3://my-bucket/my_app

# 启动复制（在后台持续运行）
litestream replicate -config litestream.yml

# 从 S3 恢复
litestream restore -o /path/to/restored.db s3://my-bucket/my_app
Litestream 的价值：

  ✅ SQLite 的简单性 + 云端备份的安全性
  ✅ 亚秒级复制延迟
  ✅ 支持 S3、GCS、Azure Blob、SFTP、本地目录
  ✅ 点时间恢复（Point-in-Time Recovery）

  适合：个人项目、小团队应用、希望用 SQLite 做生产数据库

LiteFS —— 分布式 SQLite ​

LiteFS（由 Fly.io 开发）让多个服务器节点可以共享同一个 SQLite 数据库：

  ┌───────────┐   ┌───────────┐   ┌───────────┐
  │  节点 A    │   │  节点 B    │   │  节点 C    │
  │ (读写)    │──→│ (只读)    │   │ (只读)    │
  │  Primary  │   │  Replica  │   │  Replica  │
  └───────────┘   └───────────┘   └───────────┘

  一个写节点 + 多个只读副本
  通过 FUSE 文件系统透明复制

架构选择总结 ​

架构适合场景复杂度
纯 SQLite单服务器、嵌入式、桌面、移动⭐
SQLite + Litestream需要云备份和灾备⭐⭐
SQLite + LiteFS需要多节点只读副本⭐⭐⭐
SQLite（本地）+ PostgreSQL（远程）离线优先、边缘计算⭐⭐⭐
纯 PostgreSQL高并发写入、大规模⭐⭐⭐⭐

本章小结 ​

知识点要点
SQLite 上限最大 281 TB；实际大多数应用 < 1 GB 就够用
真实案例全球数十亿设备在用（手机、浏览器、航空）
迁移信号高并发写入 / 多服务器 / > 100 GB / 权限管理 / 复制需求
三库对比SQLite（嵌入式简单）→ PostgreSQL（强大全面）→ MySQL（中间路线）
混合架构SQLite 作缓存/边缘；Litestream 云备份；LiteFS 分布式只读副本
黄金法则先用 SQLite 开始，瓶颈时再迁移

📖 完整附录请见：附录

  • 附录 A：常用 SQL 语句速查表
  • 附录 B：常用 PRAGMA 配置说明
  • 附录 C：SQLite 内置函数参考（字符串 / 数学 / 聚合 / 日期 / 条件 / JSON / 窗口）
  • 附录 D：推荐学习资源与官方文档链接

全书总结 ​

┌─────────────────────────────────────────────────┐
│                                                 │
│   恭喜你完成了 SQLite 入门教程！                  │
│                                                 │
│   你已经学会了：                                 │
│                                                 │
│   ✅ SQLite 的设计哲学与架构                     │
│   ✅ 安装与命令行操作                            │
│   ✅ DDL：建库、建表、约束                       │
│   ✅ DML：增删改、UPSERT                        │
│   ✅ SELECT：从基础到 JOIN、子查询、CTE           │
│   ✅ 索引：原理、创建、EXPLAIN、避坑              │
│   ✅ 事务：ACID、WAL、并发锁机制                  │
│   ✅ 特色功能：JSON、FTS5、窗口函数、STRICT       │
│   ✅ 编程集成：Python、Node.js、Go、ORM          │
│   ✅ 运维：备份、修复、VACUUM、性能调优           │
│   ✅ 架构：适用边界、迁移信号、混合架构           │
│                                                 │
│   SQLite 的座右铭：                               │
│   "Small. Fast. Reliable. Choose any three."     │
│                                                 │
│   现在，去用 SQLite 构建你的下一个项目吧！ 🚀     │
│                                                 │
└─────────────────────────────────────────────────┘

坚持是一种品格

Copyright © 2024-2026 Jersey