研究报告 · 约 23,538 字 · 预计推送 3 部分

SQLite 为什么无处不在：架构、WAL 与嵌入式数据库选型逻辑（综合报告） 未开始

目录

题记与说明

版本说明：本稿为综合报告最终稿，撰写与修订日期 2026-10-29。由同日两份章节稿综合而成：纵轴稿《从战舰到边缘的发展史》与横轴稿《嵌入式数据库选型横向对比》。综合时已消除两稿的重复表述（WAL 技术细节、Litestream/LiteFS 生态、个人项目建议此前各写了两遍），并统一了不一致的细节，统一依据为撰写当日对官方来源的直接核验：
1. WAL 所在的 3.7.0 发布日期为 2010-07-21（官方编年史当日读取确认）——横轴稿误作"2011 年"，已更正；
2. WAL-reset 损坏 bug 的影响区间统一为 3.7.0–3.51.2，修复于 3.51.3（2026-03-13）及 3.44.6 / 3.50.7 回移版（官方 WAL 文档当日读取确认）；
3. 部署规模口径统一为 mostdeployed 页面（2026-04-21 更新）的原文表述：超 40 亿智能手机、活跃库超 1 万亿，"官方最佳猜测是仅次于 libz 的第二大部署软件库，且因静态链接可能实为第一"；
4. WAL 性能代价措辞统一为官方原文："在读多写少的应用中比回滚日志慢约 1–2%"（并非所有读场景）；
5. "25 周年纪念版"口径补齐：官方新闻页原文称 3.50.0 为 "Version 3.50.0 is the twenty-fifth anniversary release of SQLite"（news 页当日读取确认）；由纪念版落日 2025-05-29 反推，起算日为 2000-05-29（项目启动），而非编年史首条 1.0 的发布日 2000-08-17（详见 1.6 节）。

本轮按独立审读意见逐条修订的要点：① 3.4 第 1 条"单文件备份"表述与 1.4 节 WAL 机制对齐——冷状态（连接全部正常关闭）方可整文件拷贝，热库不能只拷主文件（补官方警告与正规热备路径），并与第 2 条 Litestream 衔接；② 删除 2.8 与 3.4 第 5/6 条之间"纯 KV""移动端"建议的逐字重复，3.4 相应条目改为引用 2.8；③ 3.4 标题由"两稿合并后的最终决策树"更正为"行动清单"，分支逻辑（三堵墙）在 2.8 开头正式定义，原第 7 条的其余升级条件归入对应墙；④ 为 Workers/D1、官方适用边界、LMDB 许可、Supabase 收购等论断补官方一手出处，删除无出处的"WAL 下 >1GB 事务可能失败""D1 边缘分发建立在日志结构上"表述，以及首次出现、未作介绍的"Turso Sync"（改为指向 1.5/2.6 节已交代的 embedded replicas）；⑤ LMDB 许可更正为 OpenLDAP Public License 2.8（类 BSD），并非公有领域；⑥ 升级建议改写为同时覆盖"低于 3.51.3"与"装了已撤回 3.52.0"两类读者；⑦ 2024-04 Stack Overflow 访谈从 1.5（2019–2023）移入 1.6；⑧ 移除 hopto.org 引用，第三方分析措辞降调并明确标注。

TL;DR

SQLite 的无处不在由两条轴共同造就。纵轴：它用 26 年只打磨"一个文件就是一个数据库"这条不变量——公有领域、零运维、文件格式 22 年未破坏；触碰不变量的尝试（SQLite 4、3.52.0）均失败或被撤回；唯一的重大变更是 2010 年的 WAL：读写并发装进单文件。横轴：2026 年竞品大多成了它的分销渠道——Turso 被 Supabase 收购、Realm 云同步 EOL、D1 本就是托管 SQLite；真正分庭抗礼的只剩 DuckDB（OLAP）与 PGlite。对个人开发者：默认 SQLite + WAL，备份用 Litestream，多端/边缘借 D1/Turso，撞上多写者、扩展、分析三堵墙再换赛道（三堵墙的正式定义见 2.8 节）。

一、纵轴：发展脉络（2000–2026）

1.0 一条与众不同的生命线

