GrapheneDB
ProductUse cases
AI apps and agentsGraphRAG, Agent memory, Graph features for MLFraud, access and securityFraud detection, Identity and access, Cybersecurity
Customers and contentRecommendations, Customer 360, Knowledge graphsNetworks, supply chains and dataNetwork and IT ops, Supply chain, Data lineage
From AI agents to fraud rings: where a graph fits.All use cases →
PricingDocsBlog
Production-readyRun Neo4j Community safely in productionSecurityDedicated, encrypted infrastructure for your data
ManageScale, pause and automate your databasesVisibilitySee what's happening, when and by whom
ExplorerQuery and visualize your graph in the browserAI accessGive AI assistants direct access to your data
New: MCP ServerGive AI assistants direct access to your data.All new features →
Console

Use cases

What teams build on a graph

Use a graph when the connections between your data matter as much as the data. Here's where Neo4j on GrapheneDB fits, from AI agents to fraud detection.

Try for free
01 / 04

AI apps and agents

Language models know a lot, but not your data or what happened yesterday. A graph gives them both, with relationships they can follow and you can check.

GraphRAG

Answers that pull in the related facts, not only text that looks similar.

Vector search finds the passages closest to the question. The graph then follows them to the products, people and policies they mention, so the model gets the whole picture and every answer can be traced to its source.

Why GrapheneDB

  • Vector + graph in one query
  • Multi-hop Cypher
  • Read replicas for retrieval load
// Similar chunks first, then the facts around them
CALL db.index.vector.queryNodes('chunks', 5, $q)
YIELD node AS chunk, score
MATCH (chunk)-[:MENTIONS]->(e:Entity)-[r]-(fact)
RETURN chunk.text, e.name, type(r), fact.name, score

Agent memory

Agents that remember people, tasks and decisions across sessions.

Memory kept as nodes and relationships is structured: an agent can ask what it knows about a person, which tasks are open, or why it decided something, and you can browse and correct it.

Why GrapheneDB

  • Vector indexes
  • MCP server
  • GDB Explorer to see what the agent stored
// What do I know about this user's open work?
MATCH (u:User {id: $user})-[:WORKS_ON]->
      (t:Task {status: "open"})
OPTIONAL MATCH (t)<-[:ABOUT]-(m:Memory)
RETURN t.name, collect(m.text)[..5] AS notes

Graph features for ML

Better fraud, churn and recommendation models, fed with what the graph knows.

How central an account is, which community it belongs to, how close it sits to known fraud: graph features often predict better than the rows alone. Compute them in the database and hand them to your model.

Why GrapheneDB

  • Graph algorithms (GDS plugin)
  • Node embeddings (FastRP)
  • Clone a database to experiment safely
// Node embeddings for every account, saved on the node
CALL gds.graph.project(
  'accounts', 'Account', 'TRANSFERRED_TO')
YIELD graphName
CALL gds.fastRP.write(graphName, {
  embeddingDimension: 64, writeProperty: 'embedding'})
YIELD nodePropertiesWritten
RETURN nodePropertiesWritten
02 / 04

Fraud, access and security

Risk hides in connections: shared devices, nested groups, a path from an exposed server to your data. Graphs find them in one query.

Fraud detection

Spot fraud rings through shared devices, cards and addresses.

One account rarely looks suspicious on its own. Linked to the devices, cards and addresses it shares with flagged accounts, a ring shows up at once.

Why GrapheneDB

  • Multi-hop Cypher
  • Graph algorithms (GDS plugin)
  • Read replicas for real-time scoring
// Accounts sharing a device with flagged accounts
MATCH (a:Account)-[:USES]->(:Device)
      <-[:USES]-(b:Account {flagged: true})
WHERE a <> b
RETURN a.id, count(DISTINCT b) AS flaggedNeighbours
ORDER BY flaggedNeighbours DESC LIMIT 20

Identity and access

Who can reach what, through every role and nested group.

Permissions come through groups inside groups, roles and inheritance. A graph answers "why can this person read that?" with the actual path.

Why GrapheneDB

  • Variable-length paths
  • APOC
  • Read replicas for fast access checks
