Host: Okay, we're in a remote studio with Emil Eifrem, uh CEO of Neo4j. Welcome.

Emil Eifrem: Great to be here.

Host: Uh Emil, you I've been waiting for this for a while. Uh you were one of our top speakers at the first FOSS Fair, and then then we did the full graph rag track with the rest of your team last year. You're back this year at FOSS in Graph Rag. How do you introduce Neo4j today?

Emil Eifrem: It depends on the audience, right? Like I think we're most well known as as a database, right? As a graph database uh specifically, right? But it's a broader platform than just a database these days, and I tend to start with the you know, we transform data into knowledge, right? So it's platform to do that, and then of course leads down the path of what do you mean with knowledge? Cuz that's kind of a ill-defined term, and I talk about how actually it takes about extracting the signal out of the noise and express that in a way that is a knowledge-dense way, and the graph is is one of them. And it at the core of it of course is the is the database, but then you know, we there's many other things in part of the platform as well now these days. Uh you you guys have been around for a bit. You're used by basically everyone, including Transport for London. Uh it should be fun.

Host: It's a very graph thing. Like you'll see when you get there. The tube network is a graph.

Emil Eifrem: Oh oh yeah, of course. Yeah. Well, you know, depending how graph pills you are, everything's a graph, right?

Host: This is true. And I've been down that that rabbit hole as well myself. Yeah, when I was I so when I learned to code uh 10 years ago, I did a did a coding boot camp, and there was a workshop at some conference I attended that introduced me to Cypher and Neo4j. And I think that that's how a lot of people maybe first come across a Neo4j. We wanted to talk about you know, what what's happened since, and what what is graph intelligence just generally, right? Like what what is the um I guess the the the rest of the system that you've been building.

Emil Eifrem: Yeah, so let's first talk about kind of the why behind it, right? And so you know, if you come in at it from like an AI engineer's perspective, right? You mentioned the word graph rag before, and that tends to be a popular way of describing retrieval that in the R path you include a knowledge graph, right? You know? And there's plenty of reasons to do that, right? The ones that I hear most loudly from from users is higher accuracy because you have a very rich representation of your data. And then actually surprisingly to a lot of people, but improved developer productivity. And there's a built-in assumption there, which is you have the graph, and we can talk about that, but when you have the graph, and if you compare that to vector space, it's very opaque vector space. If you search and find the top K documents, you don't know why. It's like 0.7 in some cosine Euclidean space kind of thing, right? Compared to in the graph, it's explicit, and you can even visually inspect it and look at it. And I have an apple and an orange, and they're related because of their fruitness, right? Whereas it like an apple and I don't know, a tennis ball might be 0.7 in Euclidean space, right? Because they're both round, or is because they're green, you don't know, right? So that's kind of the second thing. And then the third reason that we hear very loudly is around explainability. People love the fact that they can actually audit why I chose these top K documents compared to just again opaque vector space.

Host: Yeah. Um I don't hear anything about query speed, which I guess it's it's it's part of it, but always think about graphs in terms of like, well, okay, the reason you want to do this is because you can you can walk a graph, you can traverse a graph, and that's probably better than doing a bunch of queries and joints. Is that a old school way of thinking about it, or is it is that [clears throat] actually just another way of saying the same thing that you just said?

Emil Eifrem: Yeah, I think it's probably built into the accuracy thing, right? Because frequently you can kind of cover a lot of ground. Like you can can traverse and touch a lot of documents or nodes by virtue of doing it really fast, right? I guess it's an interesting observation. I guess we hear less of it, and even I hear less of

Host: said it's speed. Yeah.

Emil Eifrem: Yeah, exactly, right? Like in in kind of thinking about it from an AI engineer perspective, right? AI-ish type use cases, I guess we're also used to kind of the LL eating up so much latency anyway that it's maybe kind of rarely pops up for that reason, but it's like a fundamental reason why we can get the higher accuracy, I think. So I think that's probably why it relates.

Host: Yeah, yeah. I mean, if you if you have speed, you can just throw more time at it to get more accuracy.

Emil Eifrem: Exactly.

Host: Yeah, okay, cool. And then I think the the other question that comes up a lot is what happened to vector databases in your mind? You know, as a as a neutral sort of database CEO, how come that has been a less I guess how should I call it? Persistent or independent category? Yeah, durable maybe.

Host: Durable maybe. Everyone has vector indexes now, but like I would I think it's fair to say vector databases are as a standalone category are over.

