A bank opens an account for a new customer and nothing on the form looks wrong, until someone notices the phone number belongs to another account, and that account shares an address with one closed for fraud. The record was clean. The problem was in the links between records. This video shows what a graph database does about that: every thing is a node, every link is a relationship stored beside the two nodes it joins, and each node keeps a direct path to its neighbours, so following a chain is a step rather than a join for every hop.
It shows how a graph is asked, by drawing the shape you want and letting the database walk the links as far as they go, and where that earns its place: fraud rings, supply chains, recommendations and access control. It then takes the same idea to knowledge graphs, facts about the world held as links, and to the AI systems that keep one beside their documents so they can follow connections as well as find similar text. It ends on the limit, a graph is hard to cut into pieces, which is why a graph database sits beside the other kinds.
Every claim was checked against Neo4j’s, Amazon Neptune’s and Azure Cosmos DB’s own documentation, the W3C’s RDF primer, Google’s 2012 Knowledge Graph announcement and Microsoft’s and Neo4j’s GraphRAG pages in September 2026. No product is recommended. This is an independent explainer, not affiliated with any vendor.
Transcript
A bank opens an account for a new customer, and nothing on the form looks wrong. Then someone notices the phone number belongs to another account, and that account shares an address with one closed for fraud. The record was clean, and the problem was in the links.
A relational database keeps those links as keys, with one table pointing to another. To follow one link, the database joins two tables. Every extra step adds another join, and each join is another search across a table, so the longer the chain, the slower it gets.
A graph database keeps the links as data in their own right. Graph here doesn't mean a chart with an axis. It means a set of dots joined by lines, where the dots are the things and the lines are the links.
Every thing is a node, whether it's a customer, a phone number or an address. Every link is a relationship, stored beside the two nodes it joins, with a name such as uses or registered at. Each node keeps a direct path to its neighbours.
Following a link is a step, not a search. From the new customer, the database steps to the phone number, then to the other account, then to the address, and then to the account that was closed. Each step costs the same however many customers the bank holds, because the path is already stored.
What the bank really wants to know is whether this customer is linked to anyone closed for fraud, at any distance. With tables, how many joins would that take?
Nobody can say, because the length of the chain is the answer you're after, and a graph query never counts joins. You draw the shape you want, one account sharing a phone or an address with another, and the database walks the links as far as they go and hands back the chain.
A graph database earns its place wherever the links matter more than the records. Fraud rings show up as accounts that share details, and a supply chain links suppliers, shipments and routes. Recommendations come from what other people also bought, and access control asks who can reach which system.
The same idea can hold facts about the world. Paris is the capital of France, and France is in Europe, each fact a link between two things. That is called a knowledge graph. Google built one in twenty twelve so that its search could understand things, not just strings of letters.
Some AI systems now keep one beside their documents. Finding similar text tells the AI what something resembles, and following the links tells it how things are connected. With both, it can answer a question that runs through several things at once.
A graph is hard to cut into pieces, because links cross every cut. That is why a graph database usually grows by making copies of the whole graph, rather than spreading it across thousands of machines.
If your questions never follow a chain, a plain table is the simpler home. A graph database sits beside it, and takes the questions about connection.
A graph database stores the links as data, and each thing keeps a direct path to its neighbours. Following a link is a step, not a search, however far the chain runs. When the question is who is connected to whom, this is the database built for it.