大多数数据库的发展史是"版本竞赛史"——更大的集群、更多的特性、更激进的架构革命。SQLite 的纵轴恰恰相反：截至 2026 年 10 月，官方编年史记录了 26.2 年间共 374 个 release，而它始终只做一件事——把"一个文件就是一个数据库"这个决定打磨到近乎不变。理解这条纵轴，就是理解嵌入式数据库选型逻辑的原点：不是"哪个功能多"，而是"哪条不变量在你的场景里最重要"。

1.1 阶段一（2000–2001）：战舰上的单点故障——诞生

2000 年春，D. Richard Hipp 作为 General Dynamics（旗下 Bath Iron Works 船厂）的承包商，为美国海军导弹驱逐舰 USS Oscar Austin（DDG-79）开发软件。舰上既有方案依赖服务器上的 Informix 数据库，服务器一旦因战损或维护宕机，整个软件随之瘫痪（来源：Wikipedia、CoRecursive 访谈、The New Stack）。Hipp 的洞察后来被反复引用："如果 Informix 不工作，我为什么不自己写一个数据库？"——他要的是无服务器、免管理、不可能宕机的数据库。

军事场景对"无单点故障、零运维"的极端要求，恰好成为嵌入式数据库最纯粹的需求定义。个人开发者后来面对的"不想为小项目养一台数据库服务器"问题，与军舰上的问题同构。

1.2 阶段二（2001–2004）：治理定型与 3.0 重写——立下不变量

Hipp 成立自己的咨询公司 Hwaci，SQLite 的开发治理从此定型：公有领域许可、核心代码不接受外部 contribution、以海量测试和防御性编程维持"零缺陷"纪律（这一纪律的后续影响见 Stack Overflow 2024 年访谈）。

2004-06-18，SQLite 3.0：彻底重写文件格式，引入 UTF-8/UTF-16 编码、类型亲和性（type affinity）与更干净的 C API（编年史）。此后 22 年，3.x 是唯一活跃版本线。核心团队此后始终极小——2020 年 ACM 颁奖词中 Hipp、Dan Kennedy、Joe Mistachkin 三人并列（ACM 官方）。

这个阶段确立的是"不变量优先"文化：嵌入式场景的数据库文件可能要在设备上存活十几年，因此文件格式宁可不改、语义宁可不增。这是 SQLite 后来能被塞进飞机、手机和浏览器的信用基础。

1.3 阶段三（2005–2010）：浏览器与手机把它带上船

这一阶段的关键在于：SQLite 没有向开发者做任何推广——是平台厂商替数十亿用户"选"了它。Web SQL 的夭折也从反面验证了 SQLite 的定位：它适合被嵌入，而不适合被当作标准接口。

1.4 阶段四（2010–2018）：WAL 转折与现代 SQL

技术核心：WAL 到底改变了什么。 2010-07-21，SQLite 3.7.0 引入 WAL（Write-Ahead Logging）模式（编年史、官方 WAL 文档，本日核验）。此前默认的 rollback journal 是"改前拷贝原页"：写操作会让读者阻塞。WAL 反转了这个模型：改动追加进独立的 -wal 文件，提交只是在 WAL 里追加一条提交记录；每个读者在启动时记录 WAL 的有效提交终点（end mark），读到的是某一时点的一致性快照。官方文档明确承诺的性质是：读不阻塞写、写不阻塞读——但由于只有一个 WAL 文件，任意时刻仍只有一个写者。配合 PRAGMA synchronous=NORMAL 还能显著减少 fsync() 次数，写入路径变成顺序 I/O。checkpoint（检查点）机制把 WAL 内容合并回主库，默认 WAL 达 1000 页（约 4MB）或最后一个连接关闭时自动触发。代价同样写在文档里：WAL 依赖 mmap 的 -shm 共享内存文件定位页，所有访问进程必须同主机，因此不能放在网络文件系统（NFS 等）上；journal_mode=WAL 是持久设置；伴生文件 -wal/-shm 会出现在同目录；在读多写少的应用中比回滚日志慢约 1–2%。

WAL 是整条纵轴上最关键的一次"性质变更"：它没有改变"单文件、无服务器"的不变量，却把读写并发装进了这个不变量里——后面所有服务器端生态（Litestream、LiteFS、libSQL、D1、rqlite、dqlite）都直接踩在 WAL 之上。

同一时期的其余节点：

驱动因素：Web 时代应用对并发读写和现代 SQL 的要求。

1.5 阶段五（2019–2023）：服务器端文艺复兴——"就用 SQLite 吧"

