【SQLite 内核】选型与阅读地图：SQLite vs PG vs DuckDB vs RocksDB
内容提要
本文是SQLite内核系列第17篇（末篇），总结选型决策树：根据网络多写者、SQL需求、分析负载等条件，选择PostgreSQL/InnoDB、DuckDB、RocksDB或SQLite。SQLite适合嵌入式行存OLTP，单文件、零IPC、单写者。文章还提供站内阅读地图、学术谱系（如Bayer & McCreight 1972）及开放问题，如单写者权衡、WAL checkpoint策略等。
延伸解读
选型决策树：先问约束，再选引擎
文章给出的决策树以“是否需要网络多写者SQL服务”为第一分支，其次看是否需要SQL、是否分析型负载、是否接受单写者。这提醒读者：选型不是比较性能高低，而是先明确部署形态、并发模型和负载类型。例如，嵌入式场景优先SQLite，多写者网络服务选PG/InnoDB，分析型嵌入选DuckDB，纯KV选RocksDB。
SQLite的适用边界：单写者与嵌入式
SQLite适合数据与应用同进程、能接受单写者（或写冲突可排队/重试）的场景。其优势在于单文件、零IPC、无需运维独立服务。但若需要多写者高吞吐、大规模分析扫描或跨机器强一致，则不宜选择。文章强调“数据量只是一维”，写并发和网络多租户往往更早成为瓶颈。
常见误解：引擎间并非简单替代
文章澄清了几个常见误解：SQLite不能简单替代PostgreSQL，DuckDB不是“更快的SQLite”，RocksDB加自研SQL也不等于SQLite。这些误解忽略了引擎在存储模型、并发控制、优化器、事务支持等方面的根本差异。选错负载会导致双输，选型应基于机制匹配而非性能口号。
Q&A
SQLite 适合什么场景？
SQLite 适合嵌入式行存 OLTP 场景，如手机、桌面、边缘设备本地存储，需要 SQL、事务与索引，但不想运维独立数据库服务，且能接受单写者模型。
SQLite 和 PostgreSQL 在写并发上有什么区别？
SQLite 是文件级单写者，同一时刻只允许一个写者；PostgreSQL 支持多写者并发，适合多客户端网络访问和多写者 OLTP 场景。
DuckDB 和 SQLite 的主要区别是什么？
DuckDB 是嵌入式 OLAP 引擎，采用列式存储和向量化执行，适合分析型扫描和聚合；SQLite 是嵌入式 OLTP 引擎，采用行存和 B-Tree，适合事务处理。两者分工不同，不能互相替代。
RocksDB 适合什么场景？
RocksDB 适合只需要持久化 KV 或迭代器、不需要 SQL 的场景，例如作为嵌入式 KV 存储。
什么时候不应该选择 SQLite？
当需要多个写者同时高吞吐写入同一逻辑库、主路径是大规模分析扫描、只需要字节 KV 且已有 LSM 运维能力，或需要跨机器强一致复制与分片时，不应选择 SQLite。
SQLite 的备份和损坏恢复机制有哪些？
SQLite 提供 Backup API 进行备份，不建议使用热 cp 备份。损坏恢复机制涉及 WAL 和锁，具体可参考系列第 14-15 篇。
SQLite 的 WAL checkpoint 策略有统一的最佳配置吗？
没有。WAL checkpoint 策略随 workload 变化，没有统一的“最佳 PRAGMA”，需要根据具体负载调整。
SQLite 能替代 PostgreSQL 吗？
不能。数据量只是一维，写并发与网络多租户往往先撞墙。SQLite 是嵌入式单写者，PostgreSQL 是服务器多写者，适用场景不同。
