hydra-db/hydradb

解决什么问题

用图数据库时通常要在两种麻烦之间选：自建集群里存储和计算绑在一起，扩容要搬数据、单节点故障要重建；或者用托管服务，换来成本和锁定。HydraDB 的做法是把 S3 兼容对象存储当作唯一可信的持久层，查询节点和索引节点只在内存和本地 SSD 上保留可丢弃的缓存，计算层因此可以随意扩缩和替换，而不必迁移图本身。

有什么不同

多数自托管图数据库把存储绑在提供查询的节点上，所以扩缩容是一次运维事件。HydraDB 把两层拆开，用对象存储的 CAS 租约加 SlateDB writer epoch 来选出并隔离每个 cell 的唯一写入者，并让每条查询固定在一个快照上以保证一致性读。遍历执行借助 GraphBLAS 稀疏线性代数，而不是纯迭代器模型；同时兼容 Bolt 5.x，现有 Neo4j 驱动可以直接接。代价在 README 里写得很明白：索引允许滞后，读仍然正确，因为会在索引基底之上叠加可见的 WAL 尾部。这和内存型或本地盘型图存储是两种不同的赌注。

适合谁

适合图负载大到对象存储明显比块存储便宜、并且已经有 S3 或兼容存储和 Kubernetes 式运维能力的团队；也适合想继续用 Neo4j 客户端但不想接受 Neo4j 部署模型的人。不适合单机嵌入式场景，不适合对延迟敏感、无法容忍索引滞后的遍历，也不适合不愿意维护带原生 C 依赖的 Rust 构建的人。

上手成本

README 对构建负担毫不掩饰：Rust 1.91+、C/C++ 工具链、libcypher-parser（不在 homebrew-core，需要加 tap）、SuiteSparse GraphBLAS。入门文档里没有现成的二进制或容器路径，只能用 just native-check / just smoke 验证，或用 cargo run --locked --features server-runtime --bin graph-node 起服务。配置是一长串环境变量，README 自己就提醒了栈溢出和 bindgen 头文件路径的坑。许可证是 AGPL-3.0，如果打算对外提供服务需要评估。文档在本地开发上很细，但对生产加固、备份和升级路径着墨很少。

点评

这是一个非常年轻的项目：2026 年 7 月创建，按信号时点约 113 天，约 13k stars，本月 Rust 榜 +8,451 排到第 11。这个年龄配上这个涨速，更像是发布期的冲高，而不是已经验证过的项目；没有 Hacker News 讨论、也没上过日榜，意味着缺少独立第三方的检验。对象存储原生图架构是一个可信且在变主流的方向，但运维层面的故事还没被证明。如果对象存储原生图在你的路线图上，值得做个原型；现在还不适合放到生产流量后面。