驱动因素：云成本与运维复杂度的反弹。"一台 Postgres + 一个 sidecar"对个人项目和小型团队过重，而对象存储的普及让"WAL 流 + 快照"成为最廉价的持久化方案。SQLite 被"倒转"使用：从服务器内部被搬到服务器上，作为主数据库。

1.6 阶段六（2024–2026）：25 周年、一次罕见的撤回与 AI 时代的考验

（版本节点全部来自 官方新闻页与 changelog当日读取。）

驱动因素：AI 应用（agent 持久记忆、向量与 JSON 元数据）与边缘部署的新需求；同时"22 年零文件格式破坏"的信用体系在 3.52.0 撤回事件中经受了罕见的公开考验——官方宁可撤回也不放过兼容性裂缝，这正是它"无处不在"的底层逻辑。

1.7 纵轴透视：三个驱动因素贯穿始终

  1. 部署面扩张：军舰（2000）→ 桌面软件 → 浏览器与手机（2007–2009）→ 服务器与边缘（2021– ），每一跳都不是 SQLite 主动出击，而是平台"来提货"。
  2. 不变量工程：单文件格式 22 年未破坏（3.0 后）、公版许可、核心团队极小。所有革命（SQLite 4、Web SQL、3.52.0）都在触碰不变量时死亡或被撤回。
  3. 生态外溢：WAL（2010）造出可复制的日志流，社区在它上面长出 Litestream、LiteFS、libSQL、D1、rqlite、dqlite——SQLite 本体保持克制，外溢生态负责激进。

二、横轴：横向对比（2026 年 10 月截面）

2.1 时间截面：SQLite 的现状

截至 2026-10-29：最新版本 3.54.1（2026-10-16）；许可为公有领域，无任何使用条款约束；官方口径的部署规模为超 40 亿台活跃智能手机每台持有数百个 SQLite 数据库文件，活跃使用的 SQLite 数据库超过 1 万亿（1e12）个，可能是仅次于 libz 的第二大部署软件模块（官方同时注明，因 SQLite 常被静态链接，按实例数算可能实为第一）。它内置于每一台 Android、iPhone、Mac、Windows 10/11，Firefox/Chrome/Safari 浏览器，以及 PHP、Python 语言运行时（mostdeployed 页面，2026-04-21 更新）。

一句话概括横轴起点：SQLite 不是"一个数据库产品"，而是接近"数据存储层的水电煤"。横轴对比因此不能只找"另一个嵌入式数据库"，而要覆盖四类对手：向上替代（客户端-服务器数据库）、平行竞争（其他嵌入式引擎）、下沉替代（KV 存储引擎）、以及"寄生/增强生态"（基于 SQLite 的云服务与分布式扩展层）。

2.2 竞品地图：谁在和 SQLite 竞争

按"竞争关系"而非"产品名录"分类：

  1. 向上的替代：PostgreSQL / MySQL —— 客户端-服务器关系型数据库。当应用从单机走向多用户、多服务共享数据时，最常规的去处。
  2. 同形态的平行竞品：DuckDB —— 同样是进程内嵌入式单文件数据库，但列式存储、面向 OLAP 分析，被称作"分析界的 SQLite"。二者更多是互补而非互斥（DuckDB 甚至能直接查询 SQLite 文件）。
  3. "以 SQLite 为底座"的云化产品：Turso（libSQL）、Cloudflare D1 —— 把 SQLite（或其分叉）变成网络服务。它们既是 SQLite 的分销渠道，也在争夺"你的数据库运行在哪"这个决策位。
  4. 同生态位的挑战者：PGlite —— 把完整 PostgreSQL 编译为 WASM 塞进浏览器/Node 的嵌入式方案，试图用"嵌入式 Postgres"正面挑战"嵌入式 SQLite"的心智。
  5. 下沉替代：LMDB、RocksDB/LevelDB —— 非 SQL 的嵌入式 KV 引擎，在纯键值访问、超高写入吞吐等场景替代 SQLite。
  6. 移动端特化对象数据库：Realm（Atlas Device SDK）、ObjectBox —— 曾长期是移动端对 SQLite+ORM 的替代方案，2024–2025 年格局剧变。
  7. SQLite 自己的扩展层：Litestream、LiteFS、rqlite、dqlite —— 不替代 SQLite，而是补齐它的短板（复制、容灾、分布式共识）。

