Knowledge Graph
Also known as: graph database, semantic knowledge base, entity graph, ontology
A knowledge graph is a structured way of storing information that represents real-world entities (people, places, organisations, concepts) and the relationships between them as a connected network.
Unlike a traditional relational database that stores data in rows and columns, a knowledge graph explicitly encodes the relationships: 'Paris is the capital of France', 'Marie Curie was born in Warsaw', 'Aspirin treats headaches'. This structure makes it possible to answer complex queries about connections that would require many table joins in a traditional database, and to discover non-obvious relationships between entities.
Knowledge Graph, explained at three levels
At home
A knowledge graph is like a web of facts stored as connected dots. Each dot is a thing -- a person, a place, a product, a concept -- and the lines between dots show how things relate. 'Paris is the capital of France' is one connection. 'The Eiffel Tower is in Paris' is another. By following the connections, you can answer questions like 'Which buildings are in the capital of France?' without needing to know that answer directly stored anywhere.
At work
Knowledge graphs are used in enterprise settings to connect data across systems that were designed independently. A company might have customer records in their CRM, product data in their ERP, and support ticket history in a helpdesk tool -- three systems that cannot easily be queried together. A knowledge graph built over these systems links the same customer entity across all three, making it possible to ask relationship-based questions like 'which customers who bought Product X in the last six months have open support tickets?'
At home
Knowledge graphs are stored in graph databases, which are optimized for traversing connections between entities rather than scanning rows. The underlying data model (typically RDF or property graphs) represents each fact as a triple: subject-predicate-object. SPARQL is the query language for RDF-based graphs; Cypher is the query language for property graph databases like Neo4j. Graph databases are significantly faster than relational databases for multi-hop relationship queries.
At work
Knowledge graphs play an important role in large language model applications. Retrieval-augmented generation (RAG) systems that ground LLM outputs in factual company data increasingly use knowledge graphs as the retrieval source, allowing the LLM to answer questions that require navigating relationships between entities -- not just retrieving similar documents. This combination is particularly powerful for compliance, legal, and research applications where factual accuracy about entity relationships matters.
At home
Google's public Knowledge Graph (powering 'knowledge panels' in search results) contains billions of facts about people, organizations, places, films, and other entities. It is populated from sources including Wikipedia, Wikidata, and structured data from trusted websites. These facts are used to enhance search results with direct answers, related searches, and entity disambiguation (telling apart the Jaguar car brand from the Jaguar animal). Enterprise knowledge graphs for internal use are built and maintained by the organization rather than from public data.
At work
From a practitioner standpoint, the key challenge in knowledge graph implementation is data quality and entity resolution -- correctly identifying when two records across different systems refer to the same real-world entity. A customer record in the CRM and a billing record in the ERP may both refer to the same company with slightly different name formatting. Entity resolution (determining they are the same node in the graph) requires fuzzy matching, rule-based logic, or ML-based disambiguation. Poor entity resolution produces a fragmented graph where the same real-world entity appears as multiple disconnected nodes.
Real-world examples
At home
Lena researched her family tree using an online genealogy tool built on a knowledge graph. When she added her great-grandmother to the tree, the system automatically suggested a connection to a historical document it had indexed, linking her family to a village in Ukraine that matched the birth record -- a connection the system inferred by traversing entity relationships, not by finding an exact name match.
At work
The compliance team at Northgate Legal built a knowledge graph connecting lawyers, clients, matters, and industry sectors across their case management and CRM systems. This allowed them to run conflict-of-interest checks (is any lawyer in our firm connected to anyone on the opposing side through any matter?) in seconds -- a query that previously required manual searching across multiple systems.
How it compares
| Feature | Knowledge Graph | Relational Database | Document Database |
|---|---|---|---|
| Data model | Entities and typed relationships (nodes and edges) | Rows and columns with foreign key references | Flexible document structures (JSON/XML) |
| Relationship queries | Native -- designed for multi-hop traversal | Possible via JOINs but slow at scale | Poor -- documents do not model relationships natively |
| Schema | Flexible; schema can evolve as new entity types are added | Rigid; schema changes require migrations | Schema-less or loose schema |
| Best for | Connected data, relationship discovery, semantic reasoning | Transactional data with well-defined structure | Unstructured or variable-schema content at scale |
| Examples | Neo4j, Amazon Neptune, Google Knowledge Graph | PostgreSQL, MySQL, Oracle | MongoDB, Couchbase, Firestore |
Knowledge graphs excel at relationship traversal and semantic queries. Relational databases are better for structured transactional data with well-defined schemas. Document databases handle unstructured variable content. Most enterprise data architectures use a combination.
For analysts
In BA artefacts, knowledge graph requirements appear when requirements involve connecting disparate entities across systems or answering relationship-based questions. When eliciting requirements, listen for phrases like 'we want to know who is connected to who' or 'we need to see the relationship between X and Y across different systems' -- these signal knowledge graph use cases. Specify entity resolution rules as explicit requirements: 'Customer records from CRM and billing must be matched using a combination of company name, registration number, and postal address, with a confidence threshold of 95% before automatic merging.'
History & origin
The concept of semantic networks (representing knowledge as connected nodes) dates to the 1960s in cognitive science. Practical large-scale knowledge graphs emerged with Google's Knowledge Graph (2012), which Google used to enhance search results with factual summaries derived from connected entity data. Wikidata (2012) created a publicly available knowledge graph derived from Wikipedia. Enterprise knowledge graph products (Neo4j, Amazon Neptune, Microsoft Azure Cosmos DB graph API) expanded adoption to commercial applications in search, recommendation, and fraud detection.