Emil Eifrem: Yeah, I don't know. Maybe that's overstating it. I've been So several years ago I was very kind of on the record saying that I don't believe this is a durable database category, right? At least not as a database category. Maybe it feels much more like search, right? That is kind of my my statement a couple of of years ago. I guess I've been surprised that there's still I think some kind of long tail thing going on where we still see a lot of experimentation where people try with vector databases early on, right? And then at the like a super high end, then like some of the vector databases are still better than the vector search features of other databases. But like you call me a neutral party. I'm not neutral here like cuz we also have vector search as part of Neo4j, and it's not as good Yeah, so what you're saying is that the vector databases Exactly, right? But like every quarter, every year kind of the line moves up, right? And so there's less and less oxygen for them, you know, I obviously watched with with pleasure, you know, your your conversation with Simon a couple of weeks ago as we're recording this from from Turbo Puffer, and he described it as a search platform, I think, or search Yeah. search tool or something like this, right? I think that's generally where people are going right now who used to be vector vector databases. And I think just the oxygen, you know, between everyone else adding it as a feature, like the good enough ends up being good enough for most situations.

Host: Yeah, got it. Um I I think I think that's true, too. And I think something that everyone should disclose or disclaim is under what size and what complexity of data or cardinality or whatever, right? Are you like truly excelling, right? Where where your solution is leaps and bounds above everyone else's because you were architected for like in in a in a specific way. At small size, who cares? Just throw it in whatever. But like at scale, it really starts to [clears throat] matter.

Emil Eifrem: Yeah, I agree. And like the way that it fits in for us is So you have call it your rag corpus, right? And you have some kind of pipeline to get that in the state where you can query it and get it kind of out and ultimately to the LLM, right? And then we populate the graph based on that ingestion pipeline and embeddings in our, you know, vector search index, right? But and then at query time we typically tend to use it to find the starting points in in the graph, right? And then we traverse from there. So in the classic kind of customer support type use case, Swyx, you know, just got a new laptop, and the permissions don't work, and so you go to on onto the Apple, you know, support site, and you type in something, then you know, from that natural language, right? There's typically a vector search, typically combined with some kind of BM25 type search as well, right? And that ends up finding some documents, right? Call it 100 documents or something like that. And then you traverse from there to get the full context. And then you end up saying, well, okay, it's not just whether these documents were found by the vector search, but also turns out that they were written by this author who's highly ranked, maybe through a page rank, or maybe just very simple like stars or or some kind of signal like that. And and you get to the top K, you know, something like this, right? And so it's not like graph or vector search, it's like vector search in combination with traversing the graph. That's the typical yeah, kind of pattern that we see.

Host: Yeah, and and like the engineering's actually like really hard here because there's so it's just trade-off trade-off trade-off. Like you can do anything if you have unlimited budget, but you don't, and so

Emil Eifrem: I agree. I do I do think there's a general trend, though. Like broadly, setting aside Neo4j, like trying to extract more signal out of the ingestion pipeline to make the kind of down down stream querying. Yeah, well, you could call it pre-process, but just extract more signal. Like in the when you add things into your like vector search or whatever it might be, right? And the vector databases you tend to call that kind of metadata, right? But it's really structured data, right? And we're part of that broader trend, and you could say that graph is a like a very rich type of structured data. And I think that generally tends to be the right way to think about it. Like the more work you can do kind of upstream, the easier it becomes at at runtime or at query time. Since you mentioned the Simon episode, uh that was a really fun one. He's a very charismatic guy. I'm curious if you have any like technical like, you know, any pushbacks, anything sound a weird to you. I can ask you about like the sort of blob S3-centric view of the world that he has, which a lot of database CEOs, including Neon, uh you know, betting heavily on. Presumably you don't have a strong opinion there, but just I I just want to let you respond whatever you want.

Emil Eifrem: No, I think broadly it's it was just really strong articulation. Now, this was like years ago that I listened to it because it was like 3 weeks ago or something like this.

Host: Yeah, yeah, yeah. It's it feels like forever since I talked to him. of put it out. Perfectly remember, yeah.

Emil Eifrem: No, I can't perfectly remember it, but generally it was like a very strong articulation which sounded like very just pragmatic and savvy trade-off and and choices, right? And like of course as a database geek I enjoyed the conversation around compare and swap, right? And even as you and I were DMing around it's like raft versus two-phase commit and stuff like that. I just kind of love all all that because I just remember for for us, right? I used to do compare and swap like on a CPU level way back in the days, right? And then it was a big unlock for us when it because we're on the JVM when it got exposed through the JVM. It allowed us to do kind of you know you know, basically lock-free concurrency. So, optimistic concurrency or optimistic locking in the database, right? And it's interesting to see like how he 15 years later can do the same thing, but you have just based on based on S3. Seems like a really good set of trade-offs for like the use cases that that he's targeting which is of course very like very different from what what we're targeting. Yeah, cool. Let's talk about some of the use cases, right? Like I think that one of the surprising things last year was I think the Pfizer talk which is kind of cool and and I just you know, you have lost you have so many customers here.

Host: Just who are the sort of AI forward customers that you that people might be surprised are using graph databases or using Neo4j for something

Emil Eifrem: Yeah. So, lots of things to talk about there. Like that's one of the biggest things that have changed certainly since the first talk that I gave which is now 2 years ago. It was uh June of 2024 I think or maybe maybe May.

Host: you on the landing Yeah, the landing page uh yeah, down here.