2.3 总对比表

对比对象定位与形态数据模型/并发许可成本（资源/托管）成熟度个人项目适用度
SQLite 3.54.1进程内嵌入式，单文件行式关系型；WAL 下读写不互斥、单写者公有领域零部署零费用，库仅数百 KB~MB 级极高：22+ 年 3.x、万亿级部署★★★★★（默认答案）
PostgreSQL客户端-服务器行式关系型；MVCC 多写者PostgreSQL License（类 BSD）需常驻服务器进程；云托管 $0~几十/月极高★★★☆（多用户/公网服务时）
DuckDB 1.5进程内嵌入式，单文件列式；向量化执行，面向 OLAPMIT同 SQLite，零部署高（近十年快速成熟）★★★★★（数据分析场景）
Turso（libSQL）SQLite 分叉 + 托管云 + Rust 重写版SQL 兼容；网络访问开源（libSQL MIT 系）免费层 100 库/5GB/月读 5 亿行中高（2026-10 被 Supabase 收购，存在整合变数）★★★★（要云同步/多端访问时）
Cloudflare D1Serverless SQLite（Workers 生态）SQL；平台托管，单库 10GB 上限商业服务（底层 SQLite 公有领域）免费 5GB；付费 $0.75/GB·月，写入计费是大头高★★★★（部署在 Cloudflare Workers 上时）
PGliteWASM 版 Postgres，嵌入式完整 Postgres ~17.4，<3MB gzip；IndexedDB 持久化Apache-2.0（Postgres 系）零部署中（新兴项目，2025 起快速成长）★★★☆（想要 PG 特性又想嵌入时）
LMDB进程内 KV，内存映射 B+ 树键值；读并发极高、单写者OpenLDAP Public License 2.8（类 BSD）零部署，极轻高（老牌，读多写少场景经典）★★★（纯 KV 且读密集时）
RocksDB进程内 KV，LSM 树键值；写吞吐极高，后台 compactionApache-2.0 / GPL 双许可零部署但资源占用大、写放大调优复杂高（Meta 系生产验证）★★（个人项目通常过重）
Realm / Atlas Device SDK移动端对象数据库 + 同步服务对象型原 Apache-2.0（本地库部分仍开源）本地免费；云同步服务已死云同步 2025-09-30 EOL★★（仅存本地库，同步需迁移）
ObjectBox移动端嵌入式对象数据库对象/NoSQLApache-2.0零部署；云同步商业收费高（活跃维护）★★★（移动端对象模型偏好者）

SQLite 生态扩展层（非竞品，补短板）： Litestream（单机 + 对象存储容灾流复制，2025 年起由 Fly.io 接手维护，社区正推进 Litestream VFS）、LiteFS（FUSE 单写多读复制，2025 年维护状态不确定，趋向被 Litestream VFS 取代）、rqlite（Raft 共识的网络化分布式 SQLite，2025-11 仍在活跃发版）、dqlite（Canonical 出品，库形态的 Raft 集群化 SQLite）。

2.4 能力与架构维度

SQLite 的核心能力边界由架构决定：单文件、单写者的嵌入式行式关系库（WAL 的并发模型与限制见 1.4 节，此处不重复）。能力上它与向上替代的差距是具体的：PostgreSQL 用 MVCC 实现真正的多写者并发，还有 JSONB、数组、扩展体系（PostGIS、pgvector）和行级安全——这些是 SQLite 不具备的。SQLite 连 ALTER TABLE DROP CONSTRAINT 这类操作都要靠重建表的变通（不过 2026-04 的 3.53.0 已加入 ALTER TABLE ADD/DROP NOT NULL 与 CHECK 约束，能力在缓慢补齐，见 changelog）。

DuckDB 与 SQLite 是"同一形态、不同负载"：列式 + 向量化执行，聚合、Join、扫描 CSV/Parquet 是它的主场，逐行事务是它的客场。社区共识是两者互补：很多团队用 SQLite 做应用的事务存储、用 DuckDB 做本地分析（DuckDB vs SQLite 对比、OneUptime 选型文）。

