最新

你好，HN 在对SQL产生过敏后，我在Dgraph、Typedb和SurrealDB中打开了120多个问题，寻找完美的图数据库。然而，它们都不是为代理（agents）构建的，也无法完全满足我们想要实现的目标：彻底摆脱SQL的遗留，正确地建模现实。因此，我们决定构建BlitzGraph。 在BlitzGraph中，记录（单位）可以属于多种类型（种类），并随着时间的推移而演变。此外，多态关系是第一类公民，多个种类可以扮演相同的角色。这种设计有助于摆脱旧的表格范式，并在整个生命周期中跟踪实体，而无需通过不同表中不同ID的自连接来连接实体。 一个例子： ```json { "$id": "amazn", "$kinds": ["Company", "Prospect"], deal: ... } // 第一天 { "$id": "amazn", "$kinds": ["Company", "Customer"], contract: .. } // 第七天 { "$id": "amazn", "$kinds": ["Company", "Churned"], churnCause: "..." }, ... // 第八十六天 ``` BlitzGraph的不同之处： - 类似GraphQL的嵌套查询和变更 https://blitzgraph.com/docs - 多态记录和关系 - 双向O(1)关系 - 具有原生基数验证的引用完整性 - 设计用于AI代理可以程序化构建的JSON查询/变更语言 - 批量查询/变更，无N+1问题 - 内置前端引擎，快速创建仪表板和MVP - 原生全文搜索、文件存储、计算字段、短暂子空间、单位历史记录... 诚实的比较： - 与Typedb相比：很棒的数据库，但不适合应用开发。另一方面，我们喜欢并引入了他们的推理理念，以及变更如何智能地执行，而不是逐行执行。 - 与SurrealDB相比：有几个核心差异，一个关键点是我们以拓扑顺序运行验证和转换，而我们的边是第一类公民。 - 与Dgraph相比：他们的一些酷功能，如提交后钩子，附属于GraphQL层，而在BG中它是基础性的。 - Neo4j：如果你尝试过，你就知道了。 - 与Supabase/PG相比：BG在平面查询上较慢，但在嵌套查询上更快。但使用BG，主要是摆脱了表格范式，跳入图形世界，同时能够构建应用。 尚未准备好： - 虽然BlitzGraph已经是AI代理的优秀内存后端，但我们仍需完成语义搜索引擎。 - 查询规划器尚未优化。 - 云前端尚未具备原生认证引擎。 Beta版本已上线，请尽情测试！ - 公共游乐场：[https://blitzgraph.com/#playground](https://blitzgraph.com/#playground) - MCP：[https://blitzgraph.com/mcp](https://blitzgraph.com/mcp)