hydradb
hydra-db/hydradb加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
想象一个客服场景：用户"李明"三个月前反馈过产品 A 的一个问题，工程师张工当时解决了，但产品 A 后来又经历了一次架构调整，那个旧解决方案已经不再适用。如果你的 AI 客服只靠向量相似度检索，它会把张工当年的解决方案和最新的产品变更都返回给你——甚至可能把旧方案排在前面。
这不是搜索的错，而是相似度搜索的天然局限：它只能告诉你"内容相近"，无法告诉你"哪个版本是当前有效的"、"谁处理过这个问题"、"这个决定影响了哪些人"。
HydraDB 解决的就是这个问题。它是一个专为 AI 系统设计的图数据库，将用户、对话、事件、决策串成一张有向有环的图——而不仅仅是语义相似的文档列表。
HydraDB 由初创公司 AGI Context, Inc 开发，2025 年获得 600 万美元融资，投资方包括 Google DeepMind 前负责人 Jeff Dean、OpenAI 和 DeepMind 的研究员，以及 Sky9 Capital。公司的核心判断是：AI 系统的下一阶段瓶颈不是模型本身，而是"记忆"——模型需要持久化、结构化的上下文来支撑多轮对话、跨会话状态和真实世界知识关联。
传统图数据库（Neo4j、Memgraph 等）将数据存储在数据库服务器的本地磁盘或专用集群存储上。这种架构面临两个挑战：一是存储与计算耦合，扩容意味着要迁移整个数据库；二是基础设施成本随连接数增长迅速攀升。HydraDB 选择将对象存储（S3 兼容）作为数据的唯一持久化层，计算节点只保留缓存——类似于数据库版的"存算分离"架构。
项目基于 Rust 语言实现（Rust 1.91+），核心依赖 SlateDB（持久化存储引擎）和 SuiteSparse GraphBLAS（稀疏矩阵运算库）。
HydraDB 的运行时分为两个独立角色：
graph-node（数据节点）：接收查询和写请求。每个请求在 SlateDB 的快照上执行，保证强一致性。数据节点之间不直接通信，全部通过对象存储协调。
graph-indexer（索引器）：后台运行，从 WAL（预写日志）中读取增量变更，异步构建 CSC（压缩稀疏列）格式的拓扑索引，供查询加速。索引生成后通过原子指针发布，查询节点即时生效。
两者的本地 SSD/NVMe 缓存都是"可丢弃"的——节点崩溃后从对象存储重建，不会丢失已提交数据。这个设计让扩缩容几乎没有代价：加一个节点，旧节点下线，都不需要迁移图本身。
架构的核心不变量：
HydraDB 支持 OpenCypher 查询语言的精炼子集，包括：
| 能力 | 支持 |
|---|---|
| MATCH（单/多路径模式） | ✅ |
| WHERE 条件过滤 | ✅ |
| CREATE/MERGE 写操作 | ✅ |
| 变量长度路径 | ✅ |
| OPTIONAL MATCH | ✅ |
| UNION | ✅ |
| 原生路径过程（algo.SPpaths 等） | ✅ |
| RETURN * | ❌ |
| CREATE UNIQUE | ❌ |
应用层可以通过两种方式接入：
neo4j://127.0.0.1:7687），兼容路由和集群模式causal / strong）HydraDB 提供三种部署路径：
Docker（推荐开发/试用）：
docker pull ghcr.io/hydra-db/hydradb:latest
docker run --rm -p 7687:7687 -p 8443:8443 -p 9090:9090 \
-v "$PWD/hydradb-data:/data" \
-e CLOUD_PROVIDER=local \
-e LOCAL_PATH=/data/store \
-e GRAPH_AUTH_TOKEN_FILE=/data/auth-token \
-e GRAPH_ALLOW_PLAINTEXT=true \
ghcr.io/hydra-db/hydradb:latest
需要注意目录权限（容器以 UID 10001 运行）和 RUST_MIN_STACK=33554432 环境变量。
Helm Chart（生产/Kubernetes）：
helm upgrade --install hydradb charts/hydradb \
--namespace hydradb --create-namespace \
--values charts/hydradb/examples/values-eks.yaml \
--atomic --timeout 15m
生产环境需配置 TLS、对象存储凭证和节点 ID。
源码编译（开发）：需要 Rust 1.91+、libcypher-parser（解析 Cypher 语句）、SuiteSparse GraphBLAS（拓扑加速），通过 just native-check 和 just smoke 验证。
HydraDB 的典型使用场景是为 AI Agent 构建持久化记忆层。以客户支持 Agent 为例：
PERFORMED_IN / CONTEXT_OF 关系连接product_id，而非返回所有语义相似的产品VALID_FROM / VALID_TO 时间戳边，Agent 能区分"三个月前的解决方案"和"上周的架构变更"，确保不会引用已失效的信息官方数据：HydraDB 在 LongMemEval-S 评测集上总体准确率 90.79%，其中知识更新（Knowledge Updates）达 97.43%，时间推理（Temporal Reasoning）达 90.97%，均大幅领先 Mem0（29.07%）和 Zep（71.20%）。
HydraDB 目前的局限性值得注意：
OpenCypher 子集限制：不支持 RETURN *、事务批处理能力有限，部分复杂图算法需要应用层配合实现。
AGPL 许可证：如果你修改了 HydraDB 并作为网络服务分发，需要开源你的修改。对于闭源商业应用，需要购买商业许可证。
生态成熟度：相比 Neo4j（15年+）和 Memgraph，HydraDB 生态较新，驱动、工具链、社区资源还在积累阶段。
性能基准的独立性问题：LongMemEval-S 评测集由 HydraDB 团队自行发布，基准数据的选择和评分标准未经第三方独立验证，与 FalkorDB vs Neo4j 这类由社区推动的基准性质不同。
| 层次 | 技术选型 |
|---|---|
| 核心语言 | Rust 1.91+ |
| 存储引擎 | SlateDB（LSM-Tree on object storage） |
| 图算子内核 | SuiteSparse GraphBLAS |
| Cypher 解析 | libcypher-parser |
| 网络层 | Tokio（异步运行时） |
| 构建工具 | Cargo workspace |
| 容器化 | Docker（多阶段构建），Helm Chart |
| 监控 | Prometheus metrics，OpenTelemetry traces |
代码仓库结构：
src/core/：配置、图模型、缓存策略、错误类型src/shard/：存储生命周期、读写、路径过程src/engine/：路由、拓扑、不可变索引src/query/：OpenCypher 解析、代数、规划src/client/：Bolt、HTTP、认证、配额src/sparse_kernel/：Rust 稀疏矩阵 + GraphBLAS 执行crates/：placement 和 telemetry workspace cratesHydraDB 的核心价值主张是将对象存储变成图数据库的持久化层，从而实现真正的计算/存储分离。这让它在大规模 AI 上下文场景中具备成本优势和弹性扩缩能力，但代价是部署复杂度和生态成熟度。对于需要构建持久化记忆层、支持时间推理和实体消歧的 AI Agent 系统，HydraDB 是一个值得关注的技术选型；对于传统图数据分析场景，Neo4j 或 Memgraph 的成熟生态可能更合适。