Knowledge Graph Databases: What They Are and How to Choose One

Ask ten engineers what a knowledge graph database is and you get three different answers, all of them partly right. One describes a storage engine. One describes a semantic model. One describes a retrieval technique for language models.

They are describing three separate things that happen to share a vocabulary, and the confusion is expensive, because two of the three do not require buying anything new.

This post separates them, then covers the parts that actually decide a choice: which data model you commit to, which systems fit which situation, and the ongoing engineering cost that comparison posts leave out.

One disambiguation first. Google’s Knowledge Graph, the thing that populates the panel on the right of a search result, is a specific proprietary product and it is not what this post is about. If you arrived looking for that, you want a search engine optimisation resource rather than this one.

How this post was put together. Every technical claim below is sourced to a standards body or to first-party vendor documentation, linked at the claim. Vendor capabilities were verified against current public documentation on 2026-08-06. This post does not rank vendors or run benchmarks, and the situation table is a starting shortlist rather than a scored comparison.

Knowledge Graph vs Graph Database, and Why the Distinction Matters

These two terms get used as synonyms in vendor material and they refer to different layers.

The graph database is the engine

A graph database stores nodes and edges and is optimised for traversing them. Its job is performance on connected queries: finding paths, walking neighbourhoods, running aggregates over relationships. It does not care what the nodes mean.

The knowledge graph is the model

A knowledge graph is the layer that supplies meaning. Entities have types, relationships have defined semantics, and both draw on a shared vocabulary so that “supplier” means the same thing in your procurement system as it does in your risk system.

PuppyGraph’s summary of the distinction is a clean statement of how practitioners use the terms: “A knowledge graph encodes semantics, context, and meaning across entities and relationships, serving as a conceptual model; a graph database is a storage/query engine optimized for traversing and analyzing connected data structures.”

That is a vendor framing rather than a standard definition, and PuppyGraph sells a product in this category, so treat it as a useful articulation rather than neutral authority. Source: PuppyGraph, Knowledge Graph vs Graph Database, observed 2026-08-06.

Why you should care

Because the two decisions are separable, and they get merged constantly.

You can build a knowledge graph on a relational database. Plenty of organisations have, and for small graphs with predictable query patterns it works fine. You can also run a graph database with no knowledge graph in it at all, storing a social network or a dependency tree that has no ontology and needs none.

Which means the question “which knowledge graph database should we buy” often decomposes into two easier questions. Do we need graph traversal performance, and do we need a shared semantic model? Those have different answers, and one of them frequently turns out to be no.

Should Your Knowledge Graph Database Use RDF or a Property Graph?

This is the real fork in the road, and the comparison posts mostly skip it because it is harder to tabulate than a feature list.

RDF, triples and SPARQL

RDF represents everything as subject-predicate-object triples (W3C RDF 1.1 Concepts, Recommendation, 2014), queried with SPARQL 1.1 (Recommendation, 2013). It comes with formal semantics and the ability to declare things a machine can act on: OWL 2 (Recommendation, 2012) for inference, and SHACL (Recommendation, 2017) for validating that a graph conforms to declared constraints. Those are two different jobs, and it is worth keeping them apart: OWL derives new facts, SHACL checks existing ones. Provenance is a first-class concern, because you can make statements about statements.

It fits when vocabularies have to be shared across organisational boundaries, when you need machine-checkable inference, or when regulators will ask where a fact came from.

Labelled property graphs, Cypher and Gremlin

A property graph puts key-value properties directly on nodes and edges, queried with Cypher or Gremlin. There is no formal semantics layer and no reasoner. What you get instead is a model that application developers pick up quickly and a query language that reads close to the shape of the data.

It fits when the graph serves an application, when the team is not going to sustain ontology work, and when traversal speed matters more than inference.

The query language situation is part of the choice

Worth knowing before you commit, because it affects hiring and portability, and because the conventional wisdom here is a year or two out of date.

The property graph side now has a standard. GQL was published as ISO/IEC 39075:2024 in April 2024, and is widely described as the first new ISO database query language since SQL. The open variable is no longer standardisation but adoption: Neo4j reports that Cypher now implements most mandatory GQL features and part of the optional set, with some mandatory features still outstanding (Neo4j GQL conformance, observed 2026-08-06). Gremlin and vendor dialects continue alongside it.

On the RDF side, SPARQL has been standardised since 2013 and the core query surface behaves consistently across stores, which makes the query layer largely portable. The parts that are not portable sit above it: reasoning profiles, rule languages, full-text search and vendor SPARQL extensions differ meaningfully between stores, so a migration is usually easy for queries and awkward for everything you built on top of them.

The practical effect today is that a property graph query is still more likely to be tied to the engine you wrote it against, and that this is narrowing rather than permanent. That is not a reason to avoid property graphs, but the exit cost is asymmetric, and it belongs in the decision alongside performance.

How to actually decide

Ask whether anything in your system needs to derive facts that nobody stated. If a regulator, a data-sharing agreement or a compliance rule requires you to prove that a conclusion follows from declared rules, RDF earns its overhead.

If not, the property graph is usually the lower-friction choice, and the friction is real: ontology design is a skill, and half-finished ontologies are worse than none.

Which Knowledge Graph Database Fits Which Situation

A note on the managed row, because “check model support” is advice that helps nobody. Amazon Neptune Database supports both models from a single cluster: RDF via SPARQL, and property graphs via both Gremlin and openCypher (AWS Neptune documentation). Neptune Analytics, the in-memory analytics engine alongside it, is queried with openCypher (AWS Neptune Analytics documentation). The distinction that matters is which service you are provisioning, not whether the vendor supports your model.

