Graph Databases
Neo4j · Neptune · Knowledge Graphs

Why a graph at all?

A relational database stores relationships implicitly — as foreign keys you re-discover with JOINs at query time. A graph database stores relationships as first-class, materialized records. Walking from one entity to a connected one is a pointer hop, not a JOIN.

That single design choice flips the cost model. In SQL, the price of a "friends-of-friends-of-friends" query grows with the size of the tables (each hop is another JOIN scanning more rows). In a graph, the price grows with the size of the answer — you only touch nodes you actually traverse. This is called index-free adjacency: each node physically points to its neighbors.

Two data models you must distinguish

"Graph database" hides a fork in the road. Almost every vendor sits on one side or the other — and Neptune notably supports both. Choosing wrong means rewriting your data layer.

Same fact, both models

The property graph keeps Alice as one rich object; RDF shreds her into atomic statements. RDF's atomicity is what makes it great for merging knowledge from many sources and for reasoning, but it's more verbose for everyday application CRUD.

Neo4j & Cypher

Neo4j is the market-leading property-graph database. Its query language, Cypher, reads like ASCII art of the pattern you're matching — nodes in (), relationships in -[]->. openCypher (the open spec) is also supported by Neptune and Memgraph, so the skill transfers.

Writing data: CREATE & MERGE

// CREATE always inserts — running this twice makes duplicates.
CREATE (a:Person {name: 'Alice', born: 1990})

// MERGE is "match-or-create" (upsert). The pattern in MERGE is the
// uniqueness key — Neo4j matches it; if absent, it creates it.
MERGE (m:Movie {title: 'The Matrix'})
  ON CREATE SET m.released = 1999, m.added = timestamp()
  ON MATCH SET  m.lastSeen = timestamp()

// Connect them with a typed, directed relationship that has a property.
MATCH (a:Person {name:'Alice'}), (m:Movie {title:'The Matrix'})
MERGE (a)-[r:RATED {stars: 5}]->(m)

Reading data: the pattern is the query

// "Who works at Acme?" — match the shape, return the people.
MATCH (p:Person)-[:WORKS_AT]->(c:Company {name:'Acme'})
RETURN p.name

// Variable-length traversal: friends up to 3 hops out.
// [:KNOWS*1..3] = follow KNOWS edges between 1 and 3 times.
MATCH (me:Person {name:'Alice'})-[:KNOWS*1..3]->(reach:Person)
RETURN DISTINCT reach.name

// Recommendation: movies my friends rated highly that I haven't seen.
MATCH (me:Person {name:'Alice'})-[:KNOWS]->(f)-[r:RATED]->(m:Movie)
WHERE r.stars >= 4 AND NOT (me)-[:RATED]->(m)
RETURN m.title, count(*) AS votes
ORDER BY votes DESC LIMIT 5

Amazon Neptune

Neptune is AWS's fully managed graph database. Its defining trait: it speaks both graph models. Same cluster, your choice of API — property graph via Gremlin or openCypher, or RDF via SPARQL.

Gremlin — imperative traversal

Where Cypher is declarative pattern-matching, Gremlin (Apache TinkerPop) is a step-by-step traversal pipeline — you literally chain the walk: start here, go out this edge, filter, repeat.

// Who works at Acme?
g.V().has('Person','name','Alice')   // start vertex
 .out('WORKS_AT')                       // hop along outgoing edge
 .values('name')                       // emit the property

// Friends up to 2 hops (repeat the 'out' step twice).
g.V().has('Person','name','Alice')
 .repeat(out('KNOWS')).times(2)
 .dedup().values('name')

SPARQL — querying RDF

PREFIX : <http://example.org/>
SELECT ?company ?coworker WHERE {
  ?p   :name      "Alice" .   # bind Alice
  ?p   :worksAt   ?company .       # her employer
  ?co  :worksAt   ?company .       # anyone at that employer
  ?co  :name      ?coworker .
  FILTER(?co != ?p)               # exclude Alice herself
}

Neo4j vs. Neptune — how to choose

Knowledge graphs, semantic search & GraphRAG

This is the section that earns the line item on senior AI/ML postings. A knowledge graph turns documents and data into a network of typed entities and relationships — and pairing it with an LLM fixes the biggest weakness of plain vector RAG.

The problem with vanilla vector RAG

Standard RAG embeds text chunks, finds the k most similar to a question, and stuffs them into the prompt. It's excellent at local questions ("what does the contract say about X?") but weak at global, multi-hop ones ("how are these three programs connected?") — because the answer isn't in any single chunk; it's in the relationships across chunks. Similarity search can't follow a relationship.

What GraphRAG adds

• Build: an LLM reads your corpus and extracts entities + relationships, writing them into a graph (Neo4j / Neptune). Optionally run community detection and pre-summarize clusters.
• Retrieve (hybrid): use a vector index to find the most relevant entry nodes, then traverse their relationships to pull in connected facts the embedding alone would miss. You get both semantic similarity and explicit structure.
• Answer: the assembled subgraph becomes grounded, explainable context — and because edges are explicit, you can cite the path, reducing hallucination.

// 1) Vector search: find chunks most similar to the question embedding.
CALL db.index.vector.queryNodes('chunkEmbeddings', 5, $qEmbedding)
YIELD node AS chunk, score

// 2) Expand: pull entities mentioned in those chunks and ONE hop of
//    their relationships — the structural context vectors can't reach.
MATCH (chunk)-[:MENTIONS]->(e:Entity)-[rel]-(neighbor:Entity)
RETURN chunk.text, e.name, type(rel) AS relation, neighbor.name
LIMIT 40

Other knowledge-graph payoffs

The broader landscape

Neo4j and Neptune anchor the field, but the right pick depends on scale, model, and where it runs. A quick map of the rest.

A pragmatic decision path