Emil Eifrem on Neo4j, Graph Databases, Connected Data & Graph-Native AI

Chapter 1 — 00:00 | Introduction & The “OG Graph Database”

Emil introduces himself and the tongue-in-cheek “Larry’s yacht” bio, explains why RDF was never the right foundation for a database, and establishes Neo4j’s claim as the original graph database that coined the term and defined the property graph model.

Raja Iqbal: My guest today is Emil Eifrem. Emil is the CEO and co-founder of Neo4j. Welcome, Emil. It is great to have you.

Emil Eifrem: Great to be here.

Raja Iqbal: I was looking at your background and I bumped into your bio on the Neo4j website. It says: “He plans to change the world with graphs, and own Larry’s yacht by the end of the decade.” Is it Larry Page, Larry Ellison, or all the rich Larrys in the world?

Emil Eifrem: It’s Larry Ellison, of course — as the symbol of relational database dominance. I figured in the end maybe I’ll just own a rowboat, but I’m targeting the yacht. It’s my feeble attempt to be funny and not take myself too seriously in my bio. In reality, I don’t want to own a yacht, but it felt like funny symbolism — because on some level, what we want to do is usher in a new era of working with data that does not replace the relational database, but is a good complement to it. That’s the spirit behind the tongue-in-cheek bio.

Raja Iqbal: Are you on track for this KPI?

Emil Eifrem: We’ll see. We’re only halfway through the decade, so probably I’ll only own a rowboat at the end of the day, but we’ll see.

Raja Iqbal: When we talk about graph databases and knowledge graphs, Neo4j is probably the first name that comes to mind. So it looks like you’re making it.

Emil Eifrem: Yeah. We have the benefit of being kind of the OG graph database, so to speak. We coined the term way back in the day, and played a significant role in defining the property graph model and then evangelizing it. So I think it’s fair to say we’re the most popular graph database out there today. There were several other implementations — call it the RDF world. RDF is Resource Description Framework, Tim Berners-Lee’s second innovation after the web. He wanted to add a semantic layer to the syntactic web. But several people tried to turn RDF into a database format, and I was always of the opinion that it wasn’t good as a database foundation — it was ultimately a format for describing resources on the web. There were certainly other databases that took a graph-ish view of the world, but they didn’t call themselves graph databases, and they didn’t use what is today the most popular graph model: the property graph model.

Chapter 2 — 05:30 | The Property Graph Model — Sketched on a Cocktail Napkin

Emil recounts joining a small Swedish startup as CTO where half his engineering team spent their time fighting with a relational database. That frustration — trying to squeeze deeply connected data into square, static tables — led to sketching the property graph model on a cocktail napkin on a flight to Mumbai, with key contributions from friends at IIT Bombay.

Raja Iqbal: I read that you came up with this sketch of a property graph model on a flight to Mumbai in 2000. At that time, internet-scale data was just starting to happen. What were you thinking?

Emil Eifrem: Let me tell our story first, then relate it to what was going on in the rest of the industry. I joined a small startup in Sweden — didn’t even know the term “startup” at the time. I was a developer who loved to write code, and pretty quickly became the CTO. After a while, what we saw was that approximately half our 20-person engineering team spent the majority of their time fighting with a relational database.

We were building multi-tenant SaaS offerings — content management around media assets. When you do that, you have a lot of connected data. Files sit in folders, folders sit in folders — that’s a tree. But then we supported shortcuts, like symbolic links in Unix. Suddenly one file or folder could have multiple parents — that’s when a tree turns into a graph. We overlaid a very sophisticated security model on top of that. This became a really deep, complex web of connections that we tried to squeeze into square, static tables.

It worked. There’s mathematical proof that you can model any data in the relational model. But it was like pushing a rope uphill. Join tables, foreign keys, a combinatorial explosion. Today anyone would look at that and say: there’s a mismatch between the shape of your data and the abstraction you’ve chosen. But back in the early 2000s, the only type of database that existed was the relational database.