The last row is there deliberately, because it is the option teams skip fastest and regret skipping. Recursive common table expressions in Postgres will traverse a hierarchy or a modest graph perfectly well, and if your graph is a few hundred thousand edges with query patterns you already know, a new database buys you syntax rather than capability.

One caveat on that, since it is the row most likely to be taken too far. Recursive CTEs need explicit cycle handling: Postgres documents both the manual visited-path array and the CYCLE clause, and without one of them a cyclic graph loops indefinitely (PostgreSQL, WITH queries). Hierarchies and other acyclic shapes are the comfortable case. High-branching or cyclic graphs are where the approach stops being cheap.

The threshold where a dedicated engine starts to matter is usually variable-depth traversal over a large graph, where the number of joins is not known when you write the query. Below that, the operational simplicity of one database tends to outweigh the ergonomics of a better query language.

This table reflects positioning and architecture as of 2026-08-06. It is not a ranking and not a benchmark. Licensing in this category is genuinely varied, and several products described as open source ship under source-available licences instead, so confirm the licence and the managed-service capabilities directly with the vendor’s own documentation before you commit.

Do You Actually Need a Knowledge Graph Database for RAG?

The GraphRAG conversation has convinced a lot of teams that they need a graph. Some of them do. The full vector-versus-graph trade-off, including hybrid patterns, is covered in Vector Databases and Knowledge Graphs for RAG; this section covers only the part that bears on buying a database.

The case for. Graph retrieval answers questions that chunk similarity structurally cannot. Which suppliers are two steps removed from a sanctioned entity. Which of our customers are affected by a dependency in a library we do not directly use. These are traversal and aggregation questions, and no amount of better embedding gets you there, because the answer is not contained in any single chunk.

The case against, and it is the one to take seriously. The graph is not the hard part. The extraction pipeline is. Getting entities and relationships out of unstructured text, keeping them current as documents change, and resolving the same entity appearing under six different spellings is an ongoing engineering commitment, not a one-time load.

Our view, from watching teams scope this work: the extraction and resolution pipeline is routinely budgeted as a fraction of the project when it is most of it, and the failure mode is quiet. The graph keeps returning answers. They are just increasingly wrong.

If you do go ahead, first-party tooling exists on both sides of the model split, so this is not a reason to pick one. Neo4j publishes the neo4j-graphrag Python package as an official first-party library with knowledge-graph construction pipelines and several retrievers, and Ontotext has shipped no-code GraphRAG tooling in GraphDB on the RDF side. Both were checked on 2026-08-06.

The test. Look at the queries your current retrieval fails on. If they are single-hop factual lookups, where the answer sits in one document and the retriever simply did not find it, a knowledge graph database will not fix them. Better chunking, a reranker or hybrid search probably will, and Best Vector Databases for RAG covers that side of the decision. If instead the failures are joins across documents, the graph is doing something the index cannot.

The Build Cost Nobody Puts in the Comparison

Choosing the engine is a week. Everything below is the project.

The entity resolution row deserves the most attention. A bad merge does not throw an error. It creates a node that claims two real-world things are one, and every query that traverses through it inherits the mistake. Because graph queries compose, a single bad merge can corrupt answers several hops away from where the error lives.

Extraction deserves a note too, because the tempting shortcut has a cost. Using a language model to pull entities and relations out of documents works well enough to demo in an afternoon, which is exactly the problem. The model is doing an extraction task with no ground truth, at scale, and its precision varies with document format in ways nobody is watching.

A vendor changes an invoice template and your relation extraction quietly starts producing a different shape of edge. The pipeline still runs. The graph still loads. The answers slowly stop being true.

If you build extraction on a model, you need a labelled sample and a regular check against it, for the same reason you would not ship a classifier without a test set.

The validation row is the one that is almost always empty. Teams instrument the pipeline and monitor whether loads succeed. Almost nobody measures whether the resulting graph is correct, which means a degrading knowledge graph produces confident wrong answers with a clean provenance trail attached, and that is a worse failure than no graph at all.

Where Future AGI Fits

The validation gap is the one worth closing first, and it does not require graph-specific tooling. Two of Future AGI’s built-in evaluators apply directly, and neither cares where retrieved context came from.

groundedness checks whether a response is strictly grounded in the provided context, flagging anything the context does not support. It returns Passed or Failed.

context_adherence measures how well a response stays within the provided context and returns a score between 0 and 1, so you can watch a distribution rather than only count failures.

The screenshot shows the shape this takes in practice. Query, context and response sit in columns, each row is scored, and the column carries an average. The eval scoring those rows is Faithfulness rather than groundedness, but the mechanic is identical.

Swap the context column for graph-retrieved context, rerun over the same questions, and compare the two averages. That comparison is the number that should decide whether the extraction pipeline is worth building, and it is the measurement the GraphRAG conversation is mostly missing. If you want the metric definitions behind it, RAG Evaluation Metrics and Evaluating RAG Faithfulness go a level deeper.

Future AGI does not ship ontology tooling or entity resolution, and nothing here should be read as that claim.

Conclusion

Three things wear the same name. The engine is a purchase, and a fairly reversible one. The knowledge graph is a project, and the extraction and resolution work continues for as long as the graph is alive. GraphRAG is a retrieval strategy, and it should be measured against your existing baseline before it justifies the project.

Separate them before you shortlist anything. Most teams who do find that their real question was narrower than “which knowledge graph database”, and that the answer to the narrow question was cheaper.

Want to test whether GraphRAG beats your current baseline? Run the same questions through both retrieval paths in the Future AGI app and score them with groundedness.