BlitzGraph is a backend service for graph databases, designed as an AI-native alternative to Supabase tailored for LLM agents.
Hello HN
After becoming allergic to SQL, I opened 120+ issues in Dgraph, Typedb and surrealdb looking for the perfect graphDB. None of them was built for agents nor were they the perfect fit for what we wanted to achieve: fully ditching the SQL legacy to properly model reality. So we decided to build BlitzGraph<p>In BlitzGraph, records (units) can belong to multiple types (kinds) and evolve through time. Also polymorphic relations are first class and multiple kinds can play the same role. This design helps to escape the old table paradigm and track entities throughout their lifecycle without awkward self-joins that connect an entity to itself under different IDs in other tables<p>An example:<p><pre><code> { "$id": "amazn", "$kinds": ["Company", "Prospect"], deal: ... } // Day 1
{ "$id": "amazn", "$kinds": ["Company", "Customer"], contract: .. } // Day 7
{ "$id": "amazn", "$kinds": ["Company", "Churned"], churnCause: "..." }, ... // Day 86
</code></pre>
What makes BlitzGraph different:<p><pre><code> - GraphQL-like nested queries and mutations https://blitzgraph.com/docs - Polymorphic records and relations
- Bidirectional O(1) relations - Referential integrity with native cardinality validations
- JSON query/mutation language designed so AI agents can build them programatically - Batched queries/mutations without N+1 issues
- Built-in frontend engine for quick dashboards and MVPs - Native full text search, file storage, computed fields, ephemeral subspaces, unit history...
</code></pre>
Honest comparisons:<p>- vs typedb: amazing db, but not ideal for app development. On the other hand we loved and brought their inference ideas and how mutations execute smartly instead of line per line - vs surrealdb: Several core differences, a key one is that we run validations and trasnformations in topological order, and our edges are first class citizens - vs dgraph: Their cool features like post commit hooks were attached to the graphQL layer, in BG it is fundational - neo4j: If you've tried it, you know - vs supabase/pg: BG is slower for flat queries but faster in nested ones. But with BG mainly you get rid of the tables paradigm and jump into the graph world while being able to build apps<p>Not ready:<p>- While blitzgraph is already an excellent memory backend for AI agents, we still need to finish the semantic search engine
- Query planner is not optimized
- Cloud frontends have no native auth engine yet<p>Beta is live, please break things!
- Public playground: <a href="https://blitzgraph.com/#playground" rel="nofollow">https://blitzgraph.com/#playground</a>
- MCP: <a href="https://blitzgraph.com/mcp" rel="nofollow">https://blitzgraph.com/mcp</a>
LatticeDB is an embedded property-graph database that integrates vector and full-text indexing into a single-file format, enabling graph traversal, similarity search, and BM25 search in one query layer for local applications.
A curated collection of research papers, benchmarks, and open-source projects on Graph Engineering in the era of LLM Agents, accompanying an arXiv survey paper to advance research from individual to system intelligence.
Introduces GraphARC, an MIT-licensed open-source tool that lets a model author agent graph topologies at runtime, with a deterministic admission gate for auditable execution, built on LangGraph and running locally via ollama or against cloud APIs.
This paper introduces Graph Engineering as an emerging paradigm for organizing multi-agent LLM systems using dynamic graph structures to coordinate specialized agents and manage complex tasks, advancing from individual to system intelligence.
HelixDB is a graph-vector database built in Rust for knowledge graphs and AI memory, offering a unified platform that supports graph, vector, KV, document, and relational data models, with tools for easy local and cloud deployment.