BlitzGraph
Supabase for graphs, built for LLM agents
Details
- External ID
- 48557002
- Source
- HN
- Company
- —
- Product
- BlitzGraph
- Website domain
- blitzgraph.com
- Launched
- June 16, 2026
- Cohort
- —
- Upvotes
- 15
- Upvotes percentile
- 0.703551912568306
- Tags
- —
- Fetched at
- Sept. 7, 2026, 9:26 p.m.
- Updated at
- Sept. 7, 2026, 9:26 p.m.
Description
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 BlitzGraphIn 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 tablesAn 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 What makes BlitzGraph different: - 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... Honest comparisons:- 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 appsNot 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 yetBeta is live, please break things! - Public playground: https://blitzgraph.com/#playground - MCP: https://blitzgraph.com/mcp
Enrichment
- Theme
- database infrastructure and developer tools
- Vertical
- —
- Function
- Data infrastructure
- Audience
- Developer
- AI stance
- AI-native
- Project type
- Commercial product
- Normalized one-liner
- graph database platform for llm agents
- Manually corrected
- False
Could you build this?
No BlitzGraph is a custom graph database and Backend-as-a-Service engine built from scratch with its own query language (BQL), storage layout, and auth system. Building a resilient, performant database and distributed BaaS requires deep systems and database engineering expertise.
What it would actually take: The system requires designing a custom transactional storage engine (or heavily modified LSM/B-tree engine), a graph query planner and executor, multi-tenant workspace routing, and an MCP/OAuth server layer. The hard parts are consistency guarantees, transaction isolation, index traversal efficiency, and distributed state routing under concurrent loads. This requires specialized database systems engineers and distributed infrastructure architects.
Discussion
13 comments analyzed.
Competitors mentioned: neo4j, Dgraph, TypeDB, SurrealDB, SPARQL/RDF databases
Concerns raised: Beta stage with data wipe risk, should be labeled alpha, Performance issues with neo4j and other graph databases, Lacks proper migration engine and payment system, SPARQL as string query language prone to errors, Opening 120+ issues across databases seems like bragging or unusual behavior
Feature requests: Proper migration engine implementation, RDF database with SPARQL and SHACL support, Topological ordering for mutations, Support for entities evolving and belonging to multiple types
Competitors
Other products that read as similar to this one — 90 launches clear the similarity bar, closest 8 shown.
Attention rank: #28 of 91 (itself plus its competitors, highest first — normalized so YC and Product Hunt are compared fairly).
Launched 230 days after the earliest competitor.
- TypeGraph · hn · 2026-02-24 · 5 upvotes · similarity 0.60
- HelixDB · hn · 2026-06-10 · 159 upvotes · similarity 0.51
- TuringDB · hn · 2026-01-28 · 7 upvotes · similarity 0.47
- SQLite Graph Ext · hn · 2025-10-29 · 35 upvotes · similarity 0.44
- LatticeDB · hn · 2026-08-25 · 190 upvotes · similarity 0.44
- NodeDB · hn · 2026-05-11 · 5 upvotes · similarity 0.43
- We built a type-safe Python ORM for RedisGraph/FalkorDB · hn · 2026-01-28 · 5 upvotes · similarity 0.42
- Ontology-driven knowledge graph extraction from text · hn · 2025-11-24 · 13 upvotes · similarity 0.42
Other launches for this product
- No other launches for this product.