Elastic N.V. (ESTC) Earnings Call Transcript & Summary

How is everybody doing. It's just Day 1 of the conference, right? I mean, it's a 4-day conference, and you're going to hear a lot about tech, software, AI. By the way, software is not dead. We're going to talk about that. Ash has been at the helm as CEO of Elastic for a few years now. I had the pleasure of meeting him some 3 years ago. And we have in addition to the executive team, Navam, who many of you will know from HashiCorp, very experienced executive. So Ash, great to have you back. I think it's the 4th Communacopia and Technology Conference we're doing together. Really excited to have you here. And I know you've been through a few conferences and people ask us. For those that are not familiar with the Elastic, can you please tell us your story. I'm not going to ask you that question. What I'm going to ask you is the same question I've been asking in '22, '23, '24, what is your vision for the company? What does success look like in 4 to 5 years?

Okay. So the most important thing for me as I think about Elastic is what we are great at is search. Like that's our core bread and butter. When it comes to unstructured information, unstructured data of any sort, the messier the data, the better we are at handling it and helping you find just the right relevant information within that data. And we have grown both as unstructured data itself has grown, but also as the use cases for unstructured data have grown. And the most exciting one of all of them, obviously, is AI. And the role that we play is search for AI, specifically as people do context engineering or providing relevant context, accurate context to a large language model, so it can actually do its job, whether it's doing it for some sort of agentic workflow or some conversational app that you might be building. And LLM itself does not know anything about your private proprietary information and that's where Elastic comes in. So we are one of the most widely used vector databases, but we do so much more than that, and it's all about providing that right context. So the vision for me is that Elastic becomes the platform, the data platform for data retrieval and context engineering as people build AI apps and that we are baked in into this new AI stack that's emerging across enterprises, mid-market, government agencies worldwide.

Got it. I was going to title the session, Kash asks Ash. So that should be at the front end of whoever is going so Kash asks Ash or Kash versus Ash or whatever you want to call it. Naman, we will find a word of way to weave in. It's coming, trust me. That's great. So as we dig into AI, there's bits and pieces of the stack that you talked about vector databases, vector search, vector embeddings, search, concept of the core Elastic search. Can you -- I mean I know you're an engineer. Can you put it all together, what is that ultimate AI application stack look like? And why do we need these different elements that do these things that embedding search, database. And where do you play in each of these layers of the stack the way you're at?

Sure. So take any large language model. So first of all, we are agnostic to what large language model you use, we integrate with just about every single one of them. But if you are building any kind of agent, the 2 things that you need, the first thing that you need is an LLM because that's the one that knows how to do reasoning on information, it knows how to do inference. So it's able to predict the next token, so it's able to create an actual set of sentences that are reasoned and thought through and come up with a full detailed answer or it can take actions, what have you. The other thing that it needs is some context of your information because otherwise all large language models are only capable of answering based on what they have been trained on and what they're trained on is publicly available information. So when you're dealing with an LLM in the context of your business, it has no understanding about your inventory, your thoughts, your products, your customer tickets, like what have you, your policies, your internal knowledge basis. It has no context if any of that. The only way to provide it with that information in real time because, by the way, all of your data is also constantly changing. So you need to connect the data to the language model. And that connection needs to be done in real time. It needs to be done with the minimum number of documents to pass to that language model because the more information you pass it, the higher the chance that the language model is going to hallucinate, so you want to keep that set down.

Thought that it should lead to less hallucination, the more information it has, right?