Emil Eifrem: Yeah, yeah, yeah, yeah. So, and a huge one of this of course is that people now have put it into production. It was such early days back back back in those those those times. You You mentioned Pfizer. We see a lot of adoption inside of life sciences, right? And so this is broadly kind of scientific intelligence that researchers at these big life science companies use on a daily basis. This is access to not just internal peer research, but patents, like external published, you know, academic papers, you know, that those kind of things, right? Novo Nordisk is one of the like public case studies we have here over 60 million documents, you know, billions of nodes and and relationships. Use lots of kind of savvy NER and NER, so that's named entity recognition and entity resolution which is such an under-discussed area right now in in AI engineering by the way which I don't understand what why it is, but but that's like key for them to make sense of all the all that data, right? And if you think about like a life science company, right? Like extremely PhD heavy, right? And this is like 100% on the critical path for them in order to like improve their product productivity and and and output. So, that that's an example.

Emil Eifrem: We have lots and lots of recent uptake just in 2026 in banking. An example here um is like so 30% of our AI conversations these days like in 2026 so far has been with like global banks. Which is pretty pretty amazing. Yeah. One example which I don't know if we have on our website is like a massive mortgage lender company. Um and um what they're doing is they have a ton of let's call it bankers. They call them agents which makes it very confusing, but human beings that they hire.

Host: Yeah, yeah, exactly human agents, right?

Emil Eifrem: And and they are kind of mid-20s, low-20s kind of demographic age-wise, right? And like their normal tenure is super low. It's like less than a year. And so a huge part of that game is to ramp them quickly. And as they do outreach to their customers, how can you get kind of the bottom quartile and move that up up up the stack, right? And so they built this huge system that looked at all prior like kind of the the best case path and what actually converted in the past and helped them pull that all together. And they actually talked about it publicly and didn't mention Neo4j, but that it increased conversion rates by by 20%. And so that all happened uh you know, last year.

Host: money is that if you convert it to money?

Emil Eifrem: Yeah, I don't I don't know. Way more than they pay us.

Host: [laughter and gasps]

Emil Eifrem: Um and but the really cool thing is and now what they're starting to do this year is they're starting to now kind of automate that, right? So, prior to that it was just kind of serving up the draft to the banker so that they can send the send the text message or the email or something like this. And now of course they're kind of removing the human in the loop and they just send it out in an automated fashion, right? And that's very cool to see how quickly people are starting to put these things in production in customer-facing ways. When we reviewed our kind of customer portfolio last summer, almost no one had customer-facing things in production, but that has shifted very very dramatically in the last call it 3 months.

Host: When you say 3 months, is it So, there's there's this thesis that I've been investigating, right? Something happened in December 2025 where uh a lot of curves infected and all that. Are you seeing that, too?

Emil Eifrem: We are seeing that.

Host: I cannot believe that it's related to Opus 4.5. That that seems like a like a separate separate thing. But GPT as well, but uh no no, every chart in both databases So, obviously I see a lot of these sort of industry-wide stats and numbers. I mean, I'm an angel investor in like 30 companies um and you know, obviously through through cognition and and AI AI I see a bunch of stuff. Every compute chart is like this. Every database chart is like this. And obviously every coding agent chart is like this.

Host: Only like Yeah, something's going on.

Emil Eifrem: Something is going on, right? And to us like I'm not sure if it's like purely the model quality, but yeah, we're seeing it, too. And and a big shift is what I just mentioned, right? Which is you know, it used to be just draft me the messages. Now it is kind of send me the messages, right? And so that complete automation in a customer-facing way that's now got into some kind of tipping point around trust, right? Where they where they're doing that. Another example of this is if So, that's kind of high-level kind of what the companies are doing, but if you go down to the micro level and like in single developer, a single application which was kind of the scope of my graph rag talk 2 years ago, right? Like that was kind of the um the the boundary.

Emil Eifrem: And if you think about that, right? Like how do people actually write agentic kind of graph applications right now? Okay, so so the graph is a tool, kind of vector database might be a tool, you know, that kind of thing, right? And then you have some kind of English coming in, some natural language coming in maybe, right? And then it used to be that what the recommendation was take the most the kind of the hot spot of the type of questions you might get. Again, if it's a like the customer support portal is just this most obvious example, right? We can choose plenty others, right? So, if it's Swix, then okay, Swix goes to Apple and he asks some questions. Take kind of the hot spot of those questions. Express that as a function or tool, right? In Cypher. And then use text generic text to Cypher Cypher as the default kind of backstop if that doesn't work. And then what customers ended up doing was like, okay, I'm going to do this. And then they sat down and they looked at the log of everything that kind of had a fall back to to text to Cypher. The stuff that didn't work, they would extract into a separate function or tool call. So, that is kind of the the general way that people were doing things, right? And you saw similar with other databases and and agentic applications about a year ago. And then in the last 3 to 6 months, what has changed is that it used to be lead with the specialized functions, fall back to the generic. And now that has flipped. So, now it's like, okay, just start with generic text to Cypher, right? And then when that fails, you extract the edge cases into the specialized functions, right?