So we banged our head against the proverbial relational wall for long enough that we realized: what if we had a robust, high-quality database — but instead of a tabular representation, it had nodes connected to other nodes, with key-value pairs you can attach to both? Then we can model everything. That’s the thing we sketched on a cocktail napkin — it was literally a cocktail napkin — on a flight to Mumbai. As any marketing message, that’s a vastly simplified view. It was a broad team effort. The reason I flew to Bombay was that I had friends at IIT Bombay, which is a phenomenal school, and they played a huge role. But ultimately, we were young enough and naive enough to say, “Let’s just invent something new here. How hard can it be?” And that led to what people today call the property graph model.

Chapter 3 — 12:00 | The Industry Context — Predating Hadoop

Emil places Neo4j’s founding before Hadoop existed and before the discourse had shifted from “the relational database is the end-all be-all.” He traces the NoSQL awakening to the 2006 Amazon Dynamo paper and Google’s Bigtable paper — the lightning strike that opened the world to alternatives.

Raja Iqbal: I was talking to Amr Awadallah on this podcast, and he told us that back at Yahoo, a single query on Oracle would take days to run. Then early Hadoop proofs of concept drastically cut that time. So there really was a broader dissatisfaction with relational databases.

Emil Eifrem: And this actually predated Hadoop. Early 2000s — Google had just been founded, Yahoo was around, Hadoop didn’t exist yet. Google was starting internally to use MapReduce but hadn’t spoken publicly about it. The discourse in the industry was that the relational database is the end-all, be-all innovation of data — a mathematical axiom. There was a lot of scar tissue from the mid-90s surge of object databases, which failed and went into obscurity. So a lot of people believed the relational database would be there forever.

But inside web companies, they were running into a version of our problem, primarily around scale. This became public in 2006 when Amazon published the Dynamo paper. They said: “We want to sell books. The last thing we want is to build our own database. But sadly, all the off-the-shelf databases don’t work for us. So we invented Dynamo.” Six to nine months later, Google published the Bigtable paper: “We’re also handling some amount of scale, and we also couldn’t get there with off-the-shelf tools. So we invented Bigtable.” Those two papers were like a lightning strike. All of a sudden, a few alpha geeks started talking about: “Wait — the relational database may not be the only solution for all of data.”

Chapter 4 — 17:30 | Neo4j’s Enterprise Footprint & Two Broad Use Cases

Now at 84 of the Fortune 100, Emil breaks down the two buckets where graph databases deliver value: intelligent applications (fraud detection, customer journeys, product recommendations) and the newer surge of knowledge graphs powering enterprise AI.

Raja Iqbal: I was reading that 75 of the Fortune 100 companies use Neo4j. What are some typical use cases?

Emil Eifrem: It’s actually now up to 84 of the 100. And it’s very horizontal — every one of the 20 biggest US banks are now customers. 9 of the 10 biggest pharma companies in the world. 10 out of 10 biggest car companies. 8 of the 10 biggest retailers. Insurance companies, 8 out of 10. And so on.

I break it into two broad buckets. The first I call intelligent applications — where there’s a lot of value in not just retrieving a singular data point, but actually figuring something out in the data. For example: there’s a fraud ring here. There are lots of individual transactions that seem fine individually but are connected in a fraudulent way. Or a customer journey — tracing the path of a customer from an advertising campaign, to the website, to the app, to an offline store, to a customer service call. These break down into what we call the seven graphs of the enterprise: the graph of your employees, your transactions, your products, your customers, and so on.

The second bucket is what’s happened over the last couple of years — the surge of adoption driven by the amazing fit of knowledge graphs and AI. That really is anywhere you have your organization’s internal proprietary data and you want to marry it up with an LLM. You use a knowledge graph as a powerful, efficient way of giving the LLM access to that data.

Chapter 5 — 23:00 | Three Core Benefits of Knowledge Graphs for AI

Emil walks through the three benefits his customers cite repeatedly: (1) improved accuracy — GraphRAG vs. vector-only RAG, with the Google/PageRank analogy; (2) developer productivity — the Klarna story where porting from a vector database to Neo4j immediately surfaced bugs; and (3) explainability and auditability — why regulated industries love graphs.

Raja Iqbal: Why do you think knowledge graphs are going to be helpful in building AI systems? We read a lot about how they can minimize hallucination.