Not really because the more information you provided in a narrow context, it can often go, okay, I have various choices without recognizing that you know internally because of various relationships that you might know about the customer, the segments are there and et cetera, that -- although these 5 documents are all related to the general topic, only these 3 documents are related to that customer. So if you don't provide that bit of information, the language model might assume that all the documents you're giving it are equally valuable. And so this is the point of training and RAG. Like the RAG, retrieval augmented generation -- the RAG of 3 years ago is no longer the same RAG that we see today. Retrieval augmented generation is becoming very, very sophisticated now. People take into account things like known relationships. So people will often model it in the form of a graph. People take into account what you know about preferences and biases. People take into account what you might have to do in terms of filtering the set based on other parameters like preferences like geolocation, like other choices that customers might have given upwards to. So there is this whole process of learning to rank or reranking that has become very, very powerful and well understood. And this is what I mean by context engineering. Context engineering is more than just a vector database. It is about first organizing and chunking the data that you are working on correctly. Then it's about using the right kind of embedding models to turn it into vectors. Then it's the vector search process itself with all the additional facets in -- like search facets that you can apply on top of it. Then there is hybrid search, which might be, okay, I've got an answer using vector search, but I also want to look at what text search gives me, especially if the data is textured. And then re-ranking all of that based on this learn to rank technique that I talked about. Eventually what comes out after all of that is ideally the most accurate bits of information that you pass to their language model and then the language model is very much going to get the right answer, right? So that process is involved. And if you give the wrong answer really, really fast, it's not very helpful. So accuracy of that context is what customers care about most. And that's really the evolution that we have seen in the market where customers are getting more and more sophisticated about this. And all of this plays to our strengths. This evolving stack also has additional things to it. Like you're going to see -- you're already seeing people talk about LLM absorbability. You're already seeing people talk about FinOps when it comes to understanding the number of tokens that are sent back and forth to these large language models because that also runs up cost. You're seeing people talk about LLM security. So the whole AI stack is going to continue to evolve. But our role is in that -- in the center of that retrieval and context engineering bucket. Like that's where we intend to have our greatest focus and then eventually we'll expand from there. But if we capture that core ground, I think the opportunity for Elastic is massive.

On that note, I know in your most recent quarter -- we'll bring Navam into the discussion shortly. You talked about a few use cases. What is the best use case, the most impactful use case where this whole stack, embeddings coupled with vector search, vector databases and the context engineering is having the maximum effect.

There are so many examples that I think are super fascinating. We've got an agency -- a government agency that is using us for solving human trafficking use cases. Where they marry phone call information, so audio information with CCTV information that they look across using these kinds of vector search techniques to quickly figure out where a person of interest could have gone. It's like amazing kinds of use cases that are like helping address real human problems. All the way to AI music companies that use us under the covers and for -- as a vector database and...

Detecting illegal use of proprietary music....

Well, I'm not going to go into the proprietary versus not. But there would be uses of vector database under the covers, as you are searching for music fragments and trying to create your own composition, Elastic is the technology under the covers. We are used by some DevSecOps platforms as the vector database under the cover for their code generation agents. So all the way from these kinds of AI native capabilities to more traditional use cases, we have banks that are using -- that have used us and have made us the -- have sort of put us into their core agent development framework and have built agents on top of us already for servicing their high net worth clients as conversational chat application that is used by their wealth management teams all the way to automotive companies that have built agents for dealing with their partner networks. So it's very, very broad. Customer support, code generation, like some of these AI native use cases like I talked about. ISVs that have embedded us under the covers as they are building AI applications that they're taking to market. What's exciting is all of this is still just scratching the surface, in my opinion, because most organizations today have a handful of these AI applications that they've rolled out. And the aspirations that are very clear are to build hundreds of these for all kinds of automation across the industry. I think as each customer adds more and more of these AI applications, our consumption just naturally grows. And so our focus today is to get embedded into as many of these use cases as possible, which is why we give the count on 2,200 customers in the last quarter that are using just an Elastic Cloud. These are not trials. This is not -- we have free trials and all of that, but these are actual customers and actual use cases.

Got it. I want to come back to you later on about the -- how you participate in the economics of the AI stack. But Navam, if I recall right, you're an engineer, right? A former engineer, I mean...

Former, recovering. I've long been a finance person that I've forgot...