// Why can this user read this resource?
MATCH path = (u:User {email: $email})
  -[:MEMBER_OF*0..6]->(:Group)
  -[:CAN_READ]->(r:Resource {name: $resource})
RETURN path LIMIT 1

Cybersecurity

Find the attack paths from exposed hosts to critical systems.

Hosts, credentials and network rules form a graph. The shortest path from the internet to your crown jewels is the one to close first.

Why GrapheneDB

  • Shortest path
  • Graph algorithms (GDS plugin)
  • GDB Explorer to trace attack paths
// Shortest route from an exposed to a critical host
MATCH p = shortestPath(
  (:Host {exposed: true})
  -[:CAN_REACH|HAS_CREDS_FOR*..8]->
  (:Host {critical: true}))
RETURN p ORDER BY length(p) LIMIT 5
03 / 04

Customers and content

What people buy, read and like is a network. Graphs turn it into recommendations and a single view of each customer.

Recommendations

"Customers like you also bought" in one query, in real time.

Recommendations are relationships: people who bought the same things, products in the same category, content with the same tags. Follow them at request time, no batch jobs.

Why GrapheneDB

  • Multi-hop Cypher
  • Vector indexes
  • Read replicas
// Bought by people who bought what I bought
MATCH (me:Customer {id: $id})-[:BOUGHT]->(:Product)
      <-[:BOUGHT]-(other)-[:BOUGHT]->(rec:Product)
WHERE NOT (me)-[:BOUGHT]->(rec)
RETURN rec.name, count(*) AS score
ORDER BY score DESC LIMIT 10

Customer 360

Orders, tickets, accounts and contacts for a customer, in one place.

Customer data lives in many systems. Linked in a graph, support, sales and product teams see the same customer and everything around it.

Why GrapheneDB

  • GDB Explorer
  • APOC for loading from many sources
  • Public API
// Everything connected to one customer, by type
MATCH (c:Customer {id: $id})-[r]-(x)
RETURN type(r) AS relationship, labels(x)[0] AS kind,
       count(*) AS total

Knowledge graphs

Connect the facts from your documents and databases so anyone can explore them.

A knowledge graph links entities from many sources: drugs to genes to diseases, people to projects to skills. It is also the base GraphRAG and agents build on.

Why GrapheneDB

  • Vector indexes
  • APOC
  • GDB Explorer
// Drugs that target genes linked to a disease
MATCH (d:Drug)-[:TARGETS]->(g:Gene)
      <-[:ASSOCIATED_WITH]-(:Disease {name: $name})
RETURN d.name, collect(g.symbol) AS genes,
       count(g) AS evidence
ORDER BY evidence DESC
04 / 04

Networks, supply chains and data

Infrastructure, suppliers and data pipelines are chains of dependencies. A graph shows what breaks when one link fails.

Network and IT ops

Know which services go down when a component fails.

Services depend on services, hosts and network links. Walk the dependencies to see the impact of an outage, or the root cause behind a set of alerts.

Why GrapheneDB

  • Variable-length paths
  • Graph algorithms (GDS plugin)
  • GDB Explorer
// Everything that depends on a failing component
MATCH (s:Service)-[:DEPENDS_ON*1..6]->
      (:Component {id: $failing})
RETURN DISTINCT s.name, s.team

Supply chain

See every supplier behind a product, tiers deep.

A product is parts made from parts, from suppliers in many countries. When one region has a problem, find the products at risk in one query.

Why GrapheneDB

  • Variable-length paths
  • Shortest path
  • Clone a database to test a disruption
// Suppliers in an affected country behind a product
MATCH (:Product {sku: $sku})<-[:PART_OF*1..5]-(:Part)
      <-[:SUPPLIES]-(s:Supplier)
WHERE s.country = $country
RETURN DISTINCT s.name

Data lineage

Trace every report back to the tables and jobs that feed it.

When a number looks wrong, follow it upstream through jobs and tables to the source, and see who owns each step.

Why GrapheneDB

  • Variable-length paths
  • GDB Explorer
  • MCP server to ask where a number comes from
// Where does this report's data come from?
MATCH (:Report {name: $report})<-[:FEEDS*1..]-(t:Table)
RETURN t.name, t.owner