Emil Eifrem: There are 3 core benefits our customers keep telling us over and over again. The first is improved accuracy — another way of saying reducing hallucination. In the classic agentic RAG architecture, you have an agent that looks at a corpus of maybe 100,000 support articles, finds the top 10 most relevant ones, hands them to the LLM with your question, and asks: “Does this answer my question?”

It turns out humanity has solved this problem before. In the late 90s there were dozens of search engines — Lycos, Excite, Yahoo, AltaVista — and they all did some version of inverted-index text search on individual documents. Then along comes Google, which says: “We’re gonna do that, but we’re also gonna rank results based on the links on the web — using a graph algorithm called eigenvector centrality.” They called it PageRank. That’s why there’s so much research showing that GraphRAG — combining a knowledge graph with vector search — delivers much more accurate responses than vector-only RAG. The graph tells you the relationships between documents, not just their individual relevance.

The second benefit is very counterintuitive: developer productivity. One of our first AI customers, Klarna, had written an application on top of a vector database. When they ported it to Neo4j, I still remember the Slack message from their CEO Sebastian, forwarding a message from one of his engineers: “Holy crap. Just by virtue of porting it from the vector database to Neo4j, we’ve found a bunch of bugs already.” Why? Because vector space is ultimately opaque. If you have two objects and ask how similar they are, you get back 0.4 or 0.6 — a cosine/Euclidean space calculation — but you don’t know why. If you marry vector space with a knowledge graph, you know that an apple and an orange are related because they’re fruits. Graph space is explicit and visible. That leads to people finding bugs faster and building applications faster.

The third benefit is the flip side of that explicitness: explainability and auditability. Why did you choose exactly these top 10 support articles? With a knowledge graph, you can trace the reasoning — this engineer’s answers were chosen because many people approved them, so they’re highly ranked. That gives explainability. Banks, regulators, insurance companies, government — they love that. So: higher accuracy, improved developer productivity, and explainability and auditability. Those are the three core benefits of using a knowledge graph in AI.

Chapter 6 — 34:00 | Explainability Tools, Hybrid Search & When to Use Graphs

Emil describes Neo4j’s built-in visual explainability tools, the out-of-the-box hybrid search combining semantic + keyword + graph, and a nuanced take on when vector-only is fine versus when investing in a knowledge graph is essential.

Raja Iqbal: Do you have explainability tools built into Neo4j for developers building agentic AI systems that need to satisfy regulatory requirements?

Emil Eifrem: Yes, we have a plethora of tools. Some are command-line tools, like the equivalent of EXPLAIN in Oracle or Postgres — showing query paths. But I think the more powerful ones are visual. You can actually see the query path, see how it traverses through the graph, and through that understand why it chose a particular document to hand off to the LLM.

Raja Iqbal: I see something called hybrid search now — keywords, semantic, and knowledge graph. Do you have something like Hybrid Search 2.0 available out of the box?

Emil Eifrem: Yes, we do that, and it’s available out of the box from Neo4j today. Our vector search is very good, but it’s still early days in terms of scalability for extremely large workloads. For 500 million embeddings or a billion embeddings, we actually recommend Neo4j for the knowledge graph plus a dedicated vector database. But for a million, 10 million, or 50 million embeddings, just use our built-in vector search, which is Lucene-based — and we’ve had Lucene for keyword search for 15 years. And Lucene now supports semantic as well. So yes, you have the best of all worlds: semantic, graph, and keyword, all at the same time.

Raja Iqbal: Should every developer building an agentic AI system always use a knowledge graph? Or is it case-by-case?

Emil Eifrem: I don’t think there’s any technology that is a silver bullet you should apply across the field every time. What I will say is there’s a broader trend becoming well-recognized: in order to build truly production-grade agentic AI systems — not toys, not proofs of concept, but production-grade enterprise systems — you better invest upfront in your data. Creating a knowledge graph so that downstream you get higher accuracy, better recall, and it’s easier to build your application. For low-end use cases, a vector-only approach is fine to get started. But for real production systems, invest in that ingestion pipeline.

Chapter 7 — 40:00 | The CIO Pitch — Why Graphs Are Going Mainstream