Emil Eifrem: I think it's just across the stack there's a number of things that have happened like that that I think caused it to to flip call it you know, 3 to 6 months ago.

Host: Because it I can single shot most things now as well.

Emil Eifrem: Exactly. Yeah. You know, this this triggers a common talk track that I have as well around LM coding. You know how um one of the reasons I did the workshop with Cypher. And then I didn't I didn't really use it. Other than that, mostly because it's a DSL and I'm like, why do I want to learn a DSL? But now DSLs, you know, a good reason is they are optimized for their use case and they are so concise. They can do so many things correctly, but then the the downside is you have to learn them. Now you don't have to learn them. You can just

Host: [laughter]

Emil Eifrem: And and yours happens to be a DSL that has a ton of training data. So, it's like you you like made the cut-off where you've been around long enough. You survived through ups and downs and now, you know, people actually can freely use you and obviously optimize if they if they need to, but other than other than that, you know, you can mostly one shot these things which is super nice.

Emil Eifrem: I I agree. A couple of more thoughts. One is we had the benefit of becoming a complete actual ISO blessed standard, right? So, it started out as open Cypher actually back in 2015 which after so many back and forths and all kinds of, you know, standards wars and whatever, right? Or not even wars, but standards bureaucracy ended up becoming GQL, right? Which is the first sibling language to to SQL. And I actually think that helps as a signal for the kind of LLM training data, right? So that's one thing. Now, having said that, internally, so we have a bunch of in kind of internal text to Cypher things that we use across the product portfolio, like a old school kind of co-pilot type thing. If you go into Neo4j into our browser, where you can type your Cypher queries, right? Then of course you can use a co-pilot to translate that and you can run agents on top of those and then so we we need that as a primitive in our in our platform. We actually still fine-tune that that one. And so whenever we we default to Gemini and we still do like some fine-tuning and even some post-processing. When you say fine-tuning, are you you're saying fine-tuning a custom model to produce, you know, your your text to to Cypher or you're fine-tuning the playground in the output?

Emil Eifrem: No, no, no. We're fine-tuning an actual model.

Host: Okay. It wasn't clear because you can't really I don't think you can fine-tune a Gemini model, right? You can't fine-tune an analytic model.

Emil Eifrem: this is where like we probably use some of the one of the derived ones internally. I actually don't know no no no no which one, but we then even have a post-processing step where we do some like real just imperative code like regex type stuff sometimes to like switch some arrows around. You know how like in Cypher you can describe it the relationships in different directions and and stuff like that, right? And so it actually is a little bit messier than you know, it's not that the models out of the box are good enough for all situations right now. I certainly hope like sort of some bitter pill kind of thing, right? that over time it's going to be good for even 99% of all situations, but it's not quite there yet. I mean I I I think, you know, that's where that's where like experts will come in having a good ecosystem will come in and you know, that that will still be the domain of human experts at least for now.

Host: And I want to come back to like use cases and cool things that people are doing, right? You do think that there's a just a ton of work obviously in like traditional recommendation systems and fraud detection and all that. I did start a LLM Rexis track last year where it looks like LLMs are eating Rexis and I think I think there's there's interesting usage of of graph databases there as well. Apparently all of YouTube, you know, the YouTube Rexis is LLM-based and they Is it really? They they obviously, yeah. They they they tokenize every video every video and put it in a codebook and then they train a LLM on it to and then feed in your your context just like a regular LLM and ask it to predict the tokens of the next videos you should watch.

Emil Eifrem: It's crazy. That that is pretty cool actually. I had no idea. The Rexis people I know, Eugene who's Eugenia who's you know, a big figure in the Rexis world and and all that is very bullish about this. Apparently it's that's also powering the new X algorithm that's also powering Pinterest. It's like all the rage in their world and it's kind of cool. You know, it definitely feels uncomfortable. I definitely have some weird recommendations in my algorithm that like normal systems would never recommend, but whatever, right? Like it's a new world and everyone's trying to get signal. And I'm sure if if anyone AB tests their stuff, it's YouTube. So so yeah, basically like I guess what are the new workloads or use cases that you're seeing that you want to encourage people to check out?

Emil Eifrem: Yeah, so there's plenty of experimentation going on which I love, right? Like again, you know, for the last 10 years we've been very focused on the global 2000, right? I mentioned several examples there, life sciences, financial services and I can keep going on and on and on about that, but we've also a little bit gone back to our roots in the last kind of call it year and two or two with like we have a startup program right now and our in our cloud service, which is called Aura, you know, has a form factor and a price point that works for startups, right? And so that's like really really phenomenal. Of course a very popular one here is agentic memory.

Emil Eifrem: And so there there's a lot of people who want to do kind of memory on graphs. People don't talk about this, but like actually the initial MCP release includes like a tiny little in-memory graph database. It's a hard thing to 200 lines of code.

Host: Yeah, yeah, I thought it was 300 lines of Python. Yeah, yeah, something like that, right?

