HelixDB：图+向量一体数据库，Rust 自研 5.6K⭐，AI 应用首选

做 AI 应用最烦的是什么？我的答案是：数据库太多。

搞 RAG 要一个向量库（Pinecone、Qdrant），存用户数据要一个关系库（PostgreSQL），做知识图谱又得一个图库（Neo4j）。然后还要折腾中间件把这些串起来，光配连接池就能配一整天。

HelixDB 想解决的就是这个问题——一个数据库，搞定图、向量、KV、文档、关系型数据。用 Rust 从头自研，YC 孵化，昨天刚发了 v3.0.8。目前 GitHub 5.6K ⭐，社区挺活跃。

HelixDB 封面图

这玩意怎么用

HelixDB 是一个 OLTP 图-向量数据库（graph-vector database），直接用对象存储（Object Storage）做底层，不需要依赖本地磁盘。

它的核心思路是：AI 应用需要的各种数据模型，与其满世界拼凑，不如一个数据库全包了。Graph（关系图谱）+ Vector（向量检索）+ KV（键值对）+ Document（文档）+ Relational（关系型），五合一。

项目是用 Rust 写的，Apache-2.0 开源，有 Rust、Python、TypeScript、Go 四个官方 SDK，覆盖了主流技术栈。

HelixDB 官网首页

这是最实在的卖点。以前做 AI Agent，内存用向量库存、用户数据用关系库存、Agent 之间的关联用图库存——三个数据库三套 API。HelixDB 一条查询就能搞定跨模型的联合检索。比如「找出最近活跃的用户，找到他相关的文档，做语义相似度排序」，在一个请求里就能完成。

项目从零开始在 Rust 里手写，没有套壳别的数据库。这样做的优势是：底层存储引擎、查询执行器、索引结构全在自己的控制范围内。对于 OLTP 场景，延迟和吞吐都有保障。

HelixDB 用对象存储（S3 兼容）而不是本地磁盘。这意味着：存多少数据不用担心磁盘不够，扩容理论上没上限。Cloud 版本支持自动扩展读节点，3+ 网关和数据库节点高可用。

helix chef 一条命令，交互式问答后自动搭好本地实例、写入示例数据、生成项目脚手架。如果你装了 Claude Code 或 Codex，它还能直接把项目交给 AI 继续开发。这个体验做得不错，大大降低了上手门槛。

不像传统数据库写 SQL，HelixDB 用代码 DSL 写查询——Rust 宏、Python 链式调用、TS 函数式。查询不是拼字符串，是编译期或运行时构造的 AST。这样既安全，又能动态组装复杂查询。

2024 年 11 月才创建，虽然迭代很快（昨天 v3.0.8），但生态还不够成熟。文档虽然齐全，但很多高级用法社区讨论不多，踩坑只能靠自己看源码。

helix start dev 默认跑在内存里，实例一停数据全丢。要持久化得加 --disk 参数。这个设计对快速体验友好，但新手可能不注意就丢数据了。

查询用 DSL 而不是 SQL，熟悉关系数据库的人要重新适应。特别是图查询 + 向量检索的组合语法，需要理解数据模型才能写出高效查询。文档里有个 Querying Guide，但篇幅不小。

看文档和仓库方向，HelixDB Cloud 才是商业主力——分布式、高可用、自动扩展。开源版跑本地开发和小项目够用，但大规模生产部署大概率要上 Cloud。

Neo4j 图查询更强，生态也稳（人家 20 年了）。但 HelixDB 向量+图一体，Rust 写的性能好，部署也轻。

Qdrant 和 Pinecone 这种纯向量库，只能「找相似」。HelixDB 能表达实体关系——比如找「和某用户兴趣相似的人收藏过的文档」，向量库做不了。

PostgreSQL + pgvector 基础向量检索够了，但图查询是硬伤。HelixDB 的复杂查询表达力强很多。不过 PG 的生态和稳定性，短期内谁也追不上。

说真的，如果你在做 AI Agent 或 RAG 系统，需要同时处理关系、向量和图的联合查询，HelixDB 值得关注。它还太新，但方向是对的，技术底子也硬。小项目先拿本地版本玩玩，生产环境等 Cloud 再稳一稳。

标签：#HelixDB #图数据库 #向量数据库 #RAG #知识图谱 #AI开发平台 #Rust

关注我，每期分享一个帮你省事的强大工具 🛠️