No, I understand. But so I'm an engineer. I used to be an engineer, but I'm a finance guy too. The reason I asked is, was that the reason you hired Navam that [indiscernible] got to be an engineer first and foremost, and then the finance stuff, the MBA and all that...

I mean, look, it's -- I'll tell you like what -- I know. And I'm not going to answer this seriously as a question. But one of the things that to me was really, really important is the ability to understand what it means to operate in an open source model, right? And Navam bought a ton of that expertise with his time at HashiCorp. And so the engineering piece might have been somewhere on the list, but it was definitely not one of the top reasons.

That's great. so Navam, welcome to our first -- because of a podcast, I think better than a podcast, we're asking some real questions of real people. But how has it been so far for you at Elastic? How has been your experience?

It's been great. I mean, as Ash mentioned, I've been in an open source company before. So the way I would describe Elastic is there's a lot of things that rhyme with my previous experience at HashiCorp, and there are a lot of things that are way better than my previous experience in HashiCorp. And the scale that we've achieved the amount of GTM success we've seen over the past 4 quarters and the testament we have with sales-led subscription revenues that's having such a durable value over 4 quarters. And more importantly, a ton of product innovation we're delivering into our platform and also the tailwinds of AI. So a lot of things to get very excited about in this particular opportunity at Elastic and it's been a really good. I've lost count because I can't play the new guy card anymore, but I think it's been about 2 quarters. So it's been a great...

And this quarter that you reported was your first full quarter?

This was my first full quarter of actual results.

Reacceleration, margin expansion, I mean the guys they're crushing it. Yes. So how were you able to do this? And what is your prognostication of -- if you uncovered so much in 4 months.

I take very little credit for this last quarter. I think there's been a ton of work that the team has been doing over the past more than a year on the GTM side, on the R&D side, that I get the benefit of just coming in, in the last quarter and saying, "Hey, guys, here's how we did in this last quarter and it was a great quarter."

He's being very humble, I mean, yes. Talk to us more about the price increase thing. People debate this, oh, yes, all the growth was price increase. Most of it was not much. What is the best -- personally, I like it when a software company increases prices and some look at it and say, well, that means the units are down, blah, blah, blah. Like, you want to invest in a company that has pricing power and is able to show that pricing power by raising prices common share with the value that the company delivers. Where are people wrong about. If you got the sense, I know you've been at a couple of other conferences before, are people being a little wrongheaded about assessing the quality of your price increase and the durability of your growth?

I think there's a few fundamental misunderstanding. But the misunderstanding is the misunderstanding of how consumption works and how price increases is working in the context of consumption, right? So first and foremost, I would argue that most of our peers who are here at your conference today, particularly the innovative ones have most likely revisited prices from time to time, we're no different, right? Some of them reflect their innovation through new SKUs that they introduce and they charge for those SKUs. The way we do it is we drive a lot of innovation onto a single platform. And that platform increases in value over time. And from time to time, we look at that and we reflect some of that value through a price search. We've done that in the past. Last year, we did it on the self-managed side. A couple of years before that, we did it on cloud and self-managed. This last May, we did it on cloud and self-managed. This is not likely the last time we're going to revisit prices given the amount of things we're doing with the platform to actually give value -- sorry, give value to our customers. The underlying platform is getting more and more valuable. So the thing we need to remember is how do we judge success in this context. We judge it in 2 ways. How are customers committing to us, on a quarter-by-quarter basis and they have a choice and how are our customers increasing or decreasing consumption with us. And that's a day by day they have a choice on how they do that, right? And when you think about the puts and takes of consumption, there are multiple things that are happening under the covers. First is the data volumes increase and that increases the consumption the customer has. Price is one factor, which increases the consumption a customer has. And on the other side, there are things that decrease the consumption. Our customers optimize quite frequently as they optimize the increased data, they optimize the increased data and that kind of tends on an upward and downward trajectory. The second is we introduce things into our platform that is meant to make things more efficient to our customers. About a quarter before, if I'm not mistaken, a quarter or 2 before the price increase, we did it -- we introduced Logsdb, which was meant to increase the efficiency of how our customers store their data and therefore consume less, that's by design. Searchable snapshots, which happened a couple of years ago, meant to decrease the amount of consumption a customer has to make things more efficient to our customers. So they're -- in the consumption model, there are multiple puts and takes, of which pricing is just one, and pricing is elastic so customers can optimize and decrease their consumption or they can see the value in the platform and grow. So what matters is net of all these puts and takes, how is consumption going with our end customers. And Q1 was a testament where consumption was strong, commitments were strong and more importantly, consumption is strong, which gives us confidence that what we are delivering to our end customers were ultimately absorbed and they decided to increase their consumption.

