Knowledge Graph Navigator

Graph Databases for Knowledge Graphs: Neo4j, Triple Stores & More

A graph database stores data as nodes and the relationships between them, and treats those relationships as first-class objects that can be traversed directly rather than reconstructed with joins. When a knowledge graph outgrows files and memory, a graph database is what holds it: it keeps the entities, the typed edges between them, and the schema or ontology in one place, and it answers questions that follow chains of relationships. Two families dominate: labeled property graph databases queried with Cypher or GQL, and RDF triple stores queried with SPARQL. This page covers what these systems do differently from a relational database, how each family stores a knowledge graph, and how the choice is usually made in practice.

The conceptual distinction between the software and the data it holds is set out in knowledge graph vs graph database, and the data models are compared in detail in property graph vs RDF. This page is about the engines.

What a graph database does that a relational one does not

A relational database can represent a graph. Nodes go in one table, edges in another with two foreign keys, and a traversal becomes a join. That works, and for one or two hops it works well. The problem is that each additional hop adds another join, and the cost of a join is driven by the size of the tables being joined, not by the size of the answer. A four-hop query over a large edge table means four passes over indexes covering the whole dataset, and the intermediate result sets can be far larger than the final one.

Graph databases are built so that traversal cost tracks the part of the graph actually visited. In the property graph engines this is often described as index-free adjacency: a node record holds direct references to its adjacent relationship records, so following an edge is a pointer dereference rather than an index lookup. The term comes from the property graph vendors and implementations differ in the details, some using pointer chains, others using compressed adjacency structures or column layouts. The property that matters is the same in each case. Once the query has reached a node, expanding its neighbors costs an amount proportional to that node’s degree, and is unaffected by how many other nodes the database contains.

The practical consequence is that certain questions become answerable at interactive speed: path finding between two entities, pattern matching over a subgraph shape, neighborhood expansion, and reachability checks over hierarchies. The corresponding weakness is that graph databases are not built for large aggregate scans. Summing a column over a hundred million rows is a job for a relational or columnar system, and a knowledge graph deployment often keeps both.

Relational systems have moved partway toward this. SQL:2023 added SQL/PGQ, which allows property graph pattern matching inside SQL over relational tables. That helps teams needing occasional graph queries over a relational warehouse, and does not replace a graph engine for traversal-heavy work.

Labeled property graph databases

A labeled property graph (LPG) database stores nodes that carry one or more labels and a map of key-value properties, connected by directed edges that carry a single type and their own property map. That model maps cleanly onto how developers already think about objects and links, which is much of why it is popular.

Neo4j is the best-known member and the reason Cypher exists. Memgraph, TigerGraph, ArangoDB, JanusGraph, and NebulaGraph are other established engines, and Kuzu offers an embedded engine for use inside an analytics process rather than as a server. Apache AGE adds openCypher querying to PostgreSQL, and Amazon Neptune and Azure Cosmos DB provide managed property graph endpoints.

Query languages

Cypher is a declarative pattern-matching language in which graph patterns are drawn in ASCII art. It originated at Neo4j, was opened as openCypher in 2015, and is implemented by several other engines. Apache TinkerPop’s Gremlin is the other long-standing option, a traversal language with a more imperative feel.

In April 2024, ISO published ISO/IEC 39075:2024, the GQL standard, the first new ISO database language since SQL. GQL draws heavily on Cypher, and vendors have been aligning with it. For new code, Cypher is the practical choice and the syntax carries over to GQL more than it conflicts with it.

What this family is good at for a knowledge graph

Edge properties are the standout. A statement such as “this employment relationship began in 2019 and came from an HR export” attaches directly to the edge with no modeling workaround. Schema is optional and enforced through constraints on labels, which suits graphs that evolve alongside an application. Operational features are mature, because these products are used as primary application stores.

RDF triple stores

A triple store holds RDF: subject-predicate-object triples in which subjects and predicates are IRIs and objects are IRIs or typed literals. Most stores are really quad stores, adding a fourth position for a named graph, which turns out to matter a great deal for provenance.

Ontotext GraphDB, Stardog, Apache Jena with Fuseki, OpenLink Virtuoso, AllegroGraph, Blazegraph, Oxigraph, and Eclipse RDF4J are established members, and Amazon Neptune supports RDF alongside its property graph mode.

SPARQL and what comes with it

