A graph database built to ship products, not run analytics.
BlitzGraph gives relationships a schema: typed roles, enforced cardinality, delete rules, attributes on the connection itself. You query it as JSON over HTTP — no driver, no dialect — and search, validation, and an instant API live in the same engine.
// A relation with its own fields, typed roles, and a delete story { "kinds": { "Book": { "dataFields": { "title": { "valueType": "TEXT", "fts": true } } }, "Author": { "dataFields": { "name": { "valueType": "TEXT" } } }, "Writing": { "dataFields": { "year": { "valueType": "INTEGER" } }, "roles": { "book": { "plays": ["Book"], "cardinality": "ONE", "onDelete": "Cascade" }, "authors": { "plays": ["Author"], "cardinality": "MANY", "required": true } } } } }
Modeling
Say it in the schema, not in application code.
Property graphs make nodes and edges flexible. The invariants that matter to a product — required roles, cardinality, validated connection attributes, and delete behavior — often need extra configuration or application code. Here they are declarations.
Three-way facts, first class
Authorship-with-a-year is not a property stapled to a binary edge. A relation here is a kind: it has its own fields, typed roles, and both directions indexed from birth. No reification pattern, no intermediate-node hack you maintain by hand.
// The relation's own fields ride along { "$kinds": "Author", "$filter": { "name": "Borges" }, "$fields": [ "name", { "$expand": "writings", "$sort": "-year", "$fields": [ "year", { "$expand": "book", "$fields": ["title"] } ] } ] }
Nodes with more than one kind
A unit is a set of kinds, not a label. Person, Author, and Reviewer compose on the same node, each contributing fields and relationships. Filtering with $all means AND — and when reality turns out polymorphic, there is no relabeling migration.
// Units that are BOTH — $all is AND, not OR { "$kinds": { "$all": ["Author", "Reviewer"] }, "$filter": { "score": { "$gte": 4 } }, "$fields": ["name", "score", "$kinds"] }
Edges with a contract
Cardinality, required roles, symmetric collapse, self-relation rules, and delete behavior — cascade, restrict, unlink — are engine checks, not conventions. The second A↔B friendship, the self-follow, and the eleventh member of a max-10 role are rejected at write time, atomically, batches included.
// Enforced by the engine, not by convention "roles": { "friends": { "plays": ["User"], "cardinality": "MANY", "symmetric": true, "allowSelfRelation": false, "onDelete": "Unlink" } }
// honest comparison
Against the graphs you know.
Neo4j, Dgraph, TypeDB, and SurrealDB are serious systems, and one meter below is a loss we are comfortable stating. The question is which job you are hiring a graph for.
Neo4j · Dgraph · TypeDB · SurrealDB
Established graph databases
Serious engines with real strengths: mature analytics, flexible query languages, and operational control. Their product-layer integration is yours to shape.
If the deliverable is PageRank, communities, or shortest paths, Neo4j's algorithm library is the tool. Full stop.
Relationship constraints vary by engine; for many property-graph stacks, role rules and delete semantics still need application design. TypeDB takes a deliberately schema-first approach.
You choose and operate the surrounding product stack: query language, driver or API, hosting, auth, and deployment.
Cloud graph backend
BlitzGraph
A graph engine built for shipping products: relationships carry schema, queries are JSON over HTTP, and search, validation, and logic run inside the same database.
No algorithms library, and traversal is schema-shaped expansion, not arbitrary-depth pathfinding. Analytics is not the job we do.
Typed n-ary roles with enforced cardinality and delete rules — the contract lives in the engine, not in every service.
JSON over HTTP with a playground and a free tier — a live graph in about a minute, no driver, nothing to operate.
The trade
What you give up. What you get back.
You give up
- Self-hosting — there is no binary to run; BlitzGraph is a managed service.
- Cypher, and a decade of Stack Overflow answers written for it.
- A graph-algorithms library.
- Gray-haired maturity — this is a public beta, and we behave like one.
You get back
- A live graph in a minute: no JVM tuning, cluster sizing, or version migrations, ever.
- A query surface any developer — or LLM — reads correctly on day one, because it is JSON.
- The application layer incumbents never shipped: BM25 search, computed fields, validations, hooks, files, one HTTP API.
- An exit that is one call: the whole namespace exports as JSON. Leaving is easy. That is the point of staying.
Agents
Your agent already speaks it.
Language models can produce invalid graph queries. BQL is JSON the engine validates structurally — add the MCP server and Claude or Codex can read your schema and compose queries against live data.
claude mcp add --transport http blitzgraph https://blitzgraph.com/mcpA fair test
Bring your gnarliest relationship.
The one with three participants, attributes on the connection, and a delete story nobody remembers. Model it in the playground; ten minutes will tell you whether this is your database.