LMDB/RocksDB 放弃了 SQL：LMDB 内存映射 B+ 树，读延迟极低、崩溃安全，适合读多写少；RocksDB 的 LSM 树换来极高写吞吐，但体积大、后台 compaction 有开销、调优复杂——官方 Wiki 坦言"把 RocksDB 配置到最优并不简单，连 RocksDB 开发者自己也无法完全理解每个配置项改动的效果"（RocksDB Tuning Guide、OneUptime 对比）。它们适合"明确知道只需要 KV"的场景。

PGlite 是能力维度上最有意思的挑战者：把完整 Postgres ~17.4 编译成 WASM（gzip 后不到 3MB），浏览器里靠 IndexedDB 持久化，支持 pgvector 向量检索。它证明"嵌入式 ≠ 必须是 SQLite"，但 Postgres 内核的体积和资源开销仍显著高于 SQLite 的零依赖 C 库（PGlite GitHub）。

2.5 成本维度

2.6 生态维度

SQLite 的生态优势是"它已经在你身边"：Android、iOS、macOS、Windows、三大浏览器、Python/PHP 运行时全部内置（来源），意味着个人项目几乎不需要引入任何新依赖。移动端 Android 官方推荐的 Room 即 SQLite 之上的抽象层。工具链上，任何 SQL 客户端都能打开一个 .db 文件。

竞品生态各有强项：PostgreSQL 的扩展生态（pgvector、PostGIS）与托管生态（Supabase 等）仍是服务端第一；DuckDB 对 Parquet/CSV/Arrow 的原生读写 + 各数据分析语言绑定，使其成为笔记本分析利器，且能直接查询 SQLite 文件，与 SQLite 形成生态互操作；PGlite 背靠 ElectricSQL 的 local-first 同步体系；Turso 提供 embedded replicas（把云端库复制到本地进程内）与分支等云原生特性。来源：DuckDB vs SQLite、Turso 定价页

2.7 成熟度与风险维度

2.8 场景速查：三堵墙与"什么时候不选 SQLite"

TL;DR 与 3.4 节所说"撞上三堵墙再换赛道"，在此正式定义——它们是 SQLite 架构（单文件、单写者、逐行 OLTP）在三类负载面前的硬边界，也是全文升级建议的统一口径：

  1. 多写者墙：WAL 解决的是读写并发，但"由于只有一个 WAL 文件，任意时刻只能有一个写者"（WAL 文档，机制详见 1.4）。多用户公网服务、需要多写者并发/复杂权限/丰富类型 → PostgreSQL。官方选型检查表的原话就是"Many concurrent writers? → choose client/server"（官方适用边界页）。参考：Better Stack: PostgreSQL vs SQLite
  2. 扩展墙（能力与容量）：需要 pgvector/PostGIS 等扩展体系、行级权限（RLS），或数据规模逼近官方舒适区上限（官方检查表原话"Big data? → choose client/server"；官方对 SQLite 的适用描述是"对设备本地存储、低写并发、小于 1TB 的数据，SQLite 几乎总是更好的方案"）→ PostgreSQL。个人项目不必等到 1TB：数百 GB 通常已伴随性能与运维信号，可视为提前撞墙。
  3. 分析墙：逐行 OLTP 引擎做聚合分析事倍功半。本地分析、扫描大文件、数据科学 → DuckDB。

三堵墙之外的场景速查（属"同生态借力"或"下沉替代"，不是撞墙换库）：

2.9 横轴结论

在 2026-10-29 这个时间截面上，横向对比揭示了一个反直觉的事实：SQLite 的主要"竞品"大多最终变成了 SQLite 的分销渠道。Turso 从分叉（libSQL）走向重写（Rust）再被 Supabase 收购，但其免费层卖的仍是"SQLite 兼容"心智；Cloudflare D1 干脆就是托管 SQLite；rqlite/dqlite/Litestream 是 SQLite 的增强层而非替代品。真正在能力上分庭抗礼的，只有 DuckDB（换了负载类型：OLAP）和 PGlite（换了内核：Postgres），而前者与 SQLite 互补，后者仍显年轻。

SQLite 无处不在的护城河，横轴上看是三条难以同时复制的属性：公有领域许可（无掣肘）、进程内单文件形态（零运维）、超长期文件格式稳定（数据不死）。竞品可以在这三条的任意组合上局部胜出——DuckDB 胜在列式分析，Postgres 胜在多写者与扩展，托管云胜在可达性——但没有谁能在三条线上全面取胜。

三、交叉洞察：两轴交汇说明了什么

3.1 纵轴是横轴的因：护城河是时间沉淀的信用

