What Are Knowledge Graphs? A Practical Introduction

From Tables to Networks

Most software engineers are trained to think in tables. Relational databases, spreadsheets, ORMs — rows and columns are the default mental model for data. But the world doesn't organise itself into tables. Relationships between entities are often more important than the entities themselves.

A knowledge graph is a data structure that puts relationships first. Instead of a users table and a purchases table joined by a foreign key, a knowledge graph represents everything as interconnected nodes and edges.

Core Concepts

Nodes (Vertices)

Nodes represent entities — people, places, concepts, events. Each node has a unique identifier and can carry properties:

Node: Paris
  type: City
  population: 2.1M
  country: France

Edges (Relationships)

Edges represent connections between nodes. In a property graph, edges are directional and can carry their own properties:

(Paris) -[capital_of]-> (France)
  established: 508 AD

Labels and Types

Nodes and edges are typed. This is what separates a knowledge graph from a generic graph database:

• Node labels: City, Company, Person, Technology
• Edge types: capital_of, employs, developed_by, depends_on

RDF vs Property Graphs

Two dominant models exist:

RDF (Resource Description Framework)

The semantic web standard. Everything is a triple: subject → predicate → object.

@prefix ex: <http://example.org/> .
ex:Paris ex:capitalOf ex:France .
ex:France ex:hasPopulation 67M .

• Strengths: Web-native, standardised (W3C), linked data principles
• Query language: SPARQL
• Best for: Data integration, open data, cross-domain linking

Property Graph Model

The model used by Neo4j, Amazon Neptune, and ArangoDB:

CREATE (p:City {name: "Paris", population: 2100000})
CREATE (f:Country {name: "France", population: 67000000})
CREATE (p)-[:CAPITAL_OF]->(f)

• Strengths: Intuitive, performant for graph traversals, flexible schema
• Query language: Cypher (Neo4j), Gremlin (Apache TinkerPop)
• Best for: Transactional applications, real-time recommendations, fraud detection

Building a Knowledge Graph: A Practical Walkthrough

The best way to understand knowledge graphs is to build one. Let's model a small technology ecosystem — companies, their products, and the technologies those products depend on — and run meaningful queries against it.

Prerequisites

You need a running Neo4j instance. The quickest path:

docker run --publish=7474:7474 --publish=7687:7687 \
  -e NEO4J_AUTH=neo4j/password neo4j:2025

Seeding the Graph with Python

Install the Neo4j Python driver and connect:

pip install neo4j

from neo4j import GraphDatabase

driver = GraphDatabase.driver(
    "bolt://localhost:7687",
    auth=("neo4j", "password")
)

def seed_graph(tx):
    # Create companies
    tx.run("""
        MERGE (a:Company {name: "Acme Corp", founded: 2015, region: "EU"})
        MERGE (b:Company {name: "Beta Inc", founded: 2018, region: "NA"})
    """)
    # Create products with dependencies
    tx.run("""
        MATCH (a:Company {name: "Acme Corp"})
        MATCH (b:Company {name: "Beta Inc"})
        MERGE (p1:Product {name: "AcmeCloud", version: "3.2"})
        MERGE (p2:Product {name: "BetaSync", version: "1.9"})
        MERGE (a)-[:DEVELOPS]->(p1)
        MERGE (b)-[:DEVELOPS]->(p2)
    """)
    # Create technology nodes and dependencies
    tx.run("""
        MERGE (neo:Technology {name: "Neo4j", type: "Database"})
        MERGE (py:Technology {name: "Python", type: "Language"})
        MERGE (k8s:Technology {name: "Kubernetes", type: "Orchestration"})
        MATCH (p1:Product {name: "AcmeCloud"})
        MATCH (p2:Product {name: "BetaSync"})
        MERGE (p1)-[:DEPENDS_ON]->(neo)
        MERGE (p1)-[:DEPENDS_ON]->(py)
        MERGE (p1)-[:DEPENDS_ON]->(k8s)
        MERGE (p2)-[:DEPENDS_ON]->(py)
    """)

