SQLite 和 RocksDB 是两款应用广泛但设计理念迥异的嵌入式数据库。它们各有优劣，适用场景也不同。下面这个表格汇总了它们的核心差异，方便你快速了解：

特性维度

SQLite

RocksDB

数据模型

关系型 (Relational)

键值型 (Key-Value)

架构

无服务器，单文件

嵌入式库，LSM-Tree结构

存储引擎

B-tree（磁盘就地更新）

LSM-Tree（内存缓冲，顺序追加写入）

写入性能

更适合低频、事务性写入

极高吞吐，尤其擅长持续大批量写入

读取性能

索引支持下点查和复杂查询效率高

点查快，但范围查询和全表扫描可能较慢

并发控制

文件锁，写操作会阻塞读写

多版本并发控制 (MVCC)，读写冲突少，高并发下更优

资源占用

极低，内存通常在MB级

较高，需要分配较多的内存用于缓存和过滤

压缩与空间效率

支持页级压缩

支持多种压缩算法，存储空间利用率高

适用场景

客户端/移动应用、嵌入式设备、轻型Web应用、系统内部数据管理

分布式系统底层存储引擎、实时日志/监控数据、高性能缓存、消息队列

️ 数据模型与架构SQLite 是一个经典的关系型数据库。你通过熟悉的 SQL 语句（如 CREATE TABLE, SELECT ... JOIN）来定义和操作数据，数据以表格形式组织，支持复杂的关联查询和事务。它的一切——表结构、索引、数据——都存储在一个独立的磁盘文件中，部署简单到只需拷贝一个文件。RocksDB 则是一个高性能的持久化键值（Key-Value）存储库。你通过 Put(key, value)和 Get(key)这样的 API 来存取二进制数据。它源自 Google 的 LevelDB，并由 Facebook 优化，采用 LSM-Tree (Log-Structured Merge-Tree) 结构，常作为大型分布式系统（如 TiDB、CockroachDB）的底层存储引擎。⚙️ 核心原理与读写性能

它们的核心原理截然不同，这直接决定了性能特点。

SQLite 使用 B-tree 引擎。它倾向于将数据直接写入磁盘的最终位置（就地更新）。为了保证数据一致性，它采用文件锁机制，当有写入操作时，会短暂阻塞其他读写操作，这在高并发写入场景下可能成为瓶颈。RocksDB 使用 LSM-Tree 引擎。其写入流程如下图所示，这种“先内存，后磁盘，顺序追加，后台合并”的机制，使其在写入吞吐量上具有天然优势。

资源占用与附加特性SQLite 以其极致的轻量著称。编译后的库大小仅几百KB，在嵌入式设备中可能只需要几百K的内存就够了。它无需任何外部依赖，真正实现了零配置。RocksDB 为了换取性能，资源占用较高。它需要分配大量内存用于 Block Cache（缓存热点数据）和 Bloom Filter（快速判断某个键是否存在，避免无效的磁盘查找）。它支持 Snappy、ZSTD 等多种压缩算法，能有效减少存储空间占用。 如何选择？

选择取决于你的具体应用场景：

在以下情况下，选择 SQLite：开发移动应用（iOS/Android）、桌面软件或资源受限的嵌入式系统。需要关系型数据模型、执行复杂查询或多表关联操作。数据操作多为读多写少，或写入是低频的、事务性的。部署简单性和开发便捷性是首要考虑因素。在以下情况下，选择 RocksDB：应用是写密集型的，需要处理海量数据的持续高速写入，例如日志记录、实时监控数据采集。系统需要很高的并发读写能力。作为分布式数据库的底层存储引擎（如 TiDB、CockroachDB）。你的数据模型本身就是简单的键值对形式，或者你可以接受在应用层构建更复杂的数据结构。 小结

总而言之，SQLite 和 RocksDB 是两款为不同目标而生的优秀数据库。

SQLite 像是瑞士军刀：轻便、通用、可靠，完美集成于应用内部，处理各种常见的数据管理任务。RocksDB 像是工业发动机：为高速、高吞吐量而生，驱动着那些需要处理海量数据的强大系统。