Emil makes the case to the 16 remaining Fortune 100 holdouts by pointing to Microsoft Fabric IQ, ServiceNow’s AI Experience, and Salesforce’s VP of Knowledge Graphs hire — all independently converging on the same conclusion: a graph-based knowledge layer is the foundation for enterprise-grade agentic AI.

Raja Iqbal: You’re at 84 of the Fortune 100. How would you help a CIO from the remaining 16 companies who wants to stay in the relational or NoSQL world?

Emil Eifrem: It has to start with the business problem — not the data model. The problems tend to come in those two broad buckets: intelligent applications, of which there are hundreds of use cases, and doing AI properly. To a CIO specifically, I’d say: most successful AI applications today follow exactly the same pattern. They sit on top of several disparate data sources, they read them into some intermediary format — which is not your core data platform, not Snowflake or Databricks or BigQuery, because most agentic applications require low-latency, real-time retrieval. And it turns out the property graph model is a really powerful way of expressing that intermediary information.

Last week was Microsoft Ignite. Microsoft launched Fabric IQ, which is their graph-based semantic intelligence layer — they call it that, we’d call it a knowledge layer, but it’s the same thing. A graph-based layer that sits on top of your multiple data sources with a unified, ontology-driven representation. ServiceNow, a couple of months ago, launched their big AI bet called AI Experience. In the blog post announcing it, Amit Savari, the Chief Product Officer, wrote about the top three differentiators. Number one was Knowledge Graphs. Salesforce is now hiring a VP of Knowledge Graphs reporting to the Chief Data Officer. All these companies — who don’t have a horse in the graph race like I do — have independently concluded that the best way to write enterprise-grade, robust agentic applications is to use a graph-shaped knowledge layer. That’s why you should care about graphs.

Chapter 8 — 46:00 | Enterprise Adoption Patterns — Start With the Business Problem

Emil describes two adoption patterns: the large enterprise-wide knowledge graph versus the use-case-first approach he recommends. He draws a direct parallel to why Hadoop failed — building the data layer first before having a business problem — and why the same anti-pattern must be avoided in AI.

Raja Iqbal: Do you foresee organizations having an organizational-level knowledge graph of all relationships, with a steward managing it?

Emil Eifrem: We see two broad patterns, which roughly break down by company size. One is exactly what you described: an enterprise knowledge graph that replicates parts of the data sitting in their core data platform. The industry has spent five years moving data into modern data platforms — the data lakes and lake house patterns. So organizations replicate part of that data into a graph form, then hang intelligent use cases or AI-agentic applications on top of that.

But the much more common one — and the one I always recommend — is to start with a business problem solved by an AI application. Let that application drag the data in. It needs to sit on top of my sales database, my customer success database, and a weather database? Then put those three systems into a knowledge graph. Incrementally build it out over time as you add more applications.

One of the reasons Hadoop failed — one of them, there are plenty more — is that the entire notion was: I’m first going to take all my data, dump it into Hadoop, and then later get business value from it. That’s an anti-pattern. Let business value pull the data in, rather than building a massive graph and hoping the use cases follow.

Chapter 9 — 51:00 | Building Knowledge Graphs from Unstructured Data

On the hard problem of constructing the knowledge graph in the first place — from the structured, supervised past to the LLM-assisted present. Emil explains why a one-shot LLM conversion produces a 60% valid graph, but adding domain hints gets you to 90%+. He also introduces GQL, the first ISO-standardized database language since SQL.

Raja Iqbal: The process of creating a knowledge graph is still more supervised — you need a domain expert. Do you see LLMs making this a semi-automated process?

Emil Eifrem: Let me be intellectually honest here. One of the three benefits I mentioned was developer productivity — and it’s true, once you have the knowledge graph. But you’re exactly right to hone in on: how do you get it in the first place?

For structured data, there’s actually a fairly simple process. We’ve been working on GQL — the Graph Query Language — which is the first time the SQL committee has approved a new database language in the history of software. For 40 years, SQL was the only standardized language for speaking with databases. Now we have GQL, a sibling to SQL governed by the same ISO committee, and it’s 95%+ Cypher, which was invented by Neo4j. As part of that work, one notion we defined is “tables as labels” — a person table maps to nodes with a person label, and every column becomes a property key. There’s a straightforward process for going from a relational schema to a property graph.