Got it. So in the context of being able to successfully put through a price increase and the quality of the Q1 beat, people see the rest of fiscal '26 guidance as being very conservative. How do you, as the CFO, balance the process of setting prudent expectations versus signaling confidence, which is always a tricky thing to do.

Yes. I think on the 1 hand, we had an excellent quarter. It was a very strong quarter, both as a -- on a consumption and a commitment basis. It was balanced without any outliers or onetime things that caused us to see this increase. The way you should think about the price increase, like I said, is it's a durable lift to the floor, just like you adopt a new SKU and then you grow from there. And that's how we should think about how the price increase changes over the years. But to answer your question, we gave a prudent guide in Q1. We detailed the assumptions behind the prudent guide and -- sorry, in Q4 and in Q1, we delivered against that guide. And I think the meta point is that the results speak for themselves as to the confidence, right? The numbers will speak to the confidence. And we will continue to give prudent guides, but one thing to remember is we also give a lot of narrative behind those guidance -- behind the guidance numbers to talk about the underlying strength of the business. So the Q1 details we provided was in our opinion, a very strong quarter, which gives us confidence in the full year, which made us raise the full year guide. And we intend to execute every quarter and revisit the year as appropriate.

Yes. I mean just to be very blunt about it, the 2 things I look at in every quarter are how are commitments trending, because commitments are a predictor of future revenue, as you know. And then second, what is the trend line on consumption. They were both very, very strong in Q1, and the underlying business is very strong. So the prudence that Navam bakes in into the guide, I think that's 1 thing. But to me, like as I think about the business, there's a lot of excitement.

We're better positioned today relative to a quarter ago, 2 quarters ago, 3 quarters ago after you went through your GTM changes...

Yes. When you think about like when we had the issue over a year ago, 5 quarters ago, we talked about where we had a stumble, right? And we've always been very transparent about stuff like that.

More things looking up now...

It's been great. I mean, the last 4 quarters have been very solid sales execution. The changes that...

So you've tweaked and you've got the right model...

We've got the right model. The 2 things that Mark, our CRO, really wanted to get right. One was the focus on enterprise and mid-market where each rep had fewer accounts because the model that we have prior to him making that change had been there since pre-IPO. And it was right for when we were a much smaller company. And we had gotten to the point where like we needed to do something different to allow us to go deeper and broader in accounts. And the second thing that we wanted to get right was greenfield territories where we could have a dedicated hunting motion because that is also important because we have a massive open source presence out there. So customers or organizations that are using the free version of Elastic search but have never paid us are prospects, our great prospects. So how do we make sure that we have a dedicated greenfield motion, hunting motion? So both of those we established with that change that we made. And as those settled, like we are starting to see the benefits. We are starting to see larger million-dollar customer accounts have grown faster in the last year than prior years. So we're seeing the right kind of outcomes. So it just makes me feel very good about the future.