横轴总结的三条护城河——公有领域、单文件形态、格式稳定——没有一条是"功能"，全是不变量。而不变量无法靠一次重写复制：DuckDB 和 PGlite 可以在能力上追平甚至局部超越 SQLite，但"22 年文件格式向后兼容 + 官方承诺支持到 2050"（Stack Overflow 访谈）只能靠时间积累。纵轴因此解释了横轴上最反直觉的现象：为什么 26 年里没有出现全能竞品——因为竞品竞争的维度（功能、性能、云体验）恰恰不是 SQLite 立身的维度。SQLite 4 的终止和 3.52.0 的撤回从内部证明：连 SQLite 自己都不能破坏这条不变量而不付出代价。

3.2 WAL 是连接两轴的枢纽：本体克制，外溢激进

纵轴上，WAL 只是 2010 年 3.7.0 的一次版本特性；横轴上，它是整个"服务器端文艺复兴"的地基——Litestream 复制的是 WAL 变更流，LiteFS 复制的是 WAL，rqlite/dqlite 的共识层包装的是 WAL 之上的写路径，libSQL/Turso 的 embedded replicas 同步的仍是 WAL 语义；D1 则干脆以 SQLite 本体为底座做成托管服务（Cloudflare 自述"D1 is built on SQLite"，发布公告）。两轴合看得到一个重要判断：SQLite 官方 26 年里只负责维护"性质"（单文件、WAL、兼容性），把"把性质变成产品"全部留给了生态。这就是"生态外溢"模式——本体克制、外溢激进——而外溢生态反过来又扩大了本体的部署面，形成飞轮。

3.3 两轴的失败案例互为镜像，指向同一个变量：控制权

两轴对照后，嵌入式选型的第一变量浮出水面：不是功能，而是控制权——数据的可携带性（能不能把数据带走）与供应链的独立性（服务死了我还能不能打开数据）。SQLite 的"单文件 + 公有领域"把控制权完整留给用户；竞品的云同步把控制权交给供应商。个人项目"五年后还能打开"这条朴素标准，正是两条轴的交集。

3.4 对个人开发者的行动清单