But the big thing that’s changed is operating on unstructured data — text in PDFs, for example. It turns out LLMs are a great first step. But just throwing a random PDF at an LLM with no additional information, asking for a one-shot knowledge graph — it will create the graph, and initially it’ll look good. It’ll be a little like dumping your data into a vector database without caring about chunking: it’ll kind of work for a POC, but won’t work in production. What we’re seeing is that if you provide just a little bit of domain hints — this is a healthcare project with the following key principles, this is an oil platform maintenance document — all of a sudden instead of a 60% valid knowledge graph, you move to the 90s. That’s a big part of what we’re working with our customers to do in their ingestion pipelines.

Raja Iqbal: So data quality and domain expertise are still important — not going away anytime soon.

Emil Eifrem: 100%.

Chapter 10 — 57:00 | Founder Lessons — The Mismatch Between Strategy and Resourcing

Emil shares his biggest founder mistake: having the right developer-led GTM strategy — win the hearts and minds of developers — but staffing it with too many salespeople and too few engineers. Winning developers requires a product and DX investment, not a sales-heavy motion.

Raja Iqbal: You’ve built Neo4j from scratch to a company valued at around $2 billion. What is one founder challenge you wish someone had warned you about?

Emil Eifrem: I think we ended up with the right go-to-market strategy: win the hearts and minds of developers. That is why we’re open source, why we go to all these conferences and meetups, why we have a free forever tier of our cloud service. That strategy was — and is — very powerful. What I did wrong in the early days was the mismatch between strategy and resourcing.

After our Series A in 2011, we were about 50 people. Maybe 12 to 15 were engineers. We built an entire enterprise sales go-to-market organization around a still-very-embryonic engineering team and early product. That was partly fantastic — that’s when we started the march towards 84 of the Fortune 100, and you need enterprise sales for that. PLG won’t get you there for real mission-critical deal sizes.

But here’s the mistake: if your go-to-market motion starts with winning the hearts and minds of developers, how do you actually win them? By creating a low-friction product experience. Super easy to install, easy to get started. That’s a product game — it’s DX. And very strong enterprise salespeople won’t help you with that. So there was a mismatch between the strategy, which was developer-led, and the resourcing, which was heavily sales-heavy. We course-corrected, but it took several years for me to understand that.

Chapter 11 — 63:00 | Near-Death Experience — $2,000 in the Bank, 6 Days to Payroll

The investor term sheet pulled the day before signing. Emil had $2,000 in the bank account and 6 days until payroll. His team pivoted to consulting, Emil factored invoices at a loss to generate cash, and they made payroll — barely. Nine months later, the NoSQL wave arrived and Neo4j raised a real round.

Raja Iqbal: Near-death experiences are very common among entrepreneurs — no money for next payroll, that kind of thing. Anything you can share publicly?

Emil Eifrem: We had an early near-death experience before we’d raised any money. We were two founders not taking salaries, and four other people. We were kind of funding the company through consulting and a very small angel round — maybe $150K to $200K. We got a term sheet around Christmas from one of the best investors in Europe, signed it, and started due diligence. At the start we had $30,000 in the bank. The company was basically nothing, but still there were lawyers, accounting DD, an IP review, freedom to operate analysis — all of it.

By March, when we were about to sign, we had spent through all our cash. We had $2,000 in the bank account. And that’s when they called me up — literally the day before we were going to sign — and said the deal is off. We’re walking from the term sheet. And I remember looking at the bank account: $2,000, and 6 days to payroll.

I remember thinking to myself: if we survive, this is going to be a great story one day. What we ended up doing was: I called all my friends in the industry, we sent people out to do consulting — not even on top of Neo4j, just anything, as software developers. I convinced customers to let me invoice them ahead of time. I took those invoices and sold them to a factoring firm. If you have an invoice for $100, they give you $80 right away and keep $20. It’s obviously not a great deal, but you get the money immediately. We did that in a few days to get cash. We made payroll the following week, and then started funding the company that way.

