For people who already think in graphs

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.

Start free Try the playground

N-ary relationsEnforced cardinalityO(1) reverse traversalJSON over HTTP

schema · relations are kinds

// 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.

BQL · traverse the relation

// 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.

BQL · composition query

// 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.

schema · role constraints

// 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.

Graph algorithms & analytics5/5

GDSPathfindingScale

If the deliverable is PageRank, communities, or shortest paths, Neo4j's algorithm library is the tool. Full stop.

Schema on relationships2/5

ConstraintsIntegrity

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.

Zero to a live product API2/5

DriversOpsDialects

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.

Graph algorithms & analytics1/5

Not our lane

No algorithms library, and traversal is schema-shaped expansion, not arbitrary-depth pathfinding. Analytics is not the job we do.

Schema on relationships5/5

RolesCardinalityonDelete

Typed n-ary roles with enforced cardinality and delete rules — the contract lives in the engine, not in every service.

Zero to a live product API5/5

HTTPStudioFree tier

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/mcp

A 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.

Start free