【SQLite 内核】选型与阅读地图：SQLite vs PG vs DuckDB vs RocksDB

本系列从 嵌入式行存全景 写到 文件格式与 Pager、B-Tree 与 VDBE、Journal/WAL、锁与事务、计划器与索引、完整性与备份，再到 与 PG/InnoDB 对照。读到这里应能回答：一次 sqlite3_step 如何落到页面、单写者约束如何塑造并发、WAL 与 cp 备份差在哪。

本文是系列第 17 篇（末篇），收束三件事：选型决策树、站内阅读地图、学术谱系与开放问题。

系列状态：全 17 篇已完成（2026-07-18）。规划见 PLAN.md；系列入口见 index.html。不写跨引擎吞吐排名；性能叙事见既有 sqlite-billion-rows。

一、选型决策树：先定约束再选引擎

flowchart TD
  START["Need local or server data store"]
  START --> Q1{"Need network multi-writer<br/>SQL service?"}
  Q1 -->|yes| PG["PostgreSQL or InnoDB<br/>server row-store series"]
  Q1 -->|no| Q2{"Need SQL?"}
  Q2 -->|no| ROCKS["RocksDB embedded KV<br/>rocksdb series"]
  Q2 -->|yes| Q3{"Workload mostly analytical<br/>scans and aggregates?"}
  Q3 -->|yes| DUCK["DuckDB embedded OLAP<br/>columnar-engine boundary"]
  Q3 -->|no| Q4{"Accept single-writer<br/>per database file?"}
  Q4 -->|yes| SQLITE["SQLite embedded OLTP<br/>this series"]
  Q4 -->|no| PG

1.1 路径说明

1.2 何时选 SQLite

• 数据与应用同进程部署，能接受「库文件 = 部署单元」；
• 写并发模型匹配单写者（或写冲突可排队 / 可重试 SQLITE_BUSY）；
• 需要 SQL、事务与索引，但不想运维独立数据库服务；
• 备份与损坏策略按第 14–15 篇落地（Backup API，慎用热 cp）。

1.3 何时不选 SQLite

• 需要多个写者同时高吞吐改同一逻辑库 → 服务器行存或分库；
• 主路径是大规模分析扫描 → DuckDB / 列存 / 湖仓；
• 只要字节 KV、宿主已有 LSM 运维能力 → RocksDB；
• 需要跨机器强一致复制与分片 → 看分布式系列，而不是把 SQLite 文件用 NFS 硬撑（官方亦不推荐把关键锁依赖建立在不可靠网络文件系统上）。

1.4 机制对照（不是吞吐排名）

flowchart LR
  subgraph sqliteNode ["SQLite"]
    S1["VDBE + Pager"]
    S2["B-Tree pages"]
    S3["Journal or WAL"]
    S1 --> S2 --> S3
  end
  subgraph duckNode ["DuckDB"]
    D1["Vectorized execution"]
    D2["Columnar storage"]
    D1 --> D2
  end
  subgraph rocksNode ["RocksDB"]
    R1["MemTable"]
    R2["SST + compaction"]
    R1 --> R2
  end
  subgraph pgNode ["PG / InnoDB"]
    P1["Server + shared buffers"]
    P2["Row-store + fine locks"]
    P1 --> P2
  end

二、站内阅读地图

flowchart TB
  PERF["sqlite-billion-rows<br/>performance narrative"]
  PG["postgresql-kernel"]
  INNO["mysql-innodb"]
  ROCKS["rocksdb"]
  COL["columnar-engine"]
  subgraph SERIES["This series: SQLite kernel 01-17"]
    A["01-05 storage path"]
    B["06-10 compile journal lock txn"]
    C["11-15 planner attach integrity backup"]
    D["16-17 compare and select"]
    A --> B --> C --> D
  end
  PERF --> A
  PG --> D
  INNO --> D
  ROCKS --> D
  COL --> D

与性能单篇：sqlite-billion-rows 回答「约束如何换速度」；本系列回答「路径如何组织」。与 FDB 历史借用：foundationdb/12 只作 B-Tree 谱系旁注。

三、全系列学术谱系与开放问题

3.1 谱系总表

3.2 仍开放（本系列标注但不关闭）

1. 单写者 vs 细粒度页锁：正确性与实现复杂度的长期权衡（第 1、9、10、16 篇）。
2. WAL checkpoint 与读放大：策略随 workload 变，无统一「最佳 PRAGMA」（第 8 篇）。
3. 嵌入式 OLTP vs 嵌入式 OLAP：SQLite 与 DuckDB 分工，而非互相替代（PVLDB 2022；columnar-engine）。
4. ATTACH 跨库与 WAL 原子性边界：多文件事务的裂缝（第 13 篇）。

常见误解

1. 「SQLite 能替代 PostgreSQL，只要数据不太大。」
   数据量只是一维；写并发与网络多租户往往先撞墙。

2. 「DuckDB 是更快的 SQLite。」
   列存分析与行存 OLTP 假设不同；选错负载会双输。

3. 「RocksDB + 自研 SQL 就等于 SQLite。」
   缺的是优化器、事务 SQL、类型系统与几十年文件格式兼容——成本在工程，不在「再写一层解析器」的口号。

4. 「选了 SQLite 就不用懂 WAL/锁。」
   备份、SQLITE_BUSY、损坏恢复全落在这些机制上（第 8–10、14–15 篇）。

四、小结

三句话小结

1. 选型先问：要不要网络多写者 SQL、要不要分析扫描、要不要 SQL 本身——再落到 PG·InnoDB / DuckDB / SQLite / RocksDB。
2. SQLite 的生态位是嵌入式行存 OLTP：单文件、零 IPC、文件级单写者；本系列补的是从页到备份的内核路径。
3. 单写者、checkpoint、OLTP/OLAP 分工、ATTACH 边界仍是开放问题；后续以官方 release note 与顶会系统论文跟踪即可。

感谢读完本系列。SQLite 内核系列至此完结。

若从本篇决策树选中了 SQLite，建议从 系列目录 的「必读核心」路径回读机制篇，而不是只收藏选型表。

参考资料

规范与官方文档（A 级）

1. SQLite Architecture、When to use SQLite、WAL、Isolation、Backup API。
2. DuckDB 官方文档（选型边界，B/A 级视章节）。
3. RocksDB 官方 wiki / 本站 rocksdb 系列入口。

论文（A 级）

4. Bayer & McCreight, 1972；O’Neil et al., 1996；Berenson et al., SIGMOD 1995。
5. Gaffney et al., SQLite: Past, Present, and Future, PVLDB 15(12), 2022. DOI: 10.14778/3554821.3554842。

站内

6. 本系列 01–16、PLAN.md。
7. postgresql-kernel、mysql-innodb、columnar-engine、rocksdb。
8. sqlite-billion-rows、第 16 篇对照。

上一篇：与 PG / InnoDB 机制对照

感谢读完本系列。SQLite 内核系列至此完结。 系列入口与阅读路径以 index.html 为准。