Graph Engineering

Data can be organized in very different ways. The most familiar is the table: each row a customer, each column an attribute. A graph arranges the same information differently. It consists of points for things and lines for relationships between those things. “Anna works at Siemens” thus becomes two points and a line between them. Graph engineering refers to the entire practical work involved in building such networks: deciding which things become points, collecting data from many sources, merging duplicates, and storing the whole thing so that programs can search it quickly.

Why relationships get lost in tables

Tables are powerful when you’re counting or summing similar things. They become unwieldy as soon as relationships are the actual information. The question “Which companies are connected to this company through shared board members?” requires many nested search steps in a classic database. In a graph, you simply follow the lines, the way you’d follow a route on a map.

Exactly these kinds of questions are economically valuable. Banks search for flows of money through multiple intermediary accounts. Insurers detect fraud rings by noticing that the same assessors and repair shops keep showing up. Authorities check who actually owns a company through chains of subsidiaries. Without a clean graph structure, these patterns remain invisible.

A second reason has emerged in recent years: language models like ChatGPT occasionally invent facts. A vetted graph can serve as a reliable reference source. The model then pulls real relationships from the network instead of guessing them.

From raw file to connected network

At the start comes a decision about the schema, i.e. the blueprint. You define which types of points exist, such as person, company, product. Then you determine the permitted types of relationships, such as “is employed by” or “supplies to”. This blueprint sounds dry, but it determines almost everything that follows. A blueprint that’s too fine-grained becomes unmaintainable; one that’s too coarse fails to answer the later questions.

The most labor-intensive step is called deduplication. In accounting it says “Siemens AG”, in the sales system “Siemens Aktiengesellschaft”, in an Excel list just “siemens”. For the graph, these must become a single point, otherwise the network falls apart into disconnected islands. This is done using rules, similarity comparisons of spellings, and increasingly also models that check text passages for closeness in meaning.

The graph is then stored and queried. There are dedicated databases with their own query languages for this, such as Cypher or SPARQL. Ongoing operation matters: companies merge, people change jobs, supply chains shift. Graph engineering is therefore continuous work, not a one-off project.

Knowledge graphs at Google, Amazon, and in job postings

The result is most visible in search engines. When Google shows a box next to the results with a birth date, films, and related people, that comes from a knowledge graph. Product recommendations in online shops are also often based on graphs of customers, items, and purchases. Social networks calculate from their relationship network which contacts to suggest to you.

In the news, the term is most often encountered in the context of enterprise data and AI. Companies like Neo4j, Databricks, or Palantir advertise connecting scattered data holdings into a searchable network. Currently popular is the combination of graph and language model, often referred to as GraphRAG. In this approach, the system first searches the graph for documented relationships and only afterward formulates the answer.

A common misconception is that graph engineering is mainly programming. The larger part is understanding the subject domain: What actually counts as a thing here, what counts as a relationship? Anyone who answers these questions wrong ends up building a technically clean network that no one can actually use.