A knowledge graph stores information as entities and named relationships instead of only rows and columns. It is useful when the question is about how things connect: customers, companies, products, documents, owners, systems, and the links between them.
A knowledge graph stores information as a network of entities and relationships. The entities are the things your data is about: customers, products, companies, people, invoices, dashboards, datasets, suppliers, or documents. The relationships explain how those things connect: customer placed order, person manages company, table feeds report, supplier delivers product.
The important part is that the relationship has meaning. A normal table may store customer IDs and product IDs. A graph says what those IDs represent and how they relate. That makes it stronger for questions where the path between things matters.
Google made the term widely known in 2012 with its Knowledge Graph and the phrase things, not strings: search should understand entities and relationships, rather than just matching words.
A knowledge graph usually has three building blocks.
Nodes
Nodes are entities. A node can be a customer, product, person, company, table, policy, ticket, or legal entity. Nodes often carry labels such as Customer, Product, or Dashboard.
Relationships
Relationships connect nodes and describe the connection. A customer placed an order. A dashboard uses a semantic model. A company owns another company. Relationships normally have a direction and a name.
Properties
Nodes and relationships can carry attributes: name, date, amount, source, confidence, role, country, or status. A relationship can have its own properties too, such as the date when a person became a director.
That is the mental shift: data lives in the entities and in the connections between them.
Two technical families appear often.
RDF graphs
RDF is a W3C standard. It represents knowledge as triples: subject, predicate, object. For example: Bob knows Alice. RDF is strong when data has to be linked across organisations, public vocabularies, or open standards. SPARQL is the query language most associated with RDF.
Property graphs
Property graphs store nodes and relationships with labels and properties. Neo4j is the best-known example. Developers often like this model because it feels direct: draw the entities, draw the relationships, query the pattern. Cypher is the best-known query language in this world, and it influenced the ISO GQL graph query standard.
Both families model connected data. The right choice depends on whether standards-based data exchange or application-oriented graph querying matters more.
Relational databases are excellent at structured records and aggregates. To answer a relationship question, they use joins. One or two joins are fine. Many hops can become hard to write, hard to optimise, and hard to explain.
A graph starts from the connection. If the question is which customers are connected to this supplier through a shared director?, the graph follows the path: supplier, director, company, customer. The query describes a pattern rather than a chain of table joins.
This does not make graphs better for everything. If the question is revenue by month, a warehouse table is simpler. A graph earns its place when the relationships themselves are the subject.
Data catalogs and metadata. Tables, dashboards, owners, glossary terms, quality rules, and lineage are connected by nature. A graph can show what depends on what.
Fraud detection. Fraud rings often share addresses, devices, accounts, phone numbers, or company officers. The pattern is easier to see as a network.
Master data and entity resolution. A graph can help connect records that refer to the same real-world customer, company, or product.
Recommendations. Products, users, purchases, views, and categories form a network that can support recommendations.
GraphRAG. Some RAG systems use a graph of entities and relationships instead of relying only on text chunks and vector similarity. That can help with broad questions about themes, connections, and provenance.
An ontology defines the vocabulary and rules: what kinds of entities exist, which relationships are allowed, and what those terms mean. A knowledge graph is the populated network: the actual customers, products, documents, systems, and relationships.
They work together. The ontology gives the graph shape. The graph gives the ontology data.
In smaller projects, the ontology may be a simple schema and naming convention. In regulated or cross-organisation settings, it may be a formal model with controlled vocabularies.
Entity resolution comes first
If the same customer appears as three separate nodes, the graph will split relationships that belong together. Matching and deduplication are not optional.
Do not graph everything
If your main use case is ordinary reporting, use a warehouse or lakehouse. Graphs are for connected questions.
Relationship names matter
A vague relationship such as related to quickly becomes useless. Name relationships in business language.
GraphRAG is not magic
A graph can improve retrieval for some questions, but bad extraction, weak entity matching, or stale source documents still produce weak answers.
Governance still applies
A graph can reveal sensitive connections. Access control, lineage, and classification matter as much as in a relational system.
ABAC decides access by evaluating attributes of the person, the resource, the action, and the context against a policy, instead of by member...
Read definitionA business glossary is the agreed list of what your business words mean. It records terms like revenue, active customer, margin and churn in...
Read definitionA business key is the identifier a business already uses to recognise something real, like an invoice number, VAT number, EAN or employee nu...
Read definitionA data catalog is a searchable inventory of an organisation's data assets. It records metadata such as owner, schema, description, lineage, ...
Read definitionA data clean room is a controlled environment where two or more parties analyse their combined data without either side seeing the other's r...
Read definition