Graph has had three waves of attention. First the Gartner years, when every analytics vendor shipping natural language query got asked whether it ran on a knowledge graph. Then COVID, when the companies with a graph foundation could trace a supplier problem upstream and downstream while everyone else guessed. Now AI, and every conversation comes back to graph again.
Emil Eifrem has built through all three. He coined the term "graph database" two decades ago and runs Neo4j. Prukalpa Sankar opened with the challenge: modelling the world as relationships makes obvious sense, it demos beautifully, and it has stayed niche for twenty years.
They agreed on the diagnosis and split on one question. Do those relationships have to be physically moved into a graph database for an agent to use them?
Q: Graph databases have been around for twenty years. Why is everyone talking about them now?
Two things made graph hard to adopt, and both changed inside the last 12 to 18 months.
The first was modelling. Getting data into a graph meant starting from a blank sheet. Now you point Neo4j's cloud service at a Postgres database and it reads the tables and converts the model into a graph on its own. That works because the popular database models are isomorphic, meaning you can move data between them without losing anything. Warehouses have no foreign keys, so the conversion is harder there, and Eifrem puts the accuracy at roughly 80% with the models of a year ago and 90% today.
The second was the query language. Cypher, now standardised as GQL, is the only formal sibling SQL has ever had, and learning it used to be a real cost. Speaking English at it removes that cost.
"All of a sudden the two major barriers to adoption for graph databases, they just look completely different today compared to even 12 to 18 months ago."
The history explains why graph stayed niche. Neo4j's position was always that the one-size-fits-all database era was over, not that everything would become a graph. Graph won where the pain left no choice: fraud detection that has to traverse deep in under a millisecond, or customer journey work where minutes were not an answer. Eifrem calls those the antibiotics use cases. Everything else stayed in tables, even though almost every domain model anyone draws on a whiteboard is already a graph.
Q: Ontology, knowledge graph, graph database, context graph. Which is which?
Eifrem admitted the vocabulary is a mess before untangling it.
"I do have some kind of terminology fatigue right now. There used to be cloud washing back in the days. I feel like we have some version of ontology washing going on."
- Ontology. The concepts in your business and how they relate, described the way your colleagues talk about the business. Eifrem calls this a business-facing ontology, and his design rule is concrete: agents do not ask for cust_f_name, they ask for the customer's first name.
- Knowledge graph. The ontology is the schema. Add the instances and you have a knowledge graph. His analogy: the ontology is the tables, the instances are the rows.
- Graph database. A transactional database that exposes nodes and relationships instead of rows and columns. Neo4j popularised the property graph model. The alternative representation is RDF, usually called a triple store.
- Context graph. Named by Foundation Capital last December. Your systems of record hold what is true right now and your warehouse holds the past. Neither holds why. A $50,000 customer sits in the CRM at a discount, and the reason was a phone call to a sales VP that no system ever recorded.
Eifrem would rename that last one.
"A more accurate name would have been something like decision trace graph."
The most useful answer came when Prukalpa asked whether a knowledge graph needs a graph database underneath it. It does not. Because the models are isomorphic, a knowledge graph can sit in Postgres, Mongo or DynamoDB without losing anything. Eifrem's claim is narrower than the category noise suggests: Neo4j wants to be the easiest place to store one at scale, not the only place one can exist.
Prukalpa's addition was that the expensive part of an ontology was never the concept, it was the upkeep, which is why Palantir deploys application by application and never company-wide. Connect your warehouses, trace lineage end to end through your systems of record and BI, and you can reverse-construct the semantics and then the ontology from them. Her caution: throwing tables at a model produces something that looks beautiful and is not accurate, so the real work is applying pre-AI data quality discipline to what Atlan calls context quality.
Q: What is graph actually doing for AI today?
Almost all of it is retrieval. Eifrem put the share of what Neo4j sees at around 95%, and the case for it rests on a precedent rather than a benchmark.
An agent answering a support question has to pick roughly ten documents out of a hundred thousand and hand them to the model. Semantic search alone gets you part of the way. The same problem was solved once before at internet scale: before Google there was AltaVista, and the complaint was never too few answers, it was that the right answer sat on page 93. PageRank fixed it by linking documents together and weighting them, which is a graph algorithm. Apply that principle to agent retrieval and accuracy goes up.
Two side effects matter as much as the accuracy. Development gets faster, because vector space is opaque and only tells you two things are 0.7 similar, where a graph tells you an apple and an orange are related through fruit. And you get auditability, which is why banks and regulators care.
Memory is the second workload, and Eifrem's evidence that it is graph-shaped is that people who do not sell graphs keep arriving there anyway. The memory implementation shipped in the original MCP spec is 500 lines of Python running in RAM, a toy by his own description, and it is a graph. The startups building agent memory on Neo4j include Cognee, Zep and Mem0.
The technique worth stealing is what happens next. Agent traces go into the graph, a background process distils them into a skill, and the skill is then grounded back to the memory it came from.
"As your memory is evolving dynamically, you can detect that the skill is stale."
Q: Does my data have to move into a graph database?
This is where they split, and Prukalpa granted the premise before pressing on it.
"I'm convinced AI needs relationships. Graph theory, AI needs 100%. It'll make AI better. Do we need to manifest all of this in a graph database?"
Eifrem said yes, then described an architecture that makes the answer less binary. Neo4j's virtual graph runs the product portfolio on top of your Snowflake or Databricks with no copy of the data. A query written in English becomes Cypher or GQL and gets pushed down into the warehouse as predicates, which is how it holds up at petabyte scale. It is in early access now.
What does not exist yet is the slider. The intent is that you start with no copy and slide toward materialising the parts that need speed, so a 10 or 20 hop traversal returns in milliseconds from a native graph underneath. By his own count there are three principles: full ecosystem integration, no copy, and the slider.
"We have the first two, the third one we're working on right now."
He was equally clear about the limit. Sub-millisecond fraud detection, the case that turns detection into prevention, should not run on a virtual graph. If a couple of seconds is acceptable it works for most queries, and he said most rather than all deliberately.
The unsolved part is knowing in advance which is which. You start from a business problem, not from a query plan, and Eifrem is wary of a system that guesses on your behalf. His reference point is that it took the industry decades to settle the line between OLTP and OLAP. Prukalpa's counter stands unresolved: moving data is friction, and data has gravity.
Both landed on the same advice, and it was not about graphs. Every vendor is washing the same terms, and every current approach to retrieval is about to change. Prukalpa's example: Claude Code retrieves skills 49% of the time and Codex 99%, a fifty-point gap on a construct Anthropic invented. Start from a business problem, solve that, then work backward to the concepts and the words. Then go build something yourself.
Episode six picks up where Eifrem left off. Jaya Gupta of Foundation Capital, who named the context graph, joins Austin on September 2 to work through what one has to hold and where it stops. Register here.