对个人项目而言，选型的第一性原理是：你的稀缺资源是时间与注意力，不是并发与吞吐。换赛道的分支逻辑即 2.8 节正式定义的"三堵墙"：默认 SQLite + WAL，撞上多写者墙或扩展墙 → PostgreSQL，撞上分析墙 → DuckDB，其余场景见下面各条。

  1. 默认答案就是 SQLite，并打开 WAL。 单机工具、CLI、桌面应用（Tauri/Electron）、移动应用、个人网站后台、Side Project 原型、本地优先（local-first）产品的数据层——零依赖、冷状态下单文件即完整备份、公有领域许可、数据文件格式 20+ 年向后兼容，意味着"这个项目五年后还能打开"。没有任何竞品同时满足这四条。执行层面：PRAGMA journal_mode=WAL;（持久设置）即可获得"读写不互相卡"的多线程安全感；配合 PRAGMA synchronous=NORMAL 提升写吞吐；-wal/-shm 伴生文件是正常现象；数据库文件不要放在网络盘/NFS 挂载上（WAL 硬限制）。备份要区分冷热：最后一个连接正常关闭时，SQLite 会自动做收尾 checkpoint 并删除 -wal/-shm（WAL 文档），此后主库文件即完整快照，复制一个文件即可；但 WAL 模式下的热库不能只拷主文件——官方明确警告：-wal 文件是数据库持久状态的一部分，拷贝/移动数据库必须连同它一起，"主文件与 WAL 分离后，此前已提交的事务可能丢失，库文件也可能损坏"。在线热备份的正规路径是官方备份 API / VACUUM INTO / sqlite3_rsync（备份文档），实用做法为先执行 PRAGMA wal_checkpoint(TRUNCATE); 并确保拷贝期间无新写入；持续热备份则直接交给下条的 Litestream。
  2. 备份用"WAL 流"而非"整库导出"。 接一个 Litestream 到对象存储（S3/R2），即得分钟级 RPO 的持续备份——这是 2021 年服务器端文艺复兴给个人项目留下的最轻量遗产（实践）。
  3. 需要多人/多端/边缘时再"借生态"，优先选以 SQLite 为底座的托管。 部署在 Cloudflare Workers 上选 D1（注意写入计费 $1.00/百万行）；想要 embedded replicas、多库免费额度，选 Turso 免费层（100 库/5GB，注意 Supabase 整合期的变数）；单机多读者可自托管 + Litestream。两者免费额度都远超个人项目实际用量，且保留 SQLite 心智模型，迁移成本近零。
  4. 数据分析负载用 DuckDB，与 SQLite 共存不冲突。 应用数据放 SQLite，分析查询用 DuckDB（它能直接读 SQLite 文件）。
  5. 纯 KV 场景：一句话速查见 2.8——先试 SQLite 单表（key TEXT PRIMARY KEY, value BLOB），读极密集才下沉 LMDB、写吞吐优先才下沉 RocksDB；RocksDB 的调优负担对个人项目远超收益。
  6. 移动端：一句话速查见 2.8——Room/平台 SQLite 封装为默认稳妥解，ObjectBox 适合对象模型偏好者，Realm 云同步已 EOL 勿选。
  7. 何时必须升级到 PostgreSQL：即撞上 2.8 定义的多写者墙或扩展墙——出现"多用户同时写""需要 pgvector/PostGIS 等扩展""需要行级权限""数据规模逼近官方小于 1TB 的舒适区上限"任一条件，或团队已有 Postgres 运维经验。SQLite 官方适用边界页给出的判断式至今没有被生态突破："对设备本地存储、低写并发、小于 1TB 的数据，SQLite 几乎总是更好的方案"；其检查表在两个方向上的断言分别是"Many concurrent writers? → choose client/server"与"Big data? → choose client/server"。从 SQLite 迁移到 PG 的成本是真实存在的（类型系统、并发语义、运维），所以把"上 PG"当作明确里程碑，而非默认路径——绝大多数个人项目终其一生达不到单写者的瓶颈。
  8. 数据要跨设备实时同步（offline-first）是 SQLite 的真实短板：官方无同步方案，生态答案要么是第三方同步层（Turso 的 embedded replicas——把云端库复制到本地进程内，见 1.5 与 2.6 节；或 PowerSync），要么换 local-first 栈（PGlite + ElectricSQL）。若同步需求只是"偶尔备份到网盘"，Litestream 流复制是最省心答案。
  9. 版本策略：跟随官方半年节奏即可；低于 3.51.3 的生产库，以及装了已撤回 3.52.0 的用户，都应升到 3.53.0+（3.53.0 修复了 WAL-reset 损坏 bug 与过期表达式索引问题，见 1.6），升级是就地替换库文件、无迁移成本——这正是单文件不变量的红利。
  10. 一个 2026 年的时代注脚：Supabase 于 2026-10-02 官方宣布收购 Turso 并完成 $150M 新融资（官方新闻稿，新闻稿原话是 "agent-driven databases" 与 "on-demand per-agent databases"）；"给每个 AI Agent 一个数据库"这一定性口号则主要出自收购后的第三方分析（分析，属第三方观察而非官方口号）。无论措辞出自谁，AI 生成应用的爆发让"海量小库、每人每 Agent 一个"成为新增长点，而这恰好是 SQLite 架构（进程内、单文件、低成本多实例）最擅长的形态。个人开发者拥抱"AI 帮我写代码 + SQLite 帮我存数据"的组合，正站在趋势的顺风面。

四、参考来源

SQLite 官方：编年史 chronology · 新闻页 news · changelog · WAL 文档 · 适用边界 whentouse · 在线备份 backup · 3.45.0 发布说明 · Consortium 新闻稿 2007 · 联盟协议 · 最广部署 mostdeployed · Older News

治理与荣誉：ACM 2020 软件系统奖 · SIGMOD Record 人物志 · Wikipedia: ACM Software System Award · Stack Overflow 访谈 2024（2050 承诺）

起源与传播：CoRecursive: The Untold Story of SQLite · The New Stack 起源故事 · Wikipedia: SQLite · Nolan Lawson: Web SQL In Memoriam · Stack Exchange: Web SQL 为何被弃用

生态与文艺复兴：HN: Postgres Cluster → Distributed SQLite · HN: SQLite4 终止 · Litestream 实践 · libSQL (GitHub) · Turso 并入 libSQL · Turso Rust 重写 (HN) · rqlite (GitHub) · dqlite (GitHub) · Litestream VFS 提案 issue #1118

