Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

Introduction — You Need a Map, Not a Pin
The Big Fork — Property Graph vs RDF Triplestore
Graph Databases — What Goes Where
The RDF and Ontology Stack — When You Need Formal Semantics
Graph RAG Frameworks — Roll Your Own, or Batteries Included?
Vector Plus Graph — Where Embeddings Fit
When NOT to Use a Graph
The Decision Flow
Closing
References

Introduction — You Need a Map, Not a Pin

The landscape of knowledge graph tooling exploded over the last two years. You can seriously consider six graph databases, the RDF stack has two decades of history, and a new graph RAG framework ships seemingly every month. The common failure of a post like this is to list thirty links and stop. There are already enough link lists.

So this post draws a map. For each category it names what it is for, two or three representative tools, and when to pick what. It is the practical closer to this series — after why graph RAG, how to build the graph, and how to model a domain as an ontology, this one answers "so what do I actually use?"

One honest premise up front: tools change. Even while this was being written, a well-known embedded graph database was archived. So I wrote down the criteria for choosing more carefully than the tool names, because the criteria last longer.

The Big Fork — Property Graph vs RDF Triplestore

Whatever you pick, the first fork is the data model. There are two families.

Property graphs hang arbitrary key-value properties on labeled nodes and edges. A formal schema is optional, they are developer-friendly, and you query them with Cypher (and GQL, which became an ISO standard in 2024), Gremlin, or GSQL.

// Property graph (Cypher): pragmatic, schema-optional
CREATE (a:Person {name: 'Ada'})-[:WORKS_AT]->(c:Company {name: 'AE Ltd'})

RDF triplestores store (subject, predicate, object) triples, identify entities with global IRIs, define formal ontologies with RDFS/OWL, and can run logical inference. You query them with SPARQL, and because they are W3C standards, cross-organization interoperability is strong.

# RDF (SPARQL): global identifiers, formal vocabulary, inference-ready
SELECT ?person WHERE { ?person a :Person ; :worksAt ?org . }

The honest rule: most LLM and graph RAG applications want a property graph. There is less ceremony, and it is more forgiving of the noisy, extracted graphs these systems produce. Reach for RDF when you need formal semantics — a vocabulary shared across teams or organizations, logical inference, standards or regulatory compliance, or data integration. How far to formalize an ontology is covered separately in the domain ontology post.

Note that Amazon Neptune supports both (property graph via openCypher/Gremlin, RDF via SPARQL), which is a strong reason on its own if you are already on AWS.

Graph Databases — What Goes Where

Six of them, split by practical fit.

Neo4j — the de facto standard. Cypher, the largest ecosystem, the most mature tooling. Self-hosted or the managed AuraDB, a built-in vector index, and the first-party neo4j-graphrag package covered below. The safe default for a server-side property graph.
Memgraph — in-memory, Cypher-compatible. Strong for real-time, low-latency operational workloads and streaming updates. Its 2025 AI Toolkit (SQL2Graph, Unstructured2Graph) reduced onboarding friction. Pick it when you need fast traversals over data that changes constantly.
Kùzu — embedded (in-process), the "SQLite for graphs." Columnar and analytics-oriented, Cypher, with vector and full-text search built in. Ideal for notebooks, prototypes, and single-node analytics. An honest caveat: Kùzu Inc. was acqui-hired by Apple in October 2025 and the GitHub repository was archived. The MIT license means community forks continue, but think hard before building a long-term production dependency on an assumed vendor roadmap. The technology is excellent; price in the governance uncertainty.
ArangoDB — multi-model (graph + document + key-value). When you want graph plus documents in one store.
Amazon Neptune — managed on AWS. Supports both property graph and RDF, and feeds into Neptune Analytics and the GraphRAG capability in Bedrock Knowledge Bases. Pick it when you are on AWS and want the operational burden reduced.
TigerGraph — native parallel (MPP), GSQL. Strong on deep-link analytics over large graphs (fraud, KYC/AML, recommendations). For the very large and traversal-heavy.

Embedded vs server splits cleanly. Prototype, notebook, or single node: embedded (Kùzu). Concurrency, ecosystem, production: server (Neo4j). Want it managed: Neptune or AuraDB.

The RDF and Ontology Stack — When You Need Formal Semantics

If you took the RDF path, the toolkit tends to look like this.

Protégé — the standard open-source OWL/RDF ontology editor (Stanford). Where you author the ontology.
OWL / RDF / RDFS / SPARQL — the W3C standards themselves. RDF is the data model, RDFS and OWL are schema and logic, SPARQL is the query language.
RDFLib — a Python library for RDF. Good for scripting, small graphs, and ETL.
Apache Jena — a Java framework: Fuseki (a SPARQL server), TDB (a triplestore), and reasoners. The open-source workhorse for RDF apps.
Ontotext GraphDB — an enterprise RDF triplestore. SPARQL, RDF-star, reasoning, and now vector similarity.
TopBraid (TopQuadrant EDG) — enterprise data governance on top of RDF knowledge graphs. EDG 8.0 (February 2025) added a built-in vector database to help with entity resolution and tagging. Commercial and governance-centric.

How to choose: prototype or Python, RDFLib. Open-source production RDF app, Jena (plus Fuseki). Enterprise triplestore needing reasoning and scale, GraphDB (or Stardog). A data-stewardship organization, TopBraid EDG. Authoring the ontology, Protégé anywhere.

