Show HN: BlitzGraph – 专为 LLM 智能体设计的图数据库后端

背景

在 AI 原生应用（AI-native applications）迅速发展的当下，传统的后端架构正面临严峻挑战。长期以来，开发者依赖关系型数据库（如 PostgreSQL）或文档数据库（如 MongoDB）来存储数据，并通过 SQL、ORM（对象关系映射）或 REST API 与应用程序交互。然而，这种基于“表”和“列”的思维模式，与大型语言模型（LLM）智能体（Agents）处理数据的方式存在天然隔阂。

LLM 智能体擅长处理结构化的 JSON 数据，而非复杂的 SQL 字符串或繁琐的 JOIN 操作。传统的数据库架构要求开发者编写大量的胶水代码来处理实体关系、多态性以及实时数据同步，这不仅增加了开发复杂度，也限制了智能体在动态环境中的灵活性。

在此背景下，BlitzGraph 作为一个“AI 原生后端”应运而生。它自称是“图数据库领域的 Supabase”，旨在通过一种全新的数据建模和查询方式，让智能体能够直接、高效地操作现实世界的数据模型。其核心理念是“想法输入，API 输出”，让开发者无需关心底层的 SQL 或 ORM，而是通过类型化的 JSON 查询语言（BQL）来构建后端。

核心内容

BlitzGraph 重新定义了数据建模和查询的方式，其核心特性围绕“实体”和“关系”展开，而非传统的“表”和“列”。

1. 数据建模：模拟现实而非表格

BlitzGraph 摒弃了传统数据库中将实体拆分到多个表中的做法，转而采用更贴近现实的建模方式：

• 多类型实体（Multi-kind entities）：一个实体可以同时拥有多种身份。例如，一个 User 实体可以同时是 Admin（管理员）和 Moderator（版主）。这种“类型”（Kinds）可以随时间动态增加或减少，无需创建新表或执行复杂的数据库迁移（Migrations）。
• 双向关系（Bidirectional relationships）：在 BlitzGraph 中，关系是双向存储的。查询“谁写了这篇文章”和“这篇文章的作者写了什么”具有相同的成本和索引效率，均为 O(1) 复杂度。这消除了传统数据库中需要反向查找表或额外查询的开销。
• 丰富的内容类型：除了基本的字符串，数据库原生支持 EMAIL、URL、DATE、JSON 和 FLEX 等类型，并在数据库层面提供内置验证，确保数据结构符合实际语义。

2. 查询语言：BQL（BlitzGraph Query Language）

BlitzGraph 引入了 BQL，这是一种专为智能体设计的结构化 JSON 查询语言，旨在解决 SQL 和 GraphQL 在 AI 场景下的局限性：

• 智能体友好：SQL 迫使智能体生成字符串并猜测结果形状，而 BQL 允许智能体从代码中构建类型化的 JSON 对象。查询本身就是数据结构，没有解析歧义。
• 类 GraphQL 的读取体验：支持根实体获取、关系展开（$expand）、嵌套字段投影、过滤、排序和限制。与 GraphQL 不同，BQL 不需要繁琐的模式定义（Schema ceremony）。
• 通过关系过滤：允许直接通过连接的数据进行查询（如遍历会话、记忆、所有者），而无需在应用代码中拼接 JOIN 语句。
• 零 N+1 问题：所有过滤、嵌套展开和全文搜索都在单次请求中完成，彻底解决了传统数据库查询中的 N+1 性能瓶颈。

3. 数据完整性与业务逻辑

BlitzGraph 将许多传统上由应用层处理的功能下沉到数据库引擎层：

• 引用完整性：在引擎层面强制执行基数约束和 onDelete 策略（级联、限制、取消链接），确保图数据的一致性。
• 内置全文搜索：原生集成 BM25 引擎，支持类型ahead、前缀、精确和所有词干模式，无需外部服务如 Elasticsearch。
• 智能事务：突变操作（Mutations）经过拓扑排序，并在最终结果上进行验证，而非逐行验证。这意味着业务规则检查的是整个事务的最终状态，确保复杂的多实体操作要么全部成功，要么全部回滚。
• 数据库中的业务逻辑：验证、计算字段、转换和效果均在模式中定义，使业务规则与数据共存，避免了逻辑分散在中间件和应用代码中的问题。