云化 SQLite 与定价：Cloudflare D1 文档 · Cloudflare D1 定价 · Cloudflare: introducing D1 · Cloudflare Workers 安全模型（无本地文件系统） · D1 写成本分析 · D1 10GB 限制讨论 · Turso 定价 · Supabase 收购 Turso（官方新闻稿） · 收购对自托管者的影响（第三方） · Agent 数据库叙事分析（第三方）

嵌入式引擎对比：DuckDB vs SQLite · OneUptime: SQLite/DuckDB/RocksDB/LMDB 选型 · PGlite (GitHub) · RocksDB Tuning Guide（官方 Wiki） · SurrealDB 存储选型讨论（个案社区反馈）

服务端对照与移动端格局：Better Stack: PostgreSQL vs SQLite · MongoDB Realm/Atlas 弃用公告 · Couchbase: Realm EOL 评论 · Phoronix: SQLite 3.45

思考题（读完后想一想，参考答案可展开）

  1. 报告如何从纵轴解释 SQLite"无处不在"？哪些尝试因触碰不变量而失败？
    参考答案

    核心是不变量工程：26 年只打磨"一个文件就是一个数据库"——公有领域许可、零运维、3.0 之后文件格式 22 年未破坏，官方承诺支持到 2050 年。触碰不变量的尝试均失败：SQLite 4（LSM 风格重写）2017 年 11 月宣布终止；Web SQL 因把某个具体版本的 SQLite 行为焊死成标准而被弃用；3.52.0 因兼容性裂缝于 2026-03-13 被官方罕见撤回。唯一重大变更是 2010-07-21 的 WAL：不改单文件不变量却把读写并发装进来，后来的 Litestream、LiteFS、libSQL、D1、rqlite 都踩在 WAL 之上。

  2. 2026 年横轴上 SQLite 的竞品格局呈现什么反直觉事实？"三堵墙"分别指什么？
    参考答案

    主要竞品大多成了 SQLite 的分销渠道：Turso（libSQL 分叉）2026-10 被 Supabase 收购、Cloudflare D1 本就是托管 SQLite、Litestream/rqlite/dqlite 是增强层；真正分庭抗礼的只有 DuckDB（OLAP，能直接读 SQLite 文件，互补）与 PGlite（WASM 版 Postgres，仍年轻）。三堵墙是架构硬边界：多写者墙——WAL 下任意时刻只有一个写者，多用户公网服务换 PostgreSQL；扩展墙——需要 pgvector/PostGIS、行级权限或数据逼近官方 1TB 舒适区上限换 PG；分析墙——聚合分析负载换 DuckDB。

  3. WAL 模式有哪些硬限制？WAL-reset bug 与 3.52.0 撤回事件说明了什么？
    参考答案

    WAL 硬限制：所有访问进程必须同主机，不能放 NFS 等网络文件系统；-wal/-shm 伴生文件是数据库持久状态的一部分，热库只拷主文件可能丢事务甚至损坏（热备走官方备份 API、VACUUM INTO 或 sqlite3_rsync）；任意时刻仍只有一个写者；读多写少应用中比回滚日志慢约 1-2%。WAL-reset 损坏 bug 影响 3.7.0（2010）至 3.51.2 长约十五年，触发条件极罕见，2026-03 发现后于 3.51.3 快速修复并有回移版——报告视之为稳定度加分项；3.52.0 被撤回则说明官方宁可撤回也不破坏兼容性，这正是"无处不在"的底层逻辑。

  4. 报告给个人开发者的默认选型、备份与版本升级建议是什么？
    参考答案

    第一性原理：个人项目的稀缺资源是时间与注意力，不是并发与吞吐。默认 SQLite + WAL（PRAGMA journal_mode=WAL 持久生效，可配 synchronous=NORMAL），撞上多写者/扩展墙再换 PostgreSQL，撞分析墙换 DuckDB，纯 KV 场景先试 SQLite 单表。备份用 Litestream 把 WAL 流复制到 S3/R2；冷状态（连接全部正常关闭）下单文件即完整备份，热库走官方备份路径。需要多端/边缘时借 D1/Turso（警惕 D1 写计费 $1.00/百万行）。版本策略：低于 3.51.3 或装了已撤回 3.52.0 的应升到 3.53.0+，升级是就地替换库文件、无迁移成本。

← 资料库今日播报 →