It should have killed the company, but the team was so committed. I remember them saying, “No, this is too good. We can’t let this die because of this.” They went out and did boring consulting — not what they’d joined Neo4j to do — just so we could get cash flow. After a while we brought them back, started building the product, and about nine months later the NoSQL hype happened. Through that momentum we raised a real round, and then we were off to the races.

Raja Iqbal: Pretty much every startup has a very similar story — early people who believed in the idea, staying with you when you’re running out of money. You just have to survive.

Emil Eifrem: You have to have that “whatever it takes” mentality. If not, you’re just not gonna survive.

Chapter 12 — 72:00 | Building Culture at Scale

From osmosis at 5 people to explicit values at 1,000. Emil explains why “American company with a Swedish soul” resonated internally, why Dunbar’s number (~150) marks the inflection point where tactics must shift, and why Neo4j’s first core value — “We value relationships” — predates the graph database, not the other way around.

Raja Iqbal: Do you actively invest in culture at Neo4j — mindset, cultural values?

Emil Eifrem: Always absolutely crucial, but the tactics and techniques vary significantly by stage. In the early days it happens through hiring — who do you hire and who do you not — and through the behavior you model. When you’re 5, 10, 20 people, it just happens through osmosis. Everyone has surface area with everyone else — in graph terms, it’s a fully connected graph. Every node has a relationship to all the other nodes.

At some point that breaks down. Generally around 30 to 50 people, is what I’ve seen. That’s when you need to become more explicit: start writing things down, have mantras. One mantra we had was “building an American company with a Swedish soul” — people tend to love it, even if no one knows exactly what it means, which is why I have a little lecture about what it means. That’s a technique for tying cultural traits to something concrete when people no longer see you every day. At a thousand people you need to layer on even more things, but culture is always important.

Raja Iqbal: Has it ever happened that you hired someone who was inconsistent with that culture?

Emil Eifrem: Oh, many times. Where the person has the core skill set for the job but the way they interact, the way they treat their colleagues or customers or partners, is just not consistent with how we want to show up. Then there’s only one way — you have to take care of that. Otherwise it falls apart.

We have 6 core values. The first one — first among equals — is just three words: “We value relationships.” People think we have that value because we’re graph people. But it’s actually the other way around. We built the graph database because we are people who value relationships. We value the relationships between our employees, between us and our investors, between us and our customers, between us and our community. We also value relationships in data. And people who value relationships in data — if they’re building a database — will end up building a graph database.

Chapter 13 — 79:00 | What Emil Is Most Excited About

The snowball effect of connected graphs: when independently built use cases start talking to each other, 1+1=3 moments emerge. Emil describes a supply chain use case connecting with a personalization use case, creating an entirely new capability. He sees this compounding effect — combined with the knowledge graph AI momentum — as the foundation for building a truly generational company.

Raja Iqbal: What are you most excited about at Neo4j, as the leader in knowledge graphs and graph databases?

Emil Eifrem: It’s actually what we discussed when I was making the CIO pitch. My full original scope was the scope of a single application: how can I make things better for developers and data scientists solving a particular problem? What’s happened over the last several years is that many of our big customers — who have tens of applications in production — start seeing data network effects and use case network effects.

They might have started with a supply chain visibility application. A team independently looked at it: what’s the best database backend so I can have visibility if the Suez Canal gets blocked for a week? They concluded graphs were the best fit. Completely independently, another team doing personalization and recommendations said: to express my product hierarchy, graphs are the best representation. These happened independently.

But over the last few years, those teams started talking: “What if we connect these two graphs?” Now, all of a sudden, I will only recommend the products that I can actually ship through my supply chain — a really relevant and important thing. That’s 1 plus 1 equals 3. And we start seeing a snowball effect: adding the N+1 use case for graphs is easier than adding the Nth one. The N+2 is even easier. That compounding effect — married up with the momentum around knowledge graphs for AI — I think is a really fertile ground to build a truly generational company, which is ultimately what we want to do at Neo4j.

Raja Iqbal: Emil, it was a pleasure having you. Thank you so much.

Emil Eifrem: Really enjoyed the conversation. Thanks.