在 Go 后端、嵌入式设备、低配 VPS 等场景中，BoltDB（bbolt） 和 SQLite 是最常用的两款零配置、单文件嵌入式数据库。两者都满足「简单、轻量、无需独立服务」，但在并发模型、语言适配、使用方式和性能上差异巨大。
本文从设计定位、并发能力、Go 适配、硬件消耗、使用成本、适用场景六个维度完整对比，并给出直接可落地的选型结论。
一、基础定位对比
BoltDB（bbolt）
- 纯 Go 实现的键值（KV）嵌入式数据库
- 基于 B+ 树，ACID 事务，读写安全
- 无表结构、无 SQL、无索引语法，API 极度简洁
- 代表场景：etcd 底层存储、Go 服务本地状态、配置中心
SQLite
- 用 C 实现的关系型嵌入式 SQL 数据库
- 支持完整 SQL 语法、事务、索引、联表查询、触发器
- 行业标准嵌入式数据库，几乎所有语言都支持
- 代表场景：APP 本地存储、桌面软件、小型网站数据
二、并发能力（核心差异）
BoltDB：高并发读为王
- 使用 读写锁（tx 事务） 模型
- 读事务完全并行：成千上万个协程同时读取不阻塞
- 写事务串行，但单次写入极快
- 高并发读场景下几乎无性能损耗
- 不会出现"database locked"类问题
SQLite：并发能力有限
- 默认模式：读写完全互斥
- 开启 WAL 模式后：读并行、写串行
- 高并发写入下极易出现锁等待
- 大量读写混合场景容易卡顿、报错
- 不适合高频读写的 Go 高并发服务
结论
高并发读、Go 协程密集场景 → BoltDB 完胜
三、Go 语言适配（决定部署体验）
BoltDB
- 纯 Go 编写，无 CGO
- 交叉编译极其简单：
CGO_ENABLED=0 go build - 最终产出单个二进制文件，无任何依赖
- 跨平台（Linux/macOS/Windows）零差异
- 编译速度快，无链接错误
SQLite
- 底层依赖 C 语言库
- 必须开启 CGO，编译慢、易报错
- 交叉编译复杂，常缺依赖库
- 部分平台（如轻量容器）需要额外安装依赖
- 无法做到真正"单文件分发"
结论
Go 项目追求极简部署、无依赖 → BoltDB 完胜
四、硬件资源消耗（低配机器关键）
BoltDB
- 内存占用极低，使用 mmap 映射磁盘
- 数据不全部载入内存，用多少加载多少
- 1核 64MB 内存可稳定跑
- CPU 占用极低
SQLite
- 内存管理依赖 C 层，开销相对更高
- 查询、索引、SQL 解析会消耗额外资源
- 建议至少 128MB 以上内存
- 复杂查询会明显占用 CPU
结论
极低配置设备、IoT、小容量 VPS → BoltDB 更优
五、使用成本与开发效率
BoltDB
- 无 SQL、无建表、无迁移
- API 只有：Put / Get / Delete / 事务
- 上手 5 分钟，代码量极少
- 结构简单，几乎无 bug
go
db.View(func(tx *bbolt.Tx) {
val := tx.Bucket([]byte("user")).Get([]byte("id1"))
})SQLite
- 需要建表、写 SQL、处理字段
- 可搭配 ORM（GORM），但仍有学习成本
- 需处理字段类型、索引、版本迁移
- 功能强大，但代码更重
sql
SELECT * FROM users WHERE id = ?结论
追求极简开发、快速迭代 → BoltDB 更优
六、功能强度对比
BoltDB
- 仅 KV 存储
- 不支持范围查询、模糊匹配、联表、聚合
- 数据结构简单，适合键值对场景
SQLite
- 完整 SQL 能力
- 支持 JOIN、GROUP BY、LIKE、事务、索引、视图
- 可处理复杂业务关系
- 多语言、多程序可共享同一数据库
结论
需要复杂查询、多语言访问 → SQLite 唯一选择
七、适用场景总结
优先选择 BoltDB，如果：
- 你在写 Go 服务/工具
- 需要高并发读
- 部署要极简单文件
- 硬件配置极低（64MB/128MB）
- 数据模型简单（KV 即可满足）
- 不想处理 SQL、表结构、迁移
优先选择 SQLite，如果：
- 需要复杂查询、联表、统计
- 多语言（Python/Java/JS）访问同一数据文件
- 数据关系复杂，必须用 SQL
- 项目不是 Go 为主
- 数据量较大且需要高效索引查询
八、一句话最终总结
- Go 项目 + 高并发 + 低配 + 简单存储 = BoltDB（bbolt）
- 多语言 + 复杂查询 + 关系型数据 = SQLite
在追求简单、安全、高并发、低硬件消耗 的 Go 系统设计中，BoltDB 是比 SQLite 更现代、更适配的选择。