Emil Eifrem: And it's so it's a toy, it's tiny, right? And it's an in-memory memory implementation, right? But it's graph shape, right? Which is which is cool, right? Of course I love that. And so there's just a lot of people who who kind of naturally do that. And then of course there's all this discussion around context graphs that happened over the last, you know, kind of three three months and so we see plenty of people doing things like that, which is also I think a great use case for graphs.

Host: Yeah, okay. So memory is a whole topic. I don't know if we'll have the the time to cover that. My my quick two cents on it is like in theory of graph databases are fantastic for memory. In practice it might be overkill. Most people's memory doesn't go that far and I don't think like we have figured out the struct the true structure of memory that that I really really works over a super long period of time.

Host: And probably it's like yeah, probably fits in a single file.

Emil Eifrem: [laughter]

Host: Like like I don't put I don't put out that many tokens, you know. But context graphs, yes, right? Like so, you know, this is where like what I always say is I don't care how long your LLM context is. We we took, you know, three years to go from 100k context to 1 million context in every frontier model, but we're not going to a billion, you're not going to a trillion with context graphs uh context lines. What is your take on the context graph discussion? I mean it's really blown up. We had a we had a short pod with the authors about it.

Host: I I think they're kind of leaving it open to interpretation. I think a lot of people will build context graph systems and we'll figure out what it is, but what are your early takes?

Emil Eifrem: Yeah. So my view on it is that in my head it completed the quadrant of the types of data sources that are required to reach what I've been talking about as kind of escape velocity for agents in production.

Emil Eifrem: And so what I mean by that is I think it's exactly four types of data sources and I would love to hear your take on it, right? If you can identify a fifth or a sixth one, but I think there's exactly four data sources that are required and I don't think it's as easy as you have to have all four of them, but like the more the merrier on some level.

Emil Eifrem: And the first data source for agents, I think is operational data stores, right? And so this is the like the system of records and I think of them as systems of record for the present, right? So this is like, okay, how many customers do I have right now? Or what's the value of this particular customer right now? You know, that kind of thing, right? And and I think in the conversation we flip between calling the application on top of the like operational database, we call that the system of records. So Salesforce is the system of record. That's one way we talk about it. The other way is like the actual database is the system of record, right? But no matter what, I think that's kind of the operational databases in the first this is the kind of the first quadrant. The second quadrant to me is the cloud data warehouses, right? So this to me is people say that they're not systems of record. I actually think they are. They're system of record of the past, right? So if operational is is system of record of the present, then this is the system of record of the past, right? And so how much revenue did we get from the LatAm region in Q3? You know, that kind of thing, right?

Emil Eifrem: And then like the third quadrant to me is memory.

Host: Yeah, that's OLAP, right? So OLTP and OLAP for like

Host: Yeah, yeah, yeah. You you said DSL before, which is probably a data term too, domain-specific language, right? Like but OLTP and OLAP, right?

Emil Eifrem: Yeah, programming term, yeah.

Host: Yeah, yeah, yeah. Um and then the third one is agentic memory, right? And so or maybe like agentic state, like system of record for agentic state, maybe short-term, long-term state, something like that.

Emil Eifrem: And then the fourth one is the context graph, right? And so what is it then? So this is the why behind we like the particular values in one quadrant one and two, right? And okay, so, you know, the classic example is the, you know, I I sold into this customer at this price point. That's a 20% discount off of list price and our policies say that we're only allowed to discount by 10%, right? Okay, so the why is, well, I wanted to break into this vertical or into this geo and I got an approval from my sales VP that was on the phone, over Slack, by email. It's not recorded anywhere. And those decision traces is what they call it, right? End up constituting a graph that they call the context graph. And if generally we're in the kind of space right now trying to shift decision-making from, yeah, kind of human brains into agentic brains, right? It used to be from wetware to software. I don't even know what to call kind of the LLMs now, right? Into latent space, maybe, right? Um then you know, then having access to that institutional knowledge of how things actually happened, the actual decisions in big organizations, feels really valuable.

Emil Eifrem: And so those are the four quadrants and then I can talk about kind of more context graph specific stuff, but first of all, do you agree with the four? Do you see a fifth or a sixth?

Host: I feel like the the the three out of the four is obvious. Sorry, I strongly agree with. And then the the fourth one is agentic memory actually where I'm like that's a little weaker, that's a little less established, that's a little smaller. It's like the the one, two and four are very strong, very large categories where I know exactly how to architect it and everything. The third one is like the I don't know, something something memory. And I feel like there could be more when I would think about two by two, right? OLAP or OLTP is great. That's like a dimension of how wide your query, how what volume of transactions you're doing. The other dimension should be ideally ideally axis should be orthogonal and I don't necessarily know what that axis is. Uh and so it doesn't exactly fit a normal two by two which usually means that maybe there's a third dimension that's kind of being sort of mixed into the into the into the equation here. Because agentic memory let's call it is it probably mostly personal maybe some organizational whereas context graphs is fully organizational. Um