4. 与主流数据库的对比

BlitzGraph 在多个维度上与传统数据库形成了鲜明对比：

• vs Supabase (PostgreSQL)：Supabase 基于列思维，实体变化需要角色表、新表和 JOIN。BlitzGraph 允许实体自由组合类型，关系双向存储，查询即数据结构。
• vs Convex (文档数据库)：Convex 基于文档思维，文档间缺乏真正的关系。BlitzGraph 将关系视为一等公民，支持双向弧和级联策略。
• vs Mongo Atlas (集合)：Mongo 使用扁平文档，实体演化需要类型字段和条件判断。BlitzGraph 允许实体自然生长和组合，同一 ID 可拥有不同能力。
• vs Neo4j (图数据库)：Neo4j 使用 Cypher 字符串查询，节点标签扁平且无模式。BlitzGraph 使用结构化 JSON 查询，实体属于多种类型，继承字段和关系，多态性是核心模型。

5. 集成与使用

BlitzGraph 提供了便捷的集成方式，特别是针对 AI 开发场景：

• MCP Server 支持：开发者可以将 BlitzGraph 添加为远程 MCP（Model Context Protocol）服务器，直接连接 Claude 或 Codex。
  • Claude 集成命令：claude mcp add --transport http blitzgraph https://blitzgraph.com/mcp
  • Codex 集成命令：codex mcp add blitzgraph --url https://blitzgraph.com/mcp
• 自动认证：用户只需在浏览器中登录一次，智能体即可自动使用工具，无需复杂的令牌管理。
• 实时数据：无需账户即可访问实时数据，包含查询、钩子、验证和计算字段。

关键要点

• AI 原生架构：BlitzGraph 专为 LLM 智能体设计，通过类型化的 JSON 查询（BQL）替代 SQL，使智能体能更准确地理解和操作数据。
• 动态实体建模：支持多类型实体（Multi-kind entities），实体可随时间动态获得或失去“类型”，无需数据库迁移，灵活适应业务变化。
• 高效双向关系：关系在存储时即为双向，查询复杂度为 O(1)，消除了反向查找和额外 JOIN 的性能开销。
• 结构化查询语言：BQL 允许智能体从代码构建 JSON 对象，避免了 SQL 字符串生成的歧义和错误，支持单次请求完成复杂的数据获取和过滤。
• 内置高级功能：集成原生 BM25 全文搜索、引用完整性约束、智能事务验证以及数据库层面的业务逻辑（验证、计算字段），减少应用层代码负担。
• 简化集成：提供 MCP Server 支持，可直接连接 Claude 和 Codex，实现自动认证和实时数据访问，降低 AI 应用后端开发门槛。
• 对比优势：相比 Supabase、Convex、MongoDB 和 Neo4j，BlitzGraph 在实体演化、关系处理、查询结构化和 AI 兼容性方面具有独特优势，特别适合需要复杂关系和动态数据模型的应用场景。

意义与影响

BlitzGraph 的出现标志着后端开发范式的一次重要转变。它不再仅仅是一个数据存储工具，而是作为 AI 智能体的“大脑”延伸，直接参与数据的语义理解和操作。

首先，它解决了 AI 应用开发中的“最后一公里”问题。长期以来，将 LLM 的能力与持久化数据结合是一个痛点，因为 SQL 和 ORM 对智能体来说过于复杂且易出错。BlitzGraph 通过 BQL 提供了一种智能体原生友好的接口，使得智能体能够像人类开发者一样，以结构化的方式思考和查询数据。

其次，它简化了复杂业务逻辑的实现。通过支持多类型实体和双向关系，BlitzGraph