Graph RAG Frameworks — Roll Your Own, or Batteries Included?

Two axes make the choice easy: (1) batteries-included pipeline vs building block, and (2) heavy batch indexing vs lightweight.

Microsoft GraphRAG — batteries-included, batch-heavy. It runs the full pipeline: LLM entity and relationship extraction, graph construction, Leiden community detection, community summarization, and both local and global search. It shines on global questions like "what are the themes across this whole corpus," but the upfront LLM indexing cost is large. LazyGraphRAG (late 2024) defers the summarization, cutting indexing cost toward vector-RAG levels while keeping global-query quality. Pick it when you need whole-corpus synthesis and can afford the indexing (or avoid it with Lazy).
neo4j-graphrag (Python) — Neo4j first-party. End-to-end, with a KG builder (SimpleKGPipeline) and retrievers (Vector, VectorCypher, Hybrid, Text2Cypher). Pick it when you are committed to Neo4j and want a supported path.
LlamaIndex PropertyGraphIndex — framework-native. It runs kg_extractors over each chunk to attach entities and relations, swaps graph stores freely, and offers several retrievers. If you are already inside LlamaIndex.
LangChain LLMGraphTransformer — a building block. Give it allowed node and relationship types as a schema and it extracts nodes and relationships. When you want to control your own pipeline.
Cognee — agent long-term memory. An ECL (Extract, Cognify, Load) pipeline, graph-plus-vector hybrid storage, and many backends (Kùzu, Neo4j, NetworkX, and more). When the goal is persistent agent memory, not document QA.
txtai — a lightweight all-in-one embeddings framework. Its semantic graphs (since 5.0, in 2022) auto-generate edges from embeddings and do RAG by graph path traversal. When you want to explore a topic locally and lightly without standing up a dedicated graph DB.
Haystack — a general-purpose LLM and RAG pipeline framework (deepset). You can wire graph components into it, but graph is not its specialty. Treat it as an orchestration layer, not a graph-first tool.

The roll-your-own vs batteries-included heuristic: if you just need entities and relations landed into your own graph, a LangChain/LlamaIndex extractor or a plain LLM call is enough. Microsoft GraphRAG earns its cost only when you genuinely need its community-summarization, global-query machinery.

Vector Plus Graph — Where Embeddings Fit

A common mistake is to treat vector vs graph as either/or. The modern default is hybrid.

Vector search handles fuzzy semantic recall ("passages like this"); graph traversal handles precise multi-hop relationships ("how are X and Y connected," "everything affected by Z"). The canonical pattern: embed the nodes or chunks, use vector search to find entry points, then traverse the graph from there to pull in connected context. neo4j-graphrag's VectorCypherRetriever is exactly this shape.

And most graph databases now ship a vector index (Neo4j, Kùzu, Memgraph, Neptune Analytics, GraphDB, TopBraid), so a separate vector DB is often unnecessary. Embeddings also help build the graph — entity resolution links similar nodes, which is what TopBraid EDG 8.0's vector DB and txtai's semantic graphs do.

When NOT to Use a Graph

Now the honest counterweight. If your questions are answered by single-hop similarity ("find documents about X," "summarize this policy"), plain vector RAG is simpler, cheaper, faster, and enough. A graph adds an extraction pipeline, a store, a schema, and traversal logic — each of which can go wrong.

A graph earns its cost only when you need one of four things: multi-hop reasoning, relationship-aware retrieval, global synthesis across a corpus, or explainable provenance. If you cannot name which of those you need, you probably need vector RAG. Getting the retrieval fundamentals right first is covered in production RAG patterns.

One more thing: a graph built on garbage extraction is worse than no graph. Construction quality gates everything (see the construction post).

The Decision Flow

Compressed to a single page:

1. Do your questions need relationships?
   (multi-hop, "how are X and Y connected", themes across a whole corpus)
   NO  -> plain vector RAG. Stop here. Do not build a graph.
   YES -> continue.

2. Do you need formal semantics?
   (logical inference, a vocabulary shared across orgs, standards/regulation)
   YES -> RDF stack: author in Protege (OWL), store in Jena/GraphDB, query SPARQL.
   NO  -> property graph (below).

3. Pick the graph database:
   local / notebook / single node       -> Kuzu (note: repo archived 2025, community forks)
   production server, biggest ecosystem -> Neo4j
   real-time / streaming updates         -> Memgraph
   managed on AWS                        -> Amazon Neptune
   graph + documents in one store        -> ArangoDB
   massive parallel deep-link analytics  -> TigerGraph

4. Pick the graph RAG layer:
   holistic "themes of the whole corpus" -> Microsoft GraphRAG (use LazyGraphRAG for cost)
   committed to Neo4j, want first-party   -> neo4j-graphrag
   already inside a framework             -> LlamaIndex PropertyGraphIndex / LangChain
   persistent agent memory                -> Cognee
   lightweight, local, topic exploration  -> txtai semantic graphs

Closing

It is a map, not a pin. Tools wobble — Kùzu is this year's proof. What does not wobble is the questions. Property vs RDF is a question about semantics, not fashion; graph vs vector is a question about relationships, not hype. Answer those two first, then pick the tool.

That reaches the practical end of the series. Why graph RAG covered the why, construction the how of building, domain ontology the modeling, and this post the tools. Keep production RAG patterns beside them for when a graph is overkill, and the map is complete.

The most honest closing line: the best graph project is usually the smallest one that answers the question — and sometimes that is no graph at all.