That's great. My go-to-market is actually the opposite. I started with 12 companies and growing 37 companies. If the IPO markets continue to be healthy, that number will likely grow, but everything has a limit. I want to talk to you, and Navam, I will come back to you. How are you deploying AI internally within the company as a CFO with an engineering background, aren't you like jumping all over this and seeing how you can, whether it's operating efficiencies within finance or sales? How are you deploying this stuff and getting advantage out of it internally and then I'll come back to you externally.

Yes. I think in the broader business, there's a lot of AI deployments, particularly in customer success in the marketing organizations. In those organizations, we even have a internal agent that we talk to and get intelligence from. On the...

What do you call it?

I think it's called Elastic GPT. From that we're very...

For Sales, it's got Elastic GPT.

We're very creative. I think finance is in very -- in the, I would say in the behind from the rest of the company in our adoption for AI, and there are several reasons for it. It has to do with the maturity of the audit side and the acceptance of AI in audit. So naturally, I think the first places where we'd be using the AI and ML within the FP&A side. And accounting will be a little bit behind the FP&A side.

How do you foresee using AI and something like accounting? And how does that...

I think the first thing that needs to change is that the audit firms themselves will have to accept AI as a form of something auditable. And right now the problem is that the audit firms are not quite there yet and accepting that. But once that acceptance comes, there's a ton of things that we can do, both in preparation of memos or reconciliations that could be done with AI that just make our accountants way more efficient than what they are today.

On the support side, as an example, our support agent is very heavily used. Like the number of -- the case deflection load is somewhere in the 40% range where that percentage of tickets never get to any human being, they just get deflected. And that's a huge advantage.

How long have you been doing in customer support.

Over a year, well over a year, like 1.5 years...

Then probably it's going to go higher, I think.

Sorry?

It's going to go higher. It has to go higher.

Yes. I mean it's like we keep pushing the envelope on that, right? And like the way I think about it is, as we grow, if we can help make the broader teams more and more efficient, it just means more that we can drop to the bottom line... I mean we had a huge GitHub shop. As anybody who knows Elastic and Elastic Search, you know our public repos are all in GitHub. And so we had a very large GitHub shop and we use their copilot but we also use multiple different vibe coding tools.

So what's your view on vibe coding versus cursor versus what you get with GitHub or the Codex based technology.

Well, we use multiple of those because we found different advantages for different ones. So we use 2 distinct vibe coding tools in addition to GitHub copilot. And what we have found is that the places where we are seeing the greatest advantages are in test development and in UI development. But anything beyond that -- even though you would argue that our repository is all in the open. So arguably, the language models have been trained on our entire source code. But it's still -- like we don't know...

Vibe coding or regular AI produced code.

When you look at AI produced code, right, it's not where we would want to use it for like core modules. It's still -- where we're seeing massive value is, in the past we used to go into customer accounts where they would say, we love your platform, super scalable, it's like amazing. But I need a what's called a searchandizing UI. So I don't know if anybody is -- there's merchandising, right? So when you're talking about merchandising, like marketers like to change preferences. So when you do a search, like this thing will pop up before that thing, you want to pin certain results. So that kind of a UI is called a searchandizing UI. And historically, we've always prefer to have a platform, and that's known as...

It's equal to as cool as Kash versus Ash.

You're better at naming. But like this idea for searchandizing UI has existed in the market for a long time. We didn't build these out of the box. And this used to be a reason why somebody would say, "Oh, I prefer if only this your UI was nice like that company there that only specializes in that. And we will basically say, look, we can help you with that, But like that's not where we are putting our product energy. What we have disclosed is when it comes to building those kinds of UIs, these vibe coding tools are fantastic. And so we are able to very quickly churn out the appropriate searchandizing UIs and make it bespoke customer by customer. And then it's like, "Oh, yes, do you want searchandizing UI, let me create it for you. So that issue has gone away. Another area where we found a lot of value is conversion from language scripts in competitive products that we might be displacing to Elastic scripts, right? So you have a scripting language, and we have a scripting language. You can just use these tools, and they'll do the conversion in minutes, and this used to be like months of work. Now it can get done within a week with testing unit -- acceptance testing and everything. Huge savings. So in migrations, in these kinds of areas, we've seen a lot of benefits.