Host: Uh and yeah so so that's my that's my initial reactions but I'm happy to just only talk about context graphs here unless unless you have more sort of

Emil Eifrem: No but I I it was really interesting to hear that. I think like agentic memory is some kind of I want to understand what happened in the past for that individual. I think is going to be an important source for retrieval for many use cases but maybe not all and

Host: Yeah. Yeah so so so maybe okay maybe one one sort of I'll put this in my own words is agentic memory is is sort of the stuff that you've done with the agent and then the context graph is the stuff you've done with everyone else because I think yeah actually there's a lot of work by all the agent companies on querying their own past trajectories and memorizing knowledge and self-improvement from from there that really has nothing to do with the context graph. It is just the agent should get better as I use it right or it's like yeah of course.

Emil Eifrem: right. Yeah yeah. Now on context graph specifically right? So I think it makes it a lot of sense to somehow encode that institutional knowledge right in some digital form right? And it's back to the PhD level intern that you get that wake up every day and they don't know the past you know that kind of thing right? And so so that that makes sense. I guess the trick is like how do you actually instrument your organization to get there?

Emil Eifrem: I think we can all see this kind of future state where okay I have my agents in production like my example from before like I have some kind of an agentic process that reaches out to my customer and offer them mortgage discount or or something like that right? And if they do that they should be instrumented and record all of their decision-making throughout that use that as a source for improving themselves going forward and you can kind of sense the compounding effect or the flywheel right? Okay.

Emil Eifrem: That's great once we're there but we're not there now we don't have it that in any digital form most typically it's that sales rep calling someone up from a car asking for a discount getting a yes then selling the deal and at best it's recorded in Salesforce right? And that's kind of how it happens today right? Like so how then do we bootstrap the context graph? So that has been almost all the conversations that I've had with big enterprise customers. With startups the bootstrapping of the context graph is by virtue of getting adoption of their product right? And so that's then not the problem then the the problem there is like how do you even get adoption of my product right? But inside the kind of the enterprise context no pun intended that ends up being like how do you even start this instrumentation so I get enough decision trails that I can bootstrap the process. That ends up being the the interesting discussion.

Host: So how valuable are startups to you? Like you you deal with like 80 of the Fortune 100 you you you target to the 2000s startups you know free tier whatever like they're not that they're not worth that much. Yeah.

Emil Eifrem: I mean maybe I'll take the the kind of founder CEO kind of point of view on this right? Like like a decade ago right we looked at our revenue and it was like a third a third a third and like a billion and above was a third and then there's like some kind of a mid-market kind of thing right? And then a third was startups right? And we just saw all the underlying metrics of the of the billion and above segment was just so much better.

Emil Eifrem: And then we looked at all database companies at scale also known as Oracle but I've been DB2 as well and stuff like that and 80 plus percent of their revenue was from the global 2000. So clearly that is where database companies monetize right? And so we kind of added all these things together and we said okay 100% what we need to do is lean in on the enterprise and that was the right business decision. My CEO hat love it was super successful that's why I can sit here today all that good stuff right?

Emil Eifrem: My founder hat was a little bit sad right? Because startup people are my people. Right? And and they represent the future and all of that kind of stuff right? And so that we have this new generation of AI native startups happening right? We're like now this is really important for us to be built into those architectures right? And not necessarily maybe from generating tons and tons of ARR I will always make more money from Bank of America as a kind of generic example not saying anything specific about Bank of America but except we do have 20 of the 20 biggest banks in North America are customers so you can derive from that what you want right? So we have all of them right?

Emil Eifrem: But I'm always going to make more money from the enterprise segment but I think it's really important to just be part of the zeitgeist. And from that perspective like getting the next generation of startups built on Neo4j is is really crucial and important.

Host: I presumably startups are easier to onboard because they have less context than the the the larger companies. So I guess what have you prescribed so far in terms of like you know whichever segment you want uh honestly both are interesting to me. What are the best practices so far like you know how do they even get started? It depends on which altitude you operate at right? Like if it's a if it's a single startup it's not just there's one product but the product is the company. So that's then everything right? And that's very different if you look in inside of the enterprise context right? Because then we engage in in two levels right? One is the scope of a single application a single project right? And the other one is more enterprise-wide. This let me talk about the the the last one for a moment because this is a big change that has happened since certainly since the two years ago the the the graph rack talk. A clear pattern that we're seeing happening is we we tend to call it the knowledge layer but we bump into a lot of enterprises and the problem is okay every single data source is going to have some kind of an MCP endpoint here right? Okay I want to give my agents access to that so like what can I do? Either I give my agents access to all of the MCP endpoints and let it figure it out right?

Host: The problem that they run into is that yes that works but like some of the data is going to be conflicting. Right?