with driver.session() as session:
    session.execute_write(seed_graph)

Querying the Graph

Once seeded, find every product that depends on Python and the company behind it:

MATCH (tech:Technology {name: "Python"})<-[:DEPENDS_ON]-(prod:Product)<-[:DEVELOPS]-(company:Company)
RETURN company.name AS Company,
       prod.name AS Product,
       prod.version AS Version
ORDER BY company.name

Company	Product	Version
Acme Corp	AcmeCloud	3.2
Beta Inc	BetaSync	1.9

This single traversal crosses three node labels and two relationship types — in a relational database it would require at least three JOIN operations. The graph model makes such multi-hop queries natural.

Finding the Blast Radius

A more powerful pattern: find all technologies reached through a product's dependency chain:

MATCH (company:Company {name: "Acme Corp"})-[:DEVELOPS]->(:Product)-[:DEPENDS_ON*1..3]->(tech:Technology)
RETURN DISTINCT tech.name AS Technology,
       tech.type AS Type
ORDER BY tech.name

This is the same blast-radius traversal used in dependency graph analysis, as explored in detail in Knowledge Graphs for Vulnerability Prioritisation.

Knowledge Graph Platforms Compared

Choosing the right platform depends on your query patterns, deployment model, and budget:

Platform	Model	Query Language	Cloud	Self-Hosted	Best For
Neo4j	Property Graph	Cypher	Aura	Yes	General-purpose graph apps, AI context layer
Amazon Neptune	Property Graph + RDF	Gremlin + SPARQL	AWS only	No	AWS-native infrastructure
ArangoDB	Multi-model (Graph + Doc + KV)	AQL	ArangoDB Cloud	Yes	Polyglot persistence
TigerGraph	Property Graph	GSQL	TigerGraph Cloud	Yes	Large-scale graph analytics
FlureeDB	RDF (semantic graph)	SPARQL + FlureeQL	Fluree Cloud	Yes	Data provenance, access control
Apache Jena	RDF	SPARQL	No	Yes (library)	Semantic web research, small-scale RDF
Apache TinkerPop	Property Graph (framework)	Gremlin	No	Yes (library)	Polyglot graph backends

Neo4j is the most popular choice for AI-augmented applications because its Cypher query language integrates natively with vector and full-text search, enabling the hybrid retrieval patterns that power modern GraphRAG — covered in Introduction to GraphRAG.

Why Knowledge Graphs Matter for AI

Structured Knowledge for LLMs

Large language models are stateless pattern matchers. They don't know things — they predict tokens. A knowledge graph provides:

1. Factual grounding: Graph queries return verified facts, not probabilistic completions
2. Relationship traversal: Answer multi-hop questions ("Which employees of Company X worked on projects using Neo4j?")
3. Consistency: The same fact queried twice returns the same result
4. Provenance: Every edge can carry a source attribution, answering "where did this fact come from?"

GraphRAG

Combining retrieval-augmented generation (RAG) with knowledge graphs produces GraphRAG — a pattern where:

1. User query is parsed into a graph query
2. The graph returns structured sub-graph results
3. Results are formatted as context for the LLM prompt
4. LLM generates a response grounded in the graph data

This is explored in depth in Introduction to GraphRAG, but the key insight is: graphs give LLMs a reliable memory. Unlike vector embeddings, which capture semantic similarity, a graph captures explicit facts and their relationships — so when an LLM needs to answer "What products does Acme Corp own?" the answer is deterministic, not probabilistic.

The context-layer approach is now being adopted by major cloud providers. As discussed in Knowledge Graphs as Context Layer for AI Agents, AWS Context, Neo4j Document Intelligence, and Databricks Genie Ontology all launched within weeks of each other in June 2026 — each combining vector search with graph traversal to give AI agents structured context.

When Vector Search Is Not Enough

Consider a customer support agent that needs to answer: "Which of our products were affected by the log4j vulnerability?" A pure vector RAG pipeline retrieves chunks mentioning "log4j vulnerability." A graph-backed retriever starts with those chunks, then traverses from Vulnerability → Component → Product → Customer to produce a structured answer. The difference is the difference between finding relevant text and answering the question.

