Show HN: BlitzGraph – Supabase for graphs, built for LLM agents
blitzgraph.comHello 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
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
An example:
{ "$id": "amazn", "$kinds": ["Company", "Prospect"], deal: ... } // Day 1
{ "$id": "amazn", "$kinds": ["Company", "Customer"], contract: .. } // Day 7
{ "$id": "amazn", "$kinds": ["Company", "Churned"], churnCause: "..." }, ... // Day 86
- 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...
- 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
Not ready:
- 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
Beta is live, please break things! - Public playground: https://blitzgraph.com/#playground - MCP: https://blitzgraph.com/mcp
"BlitzGraph beta · data may be wiped without notice · expect resets"
This is not beta. This is alpha.
- - -
After becoming allergic to SQL, I opened 120+ issues in Dgraph, Typedb and surrealdb looking for the perfect graphDB.
What were those 120+ issues supposed to do?
That sounds suspiciously like something OpenClaw would think is a good idea. And surely only an agent would think it a good idea to brag about here.
Fair! We haven't wiped storage so far and we do multiple daily backups, to speed up development I'd rather keep that warning there until we implemente a proper migration engine and enable payments.
On the issues: those were filed by hand over a couple of years trying to ship products on these DBs. Probably came across as bragging but the point was that I spent a big chunk of my life digging into graph and modern databases, and the gaps pushed me to give up and build one that gathers all their best ideas
> I opened 120+ issues in Dgraph, Typedb and surrealdb looking for the perfect graphDB
Can you share some examples? What was wrong with those?
Hello! I would say about 50% of them were bugs, 25% were features/mechanisms I loved from the the other ones, and 25% trying to push a better way to model things, which is what I never got in none of them. Typedb would be close if entities could evolve and belong to multiple types, as well as if they focused on making it adapted for app creation, but it wasn't their priority. In surrealdb I opened several issues around enhancing the graph db part, add some topological ordering to mutations the way typedb does it and several other topics. The most recent ones are in surrealdb's repo: https://github.com/surrealdb/surrealdb/issues?q=is%3Aissue%2.... Half of them have been achieved but the other half remains. With blitzgraph I tried to take the best ideas and pracrices from each, keep the tradeoffs loww, and lean as hard as possible into being AI-agent-first
what makes you say that you're more suitable for agents compared to say neo4j and typedb? is it the temporal modeling?
congratulations for the beta by the way!
Hello! Temporal modeling is one piece, but the key things are performance (neo4j is a pain as murmansk said) and the AI-agent-centered design. It means everything has been tested from an agent point of view and we automatically gather agents' feedback to close self-improvement loops. Beyond the MCP, there are several agent-specific features, since long-term we want to compete with context layers like Mem0 or Cognee ,but natively, without the glue they need.
Say you want to build a context layer for your company with BlitzGraph. Agents would use ephemeral subspaces to gather as much info as possible prior to re-categorize it, store files natively, keep episodic memories, track everything that happens to each memory or record with the native $history. Also the query language is in JSON, so it's easy to build programatically, it'sis strongly typed, and errors are written to guide agents to fix them. Agents can also batch-query docs, which are dense and straight to the point for token optimization (and the discovery tree for related docs is also optimized for them)
The long term objective is to become the "brain" or logic/storage layer of AI agents
Not the blitz author. Neo4j was freaking slow when I tried to use it.
Yeah, perf was a big motivator. I still have nightmares with Cypher and neo4j's slowness. Thanks for jumping in!
Just build a decent rdf database, with SPARQL, basic inferencing and SHACL support rather then reinventing another thing
Considered it, but it didn't fit our constraints-driven design ("this must have exactly one author"), first-class edges, polymorphism and JSON DX. SPARQL is a string query language which is exactly the kind of "build the query as txt and pray" that I wanted agents to avoid. BQL is more like graphQL but with a fully typed JSON shape, and batched, nested, topologically-ordered mutations built in.
We did borrow the inference ideas tho, the inference/recursive relations are on the oven!
have never tried them before. do you have to configure/assemble these things? do you then run them as separate processes?
SQL isn't an allergy. It's time test. Take medicine to fix your allergy.
Supa, Burschi!