What Is a Knowledge Graph? Connecting Data With Context

A knowledge graph represents information as a network of entities and the relationships between them — rather than as rows and columns in a table. Instead of storing "customer 1234 placed order 5678 for product 9012" as three rows in three tables connected by foreign keys, a knowledge graph stores it as three nodes (Customer, Order, Product) connected by two edges (PLACED, CONTAINS) with the relevant properties attached to each.

This sounds like a difference in representation rather than a fundamental architectural choice. For many use cases, it is. But for specific classes of problems — particularly those involving complex, multi-hop relationships, heterogeneous data types, and evolving schemas — the graph model provides capabilities that relational tables cannot match without significant engineering effort.

Core Concepts

**Nodes** (also called vertices or entities) represent things: people, products, locations, events, organizations, concepts. Each node has a type (label) and properties: a Person node might have name, age, and email properties.

**Edges** (also called relationships or predicates) represent the connections between nodes: PURCHASED, LOCATED_IN, WORKS_FOR, SIMILAR_TO, CAUSES. Edges are directed (A works for B, not necessarily B works for A) and can also carry properties: a PURCHASED edge might have a timestamp and quantity property.

**Triples** — in RDF (Resource Description Framework) knowledge graphs, information is stored as subject-predicate-object triples: (CustomerA, placed, Order123), (Order123, contains, ProductX). A knowledge graph is a collection of such triples that forms a connected graph.

**Ontology** — the schema for a knowledge graph: what types of nodes exist, what types of edges are valid between what types of nodes, what properties are required or optional. An ontology is the formal definition of the domain the graph represents.

Why Graph Over Relational?

For analytical queries that involve multiple joins, relational databases handle them adequately up to a point. But certain query patterns are architecturally awkward in a relational model:

**Variable-depth traversal** — "find all people who influence this influencer's network up to 5 degrees of separation." In a relational database, this requires either recursive CTEs (complex, often slow) or multiple self-joins with fixed depth (inflexible). In a graph database, it is a single traversal query.

**Pattern matching across heterogeneous entities** — "find all the entities (customers, partners, devices) that interacted with this account in the 72 hours before a fraud event." In a relational model, these are different tables requiring multiple union queries. In a graph, they are nodes of different types that can be traversed uniformly.

**Schema flexibility** — relational schemas require knowing ahead of time what properties a record will have. Knowledge graphs can represent entities with variable sets of properties without nullable columns for every possible attribute.

**Relationship-first queries** — when the interesting question is about the structure of relationships rather than the properties of records (who knows whom, what is connected to what), graph traversal is more natural than relational joins.

Enterprise Use Cases

**Fraud detection and financial crime** — financial institutions use knowledge graphs to model the network of accounts, transactions, devices, IP addresses, merchants, and individuals involved in payment flows. Graph traversal detects circular payment patterns, shared device identifiers across multiple accounts (mule networks), and relationship networks that match known fraud topologies. Relational joins across these networks at the required depth are not practical at transaction monitoring scale.

**Customer 360** — connecting customer identities across touchpoints: CRM records, e-commerce transactions, support tickets, loyalty programs, website sessions. A knowledge graph can represent a single customer as a node connected to all their associated identifiers and interactions, enabling unified queries across the full relationship graph regardless of which system holds each piece of data.

**Enterprise knowledge management** — connecting documents, people, skills, projects, and organizational structures. A knowledge graph can answer "who in this organization has worked with this technology on a similar problem" by traversing People — Skills — Projects — Technologies — Projects — People.

**Supply chain and operations** — modeling relationships between suppliers, components, products, facilities, and logistics entities. Impact analysis when a component supplier fails requires understanding the multi-hop relationship between that supplier and every finished product it affects — a graph traversal problem.

**Recommendation systems** — knowledge graphs power recommendation engines at companies like Google, Amazon, and LinkedIn by modeling the relationships between users, content, products, and behaviors. Item similarity, collaborative filtering, and contextual recommendations can all be framed as graph problems.

Knowledge Graphs in AI and Retrieval

Knowledge graphs have become relevant in the AI context as a way to ground language model outputs in structured, verified facts — addressing the hallucination problem.

Retrieval-Augmented Generation (RAG) systems that rely purely on vector search retrieve semantically similar text chunks but cannot reason about explicit structured relationships. A knowledge graph can answer "what is the current CEO of Company X" with a definitive graph lookup, whereas vector search retrieves relevant text that may be outdated.

GraphRAG — combining knowledge graph traversal with vector retrieval — is an emerging pattern for AI systems that need both semantic similarity and relationship-structured facts. Microsoft released an open-source GraphRAG implementation in 2024 that constructs a knowledge graph from document corpora and uses it to answer multi-hop questions.

Graph Database Technologies

**Neo4j** — the dominant commercial graph database. Uses the Cypher query language, which is relatively readable for expressing graph traversal patterns. Available as managed cloud service (Aura). Has the largest ecosystem of connectors, libraries, and tooling in the graph database space.

**Amazon Neptune** — fully managed graph database on AWS. Supports both property graph (Gremlin query language) and RDF/SPARQL query models. Integrates with IAM and other AWS services.

**TigerGraph** — purpose-built for large-scale graph analytics. Notable for performance on multi-hop traversal queries at enterprise scale; used by financial institutions for real-time fraud detection.

**Apache Jena** — open-source Java framework for RDF and SPARQL. Common in academic and semantic web contexts. Not a database; more of a toolkit for building RDF applications.

**Stardog** — enterprise knowledge graph platform with strong ontology management, federated query capabilities, and AI integration. Common in life sciences, financial services, and government.

When to Consider a Knowledge Graph

Consider a graph database when:

- Core queries involve multi-hop relationship traversal (friends of friends, supply chain upstream dependencies, fraud network analysis)

- Entities have highly variable properties that do not fit naturally into a fixed-schema table structure

- The relationships between entities are themselves the most important data — not just the entity properties

- You are building a recommendation engine or personalization system where relationship topology drives relevance

- You need to integrate heterogeneous data sources where entities are the common thread

A relational data warehouse remains the right choice when:

- The primary use case is aggregate analytics across large volumes of structured data

- Queries are primarily filters, joins, and aggregations on known schemas

- Your team has strong SQL skills and limited graph query language familiarity

- The relationship depth in your queries does not exceed what recursive CTEs handle adequately

Our data architecture practice evaluates data model and storage architecture options including graph databases for appropriate use cases — contact us to discuss whether a knowledge graph fits your requirements.

A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.