Emil Eifrem: And so we just talked about we have a cloud service right? Even for me like when I try to figure out like how many customers do I have on my cloud service? Like I go to the actual cloud platform and I ask and we have let's call it 3000 customers right? That means how many are active have an account with a running database and then I go to like the finance system and I have 2800 customers because those are the ones that were like with the credit card and the you know okay so like so how do you make sense of that right? And I think we're learning that an LLM is going to give you an answer with without doubt right? You just have no idea if it's right or wrong. Right? And it's very hard to find that out right? And so what we're talking to a lot of big enterprises about now right? Is you want to own that layer or they want to own that layer right? Where they consolidate the metadata around where data sits right? Inside of their enterprise and that gives you the consistency and the trust and the explainability

Emil Eifrem: And so what is that metadata that they want to own then? It's basically the data asset landscape right? So what are the schemas that sit in your relational database right? What are the buckets in your S3 and so on and so forth right? Express that in a graph form marry it up with a business-facing ontology.

Emil Eifrem: What is a customer? Right? Like how does a customer relate to a supplier and what what are the concepts that I have?

Host: That's so hard. You talk to five different people you get six answers.

Emil Eifrem: That's exactly right and this has been the key problem that has has been holding this back in the past. What is happening now of course is I need to solve this to make my agent successful for this particular use case. So that forces them to kind of converge on something that is good enough to work for those agents. Right?

Emil Eifrem: And then the third piece is kind of the mapping between between people talk about semantic layers people talk about context layers I like the term knowledge layer they all mean kind of the similar but distinct things but this is a very very popular use case that we have right now. If you you were on our website if you Google kind of leading media company or something like this um and Neo4j you're you're going to see this and it has like a nice little architecture in green that that you can scroll down and if you can screen share that you'll you'll see it.

Emil Eifrem: And so you have like the disparate data silos at the at the bottom and they they call it the semantic layer right? And then they have their agents running on top of that. There's a couple of flavors where you do kind of zero copy so what the what the knowledge layer will give you is the map of where I should actually go and query or sometimes we inline the data like partial data into the knowledge layer so you can just do the queries right in there. Yeah. What what what is zero copy again? I want to say Salesforce has coined or at least popularized this term. This is where it's like okay instead of replicating your data in every single like between Snowflake and this and that right? Instead you have like a virtualization type layer where it points to the original data source. So you're pointing data wrapper.

Emil Eifrem: Yeah, exactly Exactly. All right? You can tell I'm like very Postgres.

Host: Yeah, yeah, yeah. That's right.

Emil Eifrem: And so, on the query path, you end up going to this layer, and then you figure out where the data sits, and sometimes it's materialized into that layer, and so you can just query that directly. And so, this is this is a very popular use case kind of enterprise-wide. But, I think your original question was like Okay. What are the best practices for for getting started? We talked about context graphs. Uh there's a uh a really neat Python wrapper called UVX, like whatever create context graph, right? That gives you a context graph out of the box for I think 22 different industries. Uh it was just published like a few a few days ago. And it stands up a full full Neo4j with a with a front end, and you can

Host: It is modeled and you're going to love this with It's modeled after What was it called? Create React app? Of course.

Emil Eifrem: Right? Of course. And so, you can have like this interactive It'll help you with your own data, but you can also choose you know, out of um existing domains. And then

Host: Existing domains. Wow.

Emil Eifrem: Integrate with eight or nine different agent platforms. Only one to one, and it's the one that's not here.

Host: No, which one? Social media.

Emil Eifrem: Interesting. Yeah. Yeah, we can add that.

Host: Yeah, yeah, yeah. Social social graph and social media. Basically, I have a view that every SaaS basically eventually becomes has a has a social graph inside of the SaaS with the off system. You know what I mean? You want people with teams. You want people who can message each other. You want to send notifications. You want to feed elements of social media find their way into every single one of these domains. It's like not even a a a vertical domain. It's just a a a feature set that I always you know, um I actually looked into doing this as a as a business before, and I I found that other people have done it, and and it didn't work as a business. But, basically, you know, the drop-in social media uh social I guess network into my user base as a feature. Into your end user base or into your employee base?

Host: No, uh end user.

Emil Eifrem: Yeah, yeah, yeah. Yeah.

Host: So, you know what I mean? Like like because because every one of my users they work in a team. They follow. They have They want a feed. They want notifications. They want DMs. They want even blocking whatever, right? They want a homepage. It's all social features that none of these people really would would build themselves, but probably they want something. Maybe maybe here. I don't know. Um but yeah, anyway, this is really cool. Cloud Co-Work William I I I know he's a he's done a workshop at one of it AI's before.

Emil Eifrem: Yeah, he's he's phenomenal. And um so, what what it does is it just helps you get started, right? And it creates some either synthetic data. It also integrates with like a bunch of SaaS tools like uh

Host: I saw you were excited about the What is it called? The Google Workspace CLI or something like this, right? So, Everyone is excited about that. I mean, you see the number of likes on that one. I know. It is shocking, right?

Host: how Okay, [clears throat] so I got so excited about Cloud Co-Work because I could use it to navigate the GCP dashboard. I was like I don't want to do It's so bad.

Emil Eifrem: [laughter]