Got it. Anybody wants to jump in with a question? Please raise your hand. I know it is the afternoon effect. It's like pushing 3'o clock, we all need a cup of coffee before we can rejuvenate ourselves. But I have another 1 for you, Ash. What have we learned from the early deposits about a couple of thousand folks that use RAG in your installed base, and I keep hearing maybe it's buyers talk in the media that the context window is bigger for these latest models whether its GPT 5, whatnot. And people are decrying RAG is dead. I'm sure it's not. But how do you think about broader context windows versus the value-added RAG, which is essential for you to add value to your customers.

Yes. I think the part that people miss on this context windows, fundamentally, making context windows massive does not really help because your language model is running somewhere else, you allow it to receive 1 billion documents in a context window. Do you know how much time it takes to move a terabyte of data like physically to move a terabyte of data, like you'd be waiting for minutes for anything, just to shift that data out. So context window increases does not really come into any relevant context for building business applications. The context window improvements add value is if I'm having a long-running session for ChatGPT. Now I can maintain history with somebody's state. I have a conversation. I can remember the conversation that you had with ChatGPT going back a year because it just stored in that context window, and it keeps building it up. So there are use cases where context window increases are incredibly valuable. They are almost entirely orthogon and irrelevant to the conversation about RAG.

Very clear. Very clear. It reminds me that just the way you explained that 1 terabyte of information, anybody here remember in-memory databases and how it was a thing. And there are some people here. You will just not admit that you're old, but [indiscernible] in memory databases are going to wipe out because they had the context windows. It run transactions in memory, but then we had reawakening.

We realize that data is actually way more than can fit into memory. And I don't think this is the thing, right? So I think the fact is that RAG or retrieval augmented generation, the way we thought about RAG 2 years ago was pretty naive. Now when you look at RAG, there's way more in it than what we used to think about 2 years ago. Having said that, RAG is never going away. Retrieval in real-time is always going to be critical because your data is constantly changing. And if you want to ground LLM in the right information, you have to do it in real time. So you can't afford to ship terabytes of data to an LLM. You have to do it contextually, you're to find the right thing and accuracy is going to matter more than feeds and speeds. And so that's -- when we talk to customers, who are now bidding these modern apps, hey, look, if it's a ChatGPT style application and it gives you the wrong answer, you're fine. If it's an agent that you are depending on to book tickets for you, you want to make sure it's booking a ticket on an airline and a flight that actually exists, right? If it makes hallucinations and gets that wrong, you're hosted.

You transferred online...

It's the problem of these language models are amazing, they're magical, but they act like human beings. If they don't have the right answer, they make it up. So engineers don't do that, but everybody else...

Actually the middle of 19 seconds, we've talked a lot about search. Give us a state of the assessment in APM, observability, security, like, 20 second each.

Our focus is to really play -- continue to play in those areas where unstructured data is the most important for the problem. So when it comes to observability, we lead with log analytics and then we expand from that to APM, infrastructure monitoring, et cetera. Same with security. We lead with SIM because it's all unstructured, log data and then we'll expand from there. Our AI functionality cash is helping us massively differentiate in these areas. So you look at our attack discovery functionality. You look at the AI SoC engine that we recently announced. All of these features are all about how do we use the native AI stack to help you automate your SoC process, to help you automate your SRE process. And that's how we intend to win in those spaces. And it just -- it feels like a very consistent way. And that's why I say we are a platform, not a portfolio, right? And that platform approach gives us massive leverage that we feel will allow us to continue to both grow the top line but also grow profitability for many years to come.

Got it. On that note, I wish you a successful journey in the years ahead. And thank you once again for your support. Navam, so good to see you part of the team here. Let's give a round of applause for Ash and Navam.

Thank you.