BriskDB 把 SQLite 做成分片数据库：并行写入换来了哪些分布式成本

开源项目 BriskDB 尝试把多个普通 SQLite 文件组合成一个逻辑数据库。每个分片保留独立 WAL 和写锁，路由层负责分配数据、生成跨分片不冲突的 ID，并通过 PostgreSQL、HTTP、Rust 和 Python 接口提供访问。

一句话结论：BriskDB 绕开了单个 SQLite 文件的写锁，却没有消除分布式数据库问题；事务、全局索引、备份和重分片成本只是从存储引擎移到了路由层。

SQLite 的优势是简单、成熟、文件可检查，但同一个 WAL 同时只有一个写者。BriskDB 让不同键落入不同 SQLite 文件，因此独立 WAL 可以并行写入。数据文件没有采用 SQLite 分叉，仍能用现有工具打开，这让故障排查和离线迁移更直接。

项目提供两种分片安全 ID。native_range_v1 给每个分片分配不重叠的正 64 位整数区间，仍由 SQLite 自己执行自增；另一种方案面向分布式生成。路由清单、虚拟桶和元数据保存在单独的 manifest 中，使逻辑分片与物理文件解耦。

代价写在项目 README 里：当前没有跨多个分片的一般原子事务，全局排序、分页和聚合下推仍有限；跨分片全局索引属于实验功能，会引入写入延迟和恢复复杂度。备份要求所有服务与嵌入进程停止后复制完整数据目录，在线快照尚未实现。

权限和运维也未完成。PostgreSQL 接口有 TLS 与单一身份 SCRAM-SHA-256，但还没有角色和授权体系；HTTP 仅用于本机开发；多进程共享限定同一主机和本地文件系统。项目明确标注为 alpha，1.0 前存储与公共 API 可能变化。

关键事实

• 架构：多个普通 SQLite WAL 文件加路由、清单和全局索引层
• 收益：不同分片可并行写入，不修改 SQLite 存储格式
• 限制：无通用跨分片原子事务，排序、聚合和在线备份有限
• 状态：alpha，不建议作为生产数据库服务

OC 判断

BriskDB 的方向适合“单机 SQLite 已撞上写竞争，但还不想迁移完整数据库集群”的团队。先别急着激动：一旦业务需要跨分片事务、复杂联表和不停机备份，项目就进入分布式数据库最昂贵的部分。可检查文件是优势，不是免运维许可证。

为什么重要

• 对开发者：现有 SQLite 工具链可以保留，但查询模型必须接受分片边界。
• 对团队：应先测真实写热点和事务范围，再决定分片是否比迁移更便宜。
• 对项目使用者：alpha 阶段更适合实验和贡献，不适合承载关键生产数据。

参考来源

• BriskDB repository