SPARQL 1.1 has been a W3C Recommendation since 2013 and covers querying, update, protocol, and result formats. Two capabilities have no equivalent in the property graph world. Federated query, through the SERVICE keyword, sends part of a query to a remote endpoint and joins the result locally, so a private graph can be queried against Wikidata in a single statement. CONSTRUCT returns a graph rather than a table, which makes queries composable: the output of one is valid input to the next.

Triple stores also load RDFS and OWL ontologies and can apply entailment, either materialized at load time or computed at query time, and most integrate SHACL validation. The model itself is described in RDF and the language in SPARQL.

What this family is good at for a knowledge graph

Global identifiers, standard serializations, and shared vocabularies. Two RDF datasets that use the same IRIs merge by union with no mapping work, and any RDF store can read Turtle, N-Triples, JSON-LD, or RDF/XML written by any other. That is the entire value proposition, and it only pays off when the data has to cross an organizational boundary.

The same question in both languages

The question: which organizations employ the most alumni of the University of Florida.

In Cypher, against a property graph:

MATCH (:University {name: "University of Florida"})<-[:EDUCATED_AT]-(p:Person)-[:WORKS_AT]->(o:Organization)
RETURN o.name AS employer, count(DISTINCT p) AS alumni
ORDER BY alumni DESC
LIMIT 10;

In SPARQL, against Wikidata, where wdt:P69 is “educated at” and wdt:P108 is “employer”:

PREFIX wdt:  <http://www.wikidata.org/prop/direct/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?employerLabel (COUNT(DISTINCT ?person) AS ?alumni)
WHERE {
  ?university rdfs:label "University of Florida"@en .
  ?person wdt:P69  ?university ;
          wdt:P108 ?employer .
  ?employer rdfs:label ?employerLabel .
  FILTER (lang(?employerLabel) = "en")
}
GROUP BY ?employerLabel
ORDER BY DESC(?alumni)
LIMIT 10

Run against Wikidata, that query returns the University of Florida itself at the top with several hundred alumni-employees, followed by other universities and government agencies. One detail is worth flagging: matching on a label string rather than on wd:Q501758 also matches anything else labeled “University of Florida”, and Wikidata happens to carry a power station by that name. It does no harm here, because a power station has no alumni and contributes no rows, but a query whose correctness matters should bind the entity by its Q-ID. The reasoning is at the Wikidata Query Service.

The two queries have nearly identical shapes: match a pattern, group, count, order, limit. The differences are informative. Cypher names the relationship types (EDUCATED_AT, WORKS_AT) as local strings that mean whatever the team decided they mean, while SPARQL names them as IRIs (wdt:P69) whose definitions are published and shared, so the query would run unchanged against any dataset using Wikidata’s properties. Cypher reads a display name from a node property; SPARQL has to join to rdfs:label and filter by language, because labels in RDF are ordinary triples and an entity commonly carries dozens of them.

Provenance and qualified statements

A trusted knowledge graph must record where each fact came from, and often when it was true. The two families solve this differently, and it is one of the more consequential modeling differences.

In a property graph, provenance goes on the edge. A WORKS_AT relationship carries since, source, and confidence properties directly, and queries filter on them without extra pattern matching. This is straightforward until a single fact needs several conflicting sources, at which point the edge has to be promoted into an intermediate node and the simplicity is gone.

In RDF, a plain triple has no room for annotation, so there are three approaches. Reification promotes the statement into a node with its own properties, which is the pattern Wikidata uses: its statement model separates the direct property (wdt:) from a full statement node (p:, ps:) that carries qualifiers (pq:, for example, a start date) and references (prov:wasDerivedFrom). Named graphs put each source’s triples in its own graph and attach metadata to the graph IRI, which is efficient when provenance is per batch rather than per fact. RDF-star, folded into the RDF 1.2 and SPARQL 1.2 work at the W3C and already supported by several stores, allows a triple to be the subject of another triple, which is closer to the property graph experience.

Named graphs have no property graph equivalent, and teams building integration graphs frequently find them the deciding feature. Loading each source system into its own named graph makes it simple to re-load one source, query a subset, or compare what two sources assert about the same entity.

Where each is the better fit

The honest answer is that the choice usually comes down to one question: does this data need to interoperate outside the organization?