Host: But, so so it can kind of get you real data, or it can generate synthetic data for you. And

Emil Eifrem: Yeah. It It It uses We have an like an agent memory kind of toolkit, which has either short-term memory. So, that's kind of conversational state type stuff. It has long-term memory, so that those are all the entities and all the concepts in the domain. And it also has the decision traces, so the context graphs. So, can put it all together with a little graph visualization kind of UI UI and all that kind of stuff, right? So, that's a great way to get started. It's It's a great idea. I can't believe no one else has done it. I can't believe this is only 6 days old. Yeah, you should you should uh promote this a lot. And and and you can imagine it's the same story. Like he he hacked it up one Sunday afternoon like this. So, I guess 5 days ago, 6 days ago, Sunday afternoon ahead of a context graph meetup that we that we did, and people love it.

Host: Yeah. Yeah, yeah. Okay. Okay. I- If If I have one feedback looking at this, it it almost does too much. Almost It's like

Emil Eifrem: Yeah, yeah.

Host: Um W- Where does it end, and where does my app begin, right? There's There's a lot here. And so, I I'm already feeling a little bit overwhelmed with this read me. So, some focus is is is valuable. You know, it's it's one of those things where like open code You know, the open code CEO Dax was like, "Look, in an age where any feature you can just vibe code it within days, actually restraint and focus and like, you know, fit for purpose is is the thing." Because yeah, you can add it, but like does it actually add anything, or is it just more stuff that just fills up my context window? And I'm just like, "Okay, what what is the the job that you do for me?" And just just do it really well, you know? So, I I do think like this is one of those things that

Emil Eifrem: kind of Steve Jobs, I'm the editor of the product kind of thing. And of course, the most important part of the editor is saying no. Like removing things.

Emil Eifrem: You know, that that's a that's a quick tour. Uh obviously, there's a lot more going on in your world that we'll we'll learn about. Yeah, any Any parting thoughts outside of your your official hat? You're you're your hacker at heart. What else are you excited by? What do you get you super excited?

Emil Eifrem: Well, I mean, it's we have It's like this era that we live in right now is simultaneously the most exciting time and the most shocking time. We haven't talked at all about kind of SaaS-pocalypse and all of that kind of stuff, but you know, with the other hat as CEO, I have to pay attention to to to things like that. And of course, we were kind of front and center in like starting to see the shift of the buy versus build, right? Because, you know, Cloudera was one of the first examples of you know, shutting down

Host: it, and then also rolled it back. That that is the public view, right? They certainly I'm not going to speak for for Cloudera, but I I think there is overstatement on both sides of that of that probably, but but clearly there's a shift in that buy versus build, right? But, then for me

Emil Eifrem: personally

Host: For for me, I pay 200,000 a year for conference management software that I hate like, you know, maybe to pay I pay 2,000 to to make one that I like.

Emil Eifrem: That's shocking that you of all people haven't fixed that.

Host: I'm busy running, you know, like printing badges and like freaking figuring out my magician costs and everything, you know? Like I just This is not like top of my list. And I have a team that isn't as agent-native as me. So, I cannot just like unilaterally as like as like a CEO like just decide, "Oh, like my whole company's going to do this now." And expect that every single one of my employees will know what to do because no, they need to be trained. And actually, sometimes the the familiar, buggy, slow, whatever system with all its flaws actually still is better. And and it's it's back to like what what is the value of these things? And a big part of it is understanding processes and being prescriptive about those processes, right? And this takes us some while to iterate there, and you could do it if you focused on it. But, in the meantime, you're going to pay for the two money, right? So, so so I get it.

Emil Eifrem: But, but so that's kind of on the terrifying side or like the shocking side or something like this, right? And then on the other side is just man, the ability to build. And remember like I I'm kind of post-technical, right? Like so, I couldn't write the the the code and swap stuff is like that's the kind of stuff that I know, right? But, I haven't been a modern real pro programmer for 10 years, right? And now again, I can like software is malleable again, which is just so phenomenally exciting.

Host: Yeah, I but I think one one failure mode of the post-technical, you know, like manager, which you are, which I am, is that you think you you Oh, AI can do it. And then you like, you know, you vibe code something, you throw it to your your employees, and then you expect that they just pick it up. No, I saw like I you know, I do I do want to encourage the leaders among us to also just be respectful of uh the fact that not everything is vibe coded, and your employees still have to clean up your mess sometimes if you do this. Of the real craft. I completely agree. Especially like as a database company, like man, there's there's some some real craft in that. Yeah, but you guys test very well. You know what I mean? Like the database testing is is top-notch. Most software is not like this.

Host: You know? So, yeah, actually I know because you can test so much, then you can vibe code more because it's so so testable. You know what I mean? So, anyway.

Host: Anyway, thank you, Emma. This is really fun chat. Um and I'm excited to catch up in person. Uh I think you're coming to to San Francisco. Um so, I'll see you there. All right, my friend. Talk soon. All right. All right.

Emil Eifrem: [music]