Common Knowledge Graph Use Cases

Domain	Application	Graph Pattern
Fraud detection	Identify money laundering rings	Multi-hop traversal across accounts and transactions
Recommendations	"Customers who bought X also bought Y"	Collaborative filtering via shared-purchase paths
Supply chain	Identify single points of failure	Dependency-chain traversal, blast-radius analysis
Healthcare	Drug-target interaction discovery	Bipartite graph of compounds and proteins
Security	Vulnerability prioritisation	CVE → Component → Application → Exposure path
Enterprise search	Query-aware document retrieval	Hybrid vector + graph traversal (GraphRAG)

Ontology: The Hidden Foundation

A knowledge graph is only as useful as its schema — called an ontology. An ontology defines:

• What node labels exist (Company, Product, Technology)
• What properties each label carries (version, region, founded)
• What relationship types connect them (DEVELOPS, DEPENDS_ON)
• What constraints enforce data quality (normalizedName IS UNIQUE)

A well-designed ontology separates a queryable knowledge graph from a tangled mess of nodes. For a deep dive into ontology design patterns — including the signal normalisation pattern, the entity-vs-value rule, and how to test your ontology — see Ontology in Graph Databases.

Getting Started

Here is a structured path from zero to your first knowledge graph:

1. Run Neo4j locally:

   docker run --publish=7474:7474 --publish=7687:7687 -e NEO4J_AUTH=neo4j/password neo4j:2025
   

   Open http://localhost:7474 in your browser to access the Neo4j Browser — an interactive console for writing and visualising Cypher queries.

2. Learn the Cypher essentials:

   • MATCH finds patterns in the graph — MATCH (n:Person) RETURN n.name
   • CREATE adds nodes and relationships — CREATE (p:Person {name: "Alice"})
   • MERGE creates only if it doesn't already exist — prevents duplicates
   • WHERE filters — WHERE n.age > 30
   • MATCH with variable-length paths — (a)-[:KNOWS*1..3]->(b) for multi-hop queries

3. Model a small domain: Start with something you know well — your music library (artists, albums, tracks, genres), a project dependency tree, or a customer journey. The smaller the domain, the faster you can iterate on the ontology.

4. Connect it to an LLM: Use the Neo4j Python driver as shown above. Query the graph, format the results as context, and feed them into any LLM. The neo4j-graphrag Python library provides pre-built retrievers for hybrid (vector + graph) search patterns.

5. Iterate on the ontology: Your first schema will be wrong. That is normal. Graph databases support schema evolution more gracefully than relational databases — you can add new labels, relationship types, and properties without migrating existing data.

Further Reading

• Introduction to GraphRAG — Deep dive into GraphRAG patterns and implementation
• Ontology in Graph Databases — Building structured knowledge with the LeadGraph project
• Knowledge Graphs as Context Layer for AI Agents — Why every major cloud vendor now has a graph-based context offering
• Knowledge Graphs for Vulnerability Prioritisation — Dependency blast-radius analysis in action
• Neo4j Database Adapters Compared — Choosing the right driver (Python, JS, Java, Go, .NET) for your stack
• Graph Theory 101 — The mathematical foundations behind every graph database
• Neo4j. Graph Data Modeling Core Principles. GraphAcademy. https://neo4j.com/graphacademy/training-gdm-40/03-graph-data-modeling-core-principles/
• Neo4j. The Neo4j Cypher Manual. https://neo4j.com/docs/cypher-manual/current/
• Hogan, A. et al. Knowledge Graphs. ACM Computing Surveys, 2021. https://doi.org/10.1145/3447772 — Comprehensive survey covering KG construction, querying, and applications.

A knowledge graph is not a silver bullet. For simple CRUD apps that never query across relationships, PostgreSQL is the right tool. But when your data's value comes from how things connect, a knowledge graph becomes indispensable. Start small, iterate on the ontology, and let the structure of your domain guide the graph.