If the graph will be published, exchanged with partners, aligned to public vocabularies, linked to Wikidata or DBpedia, or subjected to formal ontology and validation requirements, RDF is the right model and a triple store is the right engine. Standards compliance is the product here. Public sector, life sciences, cultural heritage, and cross-enterprise integration land in this group by default.

If the graph serves one application or one organization, relationships carry a lot of their own data, and the team is building features rather than publishing a dataset, a property graph database fits better, and the developer experience is smoother. Recommendations, fraud and risk analysis, network and dependency analysis, and operational entity resolution land here.

Secondary factors: whether inference is part of the design (RDF), whether write throughput on an operational path matters (property graph engines are generally more mature as primary stores), and what skills the team already has. Some deployments run both, exchanging in RDF and querying in an LPG store, which is what Neo4j’s neosemantics plugin supports. Product categories are listed in knowledge graph tools.

What happens at scale

Three things change as a graph grows past what one machine holds comfortably.

Graphs do not partition cleanly. Splitting a relational table by key is routine; splitting a graph means edges cross partitions, and every cross-partition traversal becomes a network hop. Distributed graph databases work best on queries that stay local to a neighborhood, and global traversals over a sharded graph get expensive.

High-degree nodes distort queries. A node with millions of edges, often a common type or category, turns an innocuous pattern into a scan of everything attached to it. Common remedies include modeling such categories as node properties rather than edges, or writing queries that expand from the selective end first.

Bulk loading is a separate discipline from transactional writing. Inserting a hundred million triples one statement at a time is impractical, and engines in both families ship an offline or batch import path that bypasses the transaction log. Plan the initial load around that tool, and measure the size of materialized inference before committing storage, since it can multiply the stored data several times over.

For developers

Model identifiers first. Whichever engine you choose, give every entity a stable external identifier and enforce uniqueness. In a triple store, that is the IRI, and the model does it. In a property graph, it is an ordinary property; a uniqueness constraint costs nothing and preserves the option to export to RDF later. See what is a knowledge graph for why identity is hard to retrofit.

For SEOs

No graph database is needed for entity work in search. Google reads schema.org markup from public pages, and the engine behind Google’s own graph is not public. A graph database becomes relevant when an organization maintains a large internal entity inventory feeding markup generation, where a query such as “every page describing an entity with no sameAs link” is genuinely a graph query.

Related pages

FAQ

What is a graph database used for?

Graph databases are used for workloads that follow chains of relationships: path finding, multi-hop pattern matching, recommendation, fraud and risk analysis, dependency and impact analysis, entity resolution, and knowledge graphs. They are a poor fit for large aggregate scans over columns, which relational and columnar systems handle better, so many deployments run a graph database alongside an existing warehouse.

Is Neo4j the same thing as a graph database?

Neo4j is one graph database, not the category. It uses the labeled property graph model and the Cypher query language, and other engines in the same family include Memgraph, TigerGraph, ArangoDB, and NebulaGraph. RDF triple stores such as Ontotext GraphDB, Stardog, and Apache Jena are graph databases too, using a different data model and the SPARQL language.

What is a triple store?

A triple store is a graph database built on the RDF model that stores subject-predicate-object triples, uses IRIs as identifiers, and is queried with SPARQL. Most are really quad stores, adding a named-graph position so triples can be grouped by source. Triple stores usually load RDFS and OWL ontologies, can apply inference, and support SHACL validation.

Are graph databases faster than SQL databases?

For traversal, they usually are, because relationships are stored as direct references and query cost tracks the part of the graph visited rather than the size of the tables. For aggregate scans and set-based reporting, relational and columnar systems are generally faster. The right comparison depends on the workload, and SQL:2023 added SQL/PGQ so some relational engines can now run graph patterns over relational data.

Sources and further reading

  • Neo4j, Cypher Manual: https://neo4j.com/docs/cypher-manual/current/
  • ISO/IEC 39075:2024, Information technology, Database languages, GQL: https://www.iso.org/standard/76120.html
  • W3C, RDF 1.1 Concepts and Abstract Syntax: https://www.w3.org/TR/rdf11-concepts/
  • W3C, SPARQL 1.1 Query Language: https://www.w3.org/TR/sparql11-query/
  • Apache Jena documentation: https://jena.apache.org/documentation/
  • Amazon Neptune documentation: https://docs.aws.amazon.com/neptune/
  • Wikidata, Data model primer: https://www.mediawiki.org/wiki/Wikibase/DataModel/Primer

Powered by CookieAdmin