一、基础属性对比

维度	redb	SQLite (rusqlite)
语言	纯 Rust	C 核心 + Rust FFI 封装
数据模型	键值对 (B+Tree)	关系型 (SQL)
最新版本	v2.6.3 (2026.02)	v0.39.0 (rusqlite)
crate 大小	195 KiB / 18K SLoC	~1.5 MiB (bundled) / 含 C 编译
许可证	MIT / Apache-2.0	MIT (rusqlite) + Public Domain (SQLite)
成熟度	1.0+ 稳定版	工业级，30年历史
下载量	122K (all time)	40M+ (all time)

二、对本项目的关键维度对比

2.1 编译与构建

维度	redb	SQLite (rusqlite)
交叉编译	零障碍，纯 Rust	需 C 交叉编译工具链 (bundled 模式需 cc crate)
编译时间	快 (~10s)	慢 (~60s+，bundled 模式编译 SQLite C 代码)
构建依赖	无外部依赖	libsqlite3-sys 需 C 编译器或系统 SQLite
Tauri 集成	直接 cargo add	需 bundled feature 或系统库，Windows 上常见构建问题

对本项目影响：项目已有 Tauri 构建链，但 SQLite 的 C 编译在 Windows 上偶发链接问题（尤其是 MSVC 工具链）。redb 纯 Rust 零额外构建依赖，与 Tauri 构建链完全兼容。

2.2 二进制体积

维度	redb	SQLite (rusqlite bundled)
静态链接增量	~200-300 KB	~1.5-2 MB (含 SQLite C 库)
当前项目 release 体积	基线	基线 + 1.2-1.7 MB

对本项目影响：项目当前 release profile 使用 opt-level = "s" + strip = true，对体积敏感。redb 增量约 200KB，SQLite 增量约 1.5MB。

2.3 数据模型适配度

本项目配置数据结构：

AppConfig
├── BinariesConfig     (2 个 String 字段)
├── PathsConfig        (1 个 String 字段)
├── LocaleConfig       (1 个 String 字段)
├── TimeoutsConfig     (1 个 u64 字段)
├── EventsConfig       (6 个 String 字段)
├── PluginsConfig      (1 个 Vec<String> 字段)
├── ParsingConfig      (9 个 String 字段)
└── EnvVarsConfig      (3 个 HashMap<String, EnvVarEntryConfig>)

维度	redb	SQLite
简单键值	原生支持，Table<&str, &str>	需建表 + SQL，过度工程
Vec 类型	JSON 序列化存储	可用 JSON 列或关联表
HashMap 类型	JSON 序列化或逐条存储	关联表更自然
查询模式	全部是点查询/范围扫描	SQL 查询能力远超需求
数据量	<100 个键	<100 行

结论：本项目数据全是点查询，无复杂关联/聚合需求。redb 的键值模型天然匹配；SQLite 的关系模型属于过度设计。

2.4 性能对比

基于公开基准测试数据（redb 官方 benchmark、Native DB/Redb/SQLite 对比）：

操作	redb	SQLite	本项目场景
单键读取	~0.5-1μs	~1-2μs	主力操作，redb 更快
批量写入	中等	快	仅迁移时一次
范围扫描	O(log n)	SQL 优化器	env_vars 按类别扫描
并发读	MVCC 无锁读	WAL 模式无锁读	两者均满足
启动打开	O(1)	O(1)	两者持平

对本项目影响：配置数据量极小（<100 键），两者性能差异可忽略。redb 在点查询上略快，SQLite 在批量写入上略快，但都不是瓶颈。

2.5 运行时安全与可靠性

维度	redb	SQLite
内存安全	Rust 保证，无 unsafe FFI	C 核心，历史上有 CVE
崩溃恢复	ACID，copy-on-write B+Tree	ACID，WAL/rollback journal
数据损坏	极少发生，有 check_integrity()	极少发生，有 PRAGMA integrity_check
杀毒软件误报	无 C 代码，低风险	SQLite DLL 偶发误报

对本项目影响：redb 纯 Rust 无 FFI，不存在 C 层面的内存安全漏洞。Windows 上杀毒软件对 SQLite DLL 的误报是实际问题。

2.6 开发体验

维度	redb	SQLite
API 风格	BTreeMap 式，类型安全	SQL 字符串，运行时校验
Schema 管理	代码定义 Table，编译时检查	需 migration 脚本
调试	不可人工阅读二进制	可用 sqlite3 CLI 直接查询
数据迁移	代码逻辑控制	SQL migration 框架成熟
学习曲线	低（5 个核心类型）	中（SQL + rusqlite API）

2.7 生态与长期维护

维度	redb	SQLite
维护者	单人 (cberner)，活跃	SQLite Consortium + rusqlite 团队
Tauri 插件	无官方插件	有 tauri-plugin-sql、tauri-plugin-rusqlite2
社区规模	小众，1.5K GitHub Stars	工业标准，rusqlite 4K+ Stars
未来扩展	键值模型，扩展受限	SQL 支持复杂查询、索引、触发器
风险	单人维护，bus factor 低	几乎无维护风险

三、综合评分矩阵

评估维度	权重	redb 得分	SQLite 得分
数据模型匹配度	25%	9 (天然键值)	5 (过度工程)
编译构建便利性	15%	9 (纯 Rust)	5 (C 编译链)
二进制体积影响	10%	9 (+200KB)	4 (+1.5MB)
运行时安全性	10%	9 (无 FFI)	6 (C 核心)
开发效率	15%	8 (类型安全)	6 (SQL 字符串)
生态与长期维护	15%	5 (小众)	9 (工业标准)
未来扩展性	10%	4 (键值局限)	9 (SQL 全能)
加权总分		7.85	6.15

四、选型建议

推荐：redb

核心理由：

1. 数据模型天然匹配：本项目配置数据是扁平键值对，无关联查询需求。用 SQL 处理键值对是杀鸡用牛刀
2. 纯 Rust 零构建摩擦：与 Tauri 构建链无缝集成，无 C 编译器依赖，无 Windows 链接问题
3. 体积敏感：桌面应用分发体积是实际考量，redb 增量仅为 SQLite 的 1/7
4. 内存安全：无 C FFI 边界，无 CVE 风险，无杀毒软件误报

何时应选 SQLite

如果未来项目演进出现以下需求，应重新评估：

• 需要存储用户操作历史/审计日志（写入密集型）
• 需要复杂关联查询（如"哪些工具链安装了 clippy 组件"）
• 需要全文搜索（如搜索环境变量描述）
• 需要多进程并发写入

迁移路径保留

即使选择 redb，仍可保留未来迁移到 SQLite 的路径：

• 配置访问通过 config.rs 抽象层封装，底层存储可替换
• 数据序列化使用 JSON，与 SQLite 的 JSON 列兼容
• AppConfig 结构体作为统一数据模型，与存储层解耦

Sources:

• redb GitHub Repository
• redb 1.0 Release & Benchmarks
• Native DB / Redb / SQLite 性能评测
• redb Storage Size Discussion
• rusqlite crates.io
• repo-recall: redb vs SQLite 选型讨论