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

Good afternoon, everyone. Blair Abernethy here, software analyst with Rosenblatt. Thrilled to have Matt Riley with us here again this year. Matt is General Manager of Enterprise Search Solutions at Elastic. And so welcome, Matt.

Thanks for having me, Blair.

Maybe if we just want to set a little context for the audience that may not have followed Elastic recently, if you just give us a bit of an overview of the business and the market's problems that you guys solve or address for customers, that would be really helpful.

Sure. Yes. So again, thanks for having me. Elastic is the company behind Elasticsearch, which is a distributed search engine built for real-time data search. It's probably one of the most downloaded open source products in the world at this point, been downloaded over 4 billion times, used very widely across industries and different types of customer segments from small companies to very, very large enterprises. We originally started in kind of a pure search use case, so something like doing search over the internal data at your company or adding search to a website, an e-commerce store, for example. But then we've also built businesses in the observability and security businesses as well, both of which also heavily utilized the search capabilities of Elasticsearch. But observability is all about kind of monitoring your technical infrastructure and then security is about securing that. So all of it, again, built on the same platform, but those are sort of the 3 primary pillars of the business and the product offerings that we have.

And it's literally millions of downloads of the search product, right?

Yes, over 4 billion at this point. So many, many people all across the world.

Hundreds of thousands of enterprises get to try it out, use it on a limited basis, I guess, compared to your full stock subscription level.

That's correct, yes. The free and open source version has a lot of the functionality of the core search engine. So we have a lot of businesses who use that, but then we also have a commercial tier, several commercial tiers, which offer additional sort of enterprise-grade functionality on top of that. My background is in search, in particular, I grew -- I came to Elastic about 7 years ago now through the acquisition of the company that I started back in 2012 and joined forces with Elastic in 2017. So I've been with the company for 7 years now, leading a lot of the work that we do in kind of our core search capabilities and how we ultimately leverage that into the observability and security products, which as recently has been very focused on a lot of the work we're doing around generative AI and the sort of component capabilities necessary to help our customers bring those -- make the most of those technologies.

Let's talk a little bit about Elastic's overall, let's call it, your AI strategy. How are you guys approaching, leveraging this technology within new products? And sort of beyond that, sort of how customers are going to use them and/or how you may be using some of this stuff internally?

Yes, exactly. So it's really kind of a two-pronged approach from the way that we -- how we invest in the AI strategy. So First, there are the core investments of the component capabilities. So the investments we make into Elasticsearch itself to make it useful in AI context. So for example, the ability to do vector search is something we've been investing in quite heavily over the last few years so that we're capable of helping our customers when they need the best vector database in the world. They can reach for Elasticsearch. So that's one example of sort of a component building block. There's also the other relevance models and bringing AI and machine learning models into Elasticsearch to help our customers get more out of the data that they have indexed there, which would ultimately ends up being a really critical component for any AI system that's interacting with the foundation model or one of these very, very large language models. And so that's kind of the first component. The other component is, as I said, we also offer observability in security solutions. And over the last 1.5 years or so, we've been building more and more AI functionality into those solutions themselves. So basically leveraging those internal component capabilities of Elasticsearch to automate different aspects of, for example, the security products. So we have a security assistant, which is sort of like a copilot that helps you automate certain security tasks for the people who -- the customers who are actually using that product. We also recently released something called Attack Discovery, which is basically an AI assistant product that automates discovering attacks from the vast amount of data that you're indexing in your SIEM for security. So it's first building those component capabilities into Elasticsearch itself and then in other cases, exposing those to make our products simpler for our customers to use, if they're using the security or observability products. But then if the -- for the customers of the core Elasticsearch product itself, they're oftentimes using that to do the same kind of things in their own products that we're doing in observability and security. So they're trying to make their products more AI capable or automate certain workflows in their own products. In those cases, they reach for those. Again, those component capabilities, the first part of the strategy. So they kind of build on top of each other.

You started talking or now -- I think your vector search technology in the ESRE Engine last year. Maybe talk to us a little bit... [Technical Difficulty] Thanks. Sorry, Matt. I'm having difficulties on my end. You're going to sort of walk us through a little bit around what is ESRE, which you introduced last year? And how are you guys differentiated with your vector database?

Yes. So ESRE rate stands for the Elasticsearch Relevance Engine and really the collection of components that I was describing around these different capabilities needed for bringing AI applications to market. One of those components is the vector database itself built into the core of Elastic search. We also have capabilities like bringing transformer models into Elasticsearch directly. So when you hear people talk about text embeddings, which is usually the reason that they're using a vector database in the first place. There's a process for creating those text in beddings. You take plain human readable text, and then you turn it into a vector embedding and store that into a vector database. The process of the creation of that vector is typically through what's a transformer model. And we wanted to make sure that we were able to allow our customers to load those models into our system and make the creation of those vectors essentially seamless, both at the time of ingest when you're indexing documents that are going to be later be searched. And then also at the time when a user is asking a question, that question also needs to be vectorized, bringing transformers into the system means that it's all sort of 1 seamless process. You don't have third-party components that you're having to call out to kind of pipe all of these things together, we want Elasticsearch to be able to serve the full scope of what is needed there. We've also built some direct integrations with some of the large language models that are very popular, GPT 4, Gemini, Anthropic, a lot of the foundation model providers out there we have integrations with their APIs, allowing our customers to call them directly through Elasticsearch as well so that they're not again having to read for kind of a collection of tools. They have one entry point for building these applications.

What sort of stage are customers at with building these customized or leveraging your Azure engine? Are they just still piloting or is this -- are we getting further down the road here?

We're getting further down the road. We've certainly seen and continue to see a lot of experimentation. I think everybody is still figuring out the true power of what we're able to do now with some of these foundation models and what needs to be done to leverage them appropriately. But we -- and so we've seen a lot of that experimentation over the last year. We're also now seeing large enterprises take these applications into production today. So people have definitely gotten to the point where they're getting these in front of their own customers or in front of their own employees in many cases. So it's exciting to see that how much progress is being made. But certainly, there's still a lot of experimentation as well. People still doing a lot of development processes, testing out new things, models are continuing to get better pretty rapidly and they're changing. So the landscape is also evolving very quickly. I think Elasticsearch is positioned within the landscape or the broader ecosystem remains as the bridge between the sort of company enterprise data and the foundation models that are trained on public Internet data. So our position remains pretty stable, but as models get better and their capabilities change, we see all new kind of cycles of experimentation, people trying to use those foundation models for new and more impressive capabilities and leveraging Elasticsearch in a similar way as they build those -- that kind of like next stage of applications.

Yes. I was certainly seeing the capabilities of the open source models really approaching those of the proprietary models. So I guess you -- Elastic is based upon an open source project, but how are you guys looking at the large language model world and what -- I think you recently open sourced some additional technology, didn't you?

Yes. So we've done a lot in this space. Our general view of the large language model landscape is we've taken a very agnostic view. We want a very open view to integrate with all of them. We want our customers to have the option to work with any model that they think is the appropriate model for the application they have in mind. And as I said, sometimes that changes over time as different capabilities improve in various different ways. So we've always taken the approach where we're not integrating with just a single model. We have what we call the open inference API, which is essentially an integration point with various different vendors, and that's given us the ability to, again, to continue to play the role that Elasticsearch plays because we're not a foundation model provider. We don't have our own large language model that we are training and taking into the market. So Elasticsearch really can continue to play the same role regardless of the foundation model that is ultimately chosen by the customer for their application. We want to give them that choice. That's something that we think is really important and it kind of fits with the flexibility and the nature of Elasticsearch as a developer tool is kind of where we all started with wanting our customers to be able to build whatever application they had in mind and have the flexibility of an open source ecosystem.

It seems that the -- I mean how do you feel about this? It seems that with your core search and then you've opened up the market for observability for yourselves as an additional solution for your customers and then you moved into the security team space as well. is building LLM driven applications or GenAI applications is that potentially another leg to the stool for your business overall?

Well, our customers oftentimes are building these LLM oriented with Elasticsearch today, where Elasticsearch is basically playing the bridge between their own private or enterprise data and the foundation model that doesn't have knowledge of that necessarily. So for example, a customer that's going to perhaps build a customer support application that helps their customer support agents, answer questions more quickly than they otherwise would be able to if they were having to manually dig through data internally as they're trying to help a customer. ElasticSearch kind of sits there to index all that internal data and provide it in real time through a search interface and then feed that into essentially a context or a prompt for a foundation model to help it synthesize that data and help those agents build become more efficient over time and get answers really quickly. So that's how we're sort of seeing the -- our place in the ecosystem of building LLM or AI applications is for Elasticsearch to do that. But then again, when I said observability and security are these solutions on top of it, they're leveraging Elasticsearch to do exactly that, but it sort of as our own internal solution that we've built to deliver as a more packaged piece of software for the customers who want to buy an observability solution from us or a security solution from us directly. We're basically built on top of Elasticsearch in the same way some of our other customers are building their own bespoke applications on top of it.

Got it. Got it. There's a question just come in from the audience. The question is how do you compete against Honeycomb and some of the other dedicated vector search companies?

So Honeycomb, being an observability company, I think is -- that competition there is probably unrelated to how we compete with vector databases. But to answer the question around how we compete with other vector database companies, I think it's an interesting one. The core of our functionality is built on a search engine. And much of what people are utilizing vector databases for is for search and retrieval, they're trying to retrieve vectors that represent unstructured data that has been vectorized through some process. And so the fact that we're already a search engine is a very great point of leverage for us in that, oftentimes, you're using a vector retrieval system in conjunction with something like a traditional text retrieval system or what we call lexical search, where we're matching keywords and documents to the queries that a user is typing. Oftentimes, you're going to retrieve using both vectors and lexical search at the same time in what we call hybrid search. So that's one thing that we do quite differently. And then if you go and look at other companies like -- who are adding vector databases, into existing systems like Snowflake, for example, where we really differentiate there is Elasticsearch has also always been build around the idea purely as a real-time search engine. So you can retrieve data in milliseconds to be utilized in these real-time applications, and they're meant for production consumer-facing workloads. So if it's a financial services app where it's powering some -- like a banking mobile application or something like that or an e-commerce store on the Internet. These are all ways that when consumers are interacting with it at high scale, they expect to answer very, very quickly. Elasticsearch is really very well positioned to be able to provide that. And as we've built our vector database capabilities into the core of Elasticsearch, it benefits from all of the same scalability that we've been investing in over the last decade as well as all the enterprise grade capabilities that you need to secure these applications at scale, take them into production, put them on whatever cloud provider is the cloud provider of choice because we have partnerships with all of them and you can use Elasticsearch through Elastic Cloud on all of the major CSPs, that's really -- those are kind of the areas or the ways that we differentiate in the vector database market.

Okay. I think the question was also -- was around, I guess, is it pine cone, I'm not familiar with that.

Sure. That's definitely another competitor in the vector database space.

So you're -- is it the same of differentiation that you just laid out there?

Yes. It's pretty much. So in the case of many of, I would call them one of the sort of pure-play vector database that started as purely a vector retrieval system, the things that -- where we have the capability of also combining those searches with lexical searches or doing filtering and faceting and aggregation on top of the search results that come back. Again, at real time and at scale and through all of the different CSPs, so you can host it on Microsoft Azure or on AWS or on GCP. All of those things are that's all functionality that we've been investing in for quite a long time. The Elastic Cloud platform, we've put an enormous amount of energy into the capability of the platform at an enterprise level and the compliance and security posture that we've put into that as well, I think, is a pretty strong differentiator especially for customers in the enterprise segment who want to take these applications into their own production workloads.

Yes. I was going to ask about that. I mean compliance and governance becoming much, much more important, I think, with -- especially as companies look to make these applications customer-facing. And also regulatory changes, the European recently enacted AI Act, does that impact you guys at all?

Yes. I think it fits well into the way that we have always designed our cloud offering, for example, and also the fact that Elasticsearch is not only available on cloud. You can run it on premises. That's from our history, and it's the same software, whether you're running on cloud or running it yourself on your own hardware because data sovereignty has actually been something that we've always been concerned with. So we have customers all over the world. Some of those customers want to make sure that their data never leaves the country in which they operate. So we want to enable them to do that. And so that's actually something that we've had support for some time and the compliance posture around making -- ensuring that, that is true. It's something we've invested in is quite a lot of work to bring a cloud product to market that is that capable in that compliant. But as the landscape changes with AI and everything that's happening there, I think customers are reaching more and more for products that have those enterprise-grade capabilities in their DNA. And so I think it's a fortunate place for Elastic, and we're seeing that.

If you think about -- if you step back and you look at some of your customers maybe you're starting to build Gen AI applications, where does Elastic sort of fit in that -- that application stack, if you will, -- and who would you say is competing against you there at that level kind of that the customer would have some choice over what they want to use.

Yes. So the way that we're typically leveraged in the GenAI stack is that retrieval system. So what people commonly refer to as Retrievable Augmented Generation or RAG, is essentially, as I've described it earlier, that bridge between the data that you have inside your company and the data that a foundation model may be aware of, is kind of the way that we allow customers to do things like if -- again, I'll build on the customer support example from earlier. If a customer is writing in about a product that they purchased and/or they have questions about something like that, being able to answer their question is going to rely on you being able to pull data from your internal systems about who is this customer, what's their profile, what's their purchase history, where are they located, what other support tickets have they submitted in the past, all the context kind of that customer. And of course, that's private context. That's context that you and your support team have access to and a foundation model, a large language model from one of these large companies that train those models, they don't have that layer of data, right? They're trained on the public Internet. So we're really responsible as a bridge. So when asking an LLM to help answer a question, we need to be able to provide it or our customers need to be able to provide the LLM context. And that context needs to be very relevant to the question at hand. And that's where they reach for a search engine like Elasticsearch. We can index all of that internal private data that is about the customers' previous interactions with your company in the transaction history and things like that, search for the most relevant bits of it based on the question that's being posed and then provide that as part of the prompt to the LLM and then it's ultimately able to answer a question about something that it didn't necessarily know during training time because it's being given the context of the question as part of the prompt. So that's typically the position that we play in the GenAI stack as people are building these kinds of applications. And I've used the customer support example quite a lot, but a similar example would happen if you're building an internal workplace search type of experience where employees need to be able to ask questions about vacation policies or 401(k) policies or how they open a job rack or something like that internally using HR systems. All of these systems internally, they leverage internal knowledge that's specific to a company. And in order to enable those kinds of applications that are made more efficient using AI or can be made more efficient using AI, they again need to have some bridge between the AI system and the internal data. And so we're typically that bridge.

The fact that you're -- if you take out one of your existing large customers and they've indexed portions or a significant part of their internal data already using -- are using you already for your search capabilities. Does that give them a leg up in building these models, these new GenAI models?

Certainly, it does because one of the challenges is always getting data indexed into a retrieval system like this. But the fact that we've been around for some time, and we're one of the most broadly adopted search engines in the world, gives our customers a leg up, all they have to do is use the latest version of Elastic search. They have this fantastic vector database right there at their fingertips, and they can start using all these new capabilities right alongside the capabilities they've had in the past. And certainly, any of the data that they've indexed historically can be processed using these new techniques and leveraging these new applications.

Interesting. If we shift over to observability, your observability solution that's been in the market for a few years now has grown to be a pretty significant part of your business. What do you see there in terms of where your technology is going, where your capabilities are going? And how are you -- how is observability going to leverage AI?

I think as with many what I would call application level products, where their Elasticsearch is a developer tool with many components that are can be leveraged in a development environment to build applications. Like our observability solution is one of those applications built here at Elastic. And so much of what we're doing in terms of leveraging AI is essentially trying to make those products easier to use, make them to automate workflows, help them automate different types of remediation. So in the case of observability, oftentimes, we're helping observe technical infrastructure. We help you notice when there's something wrong in the infrastructure, whether it's a CPU spike or you're running out of disk somewhere and there's some trouble. We basically -- our goal is to help you remediate those problems as quickly as possible. Maybe historically, most observability tools are about alerting you when there's a problem. Now with the -- some of these new capabilities, we're also offering remediation steps and to automate some of that remediation. So we can alert you that there's a problem, but say, and these are the steps that you would take to handle the situation right now, given what we know of your system. So we want to be able to essentially streamline a lot of the workflows and make them just overall more intelligent for our end users.

So the human is still in the loop though, right?

Definitely. The human's still in the loop, we're just giving them sort of superpowers and the capability to be able to do even more faster and hopefully, more accurately because oftentimes, a lot of this work is not just one obvious answer. Oftentimes, it becomes exploratory when it comes to a challenge in your infrastructure, if there's some problem some downtime or something like that. Oftentimes, people are searching through various different mechanisms to figure out what exactly is going wrong if we can help automate that kind of exploration process or get to an answer much faster and synthesize or remediation for you. That's absolutely something that we're aiming to help do for our customers, so that end user their job just got faster and they can take care of problems faster, which is really kind of the name of the game in both observability and in the security markets.

Observability, I mean there's some pure-play players out there, the Datadogs of the world and Dynatraces. How do you -- how does Elastic sort of position itself when you're going after your observability kind of opportunities?

I'm probably the wrong present who speak specifically to our observability positioning just in my case, I'm -- I lead all of our core search capabilities. But with -- I think the 1 of the common things here is that we are a common platform, a very powerful underlying platform in Elasticsearch, which is a search engine. And I think when you boil down many of these observability or security problems, they ultimately turn into search problems over both structured and unstructured data. And that's something that Elasticsearch is very uniquely capable of doing, especially as that data gets very, very large. So we recently released the Search AI Lake, which is part of our serverless strategy, which essentially allows you to have infinite storage of any observability data or security data that you're ingesting into Elasticsearch while still maintaining fast search capability over that. So that, I think, itself is very unique in terms of the capabilities of the product is sort of the foundational technology is ultimately a search engine. It's very good. It's sifting through structured and unstructured data and determining relevance of data, which especially when it comes to building AI powered workflows on top of it, you have to be able to find the most relevant data through typically in the case of those products, a very large amounts of data, being able to find the most relevant bits of it so that we can then help automate some of these workflows is a really key component to an AI strategy in those spaces. So I would say that, that's probably the area where we're differentiated.

Where do you see -- on the search side of things, where do you sort of see the biggest opportunities for Elastic over the next couple of years? And where should we be looking for innovations in that space?

Yes. We continue to invest in these core capabilities, like, for example, making sure that we're the best vector database in the world is going to be -- it's an important it's an important investment for us. And a lot of the work in these core capabilities is never really fully complete. So there's a lot of optimization work you can do to -- once the vector databases perfectly capable, it's how much more efficient can we make it? How much faster can we make it? Can we make it use less memory, so it's easier for our customers to run in their environments, things like that. So there's a lot of work that we're going to be doing there. There's also a lot of work that we do with the inference API, whether it's investing in integrations with additional providers, so third parties that have built really great foundation models. There's additional things we can do in that area. We've also built a couple of our own proprietary models, which are not competitive with the sort of Geminis and GPT 4s of the world, but are used for doing relevant search retrieval, which again is a precursor to passing data along to one of those foundation models. So we've built what we call ELSA, is one of our -- is our first proprietary model that we released. And it's really for doing semantic search over unstructured data. With a high degree of relevance that wasn't possible before we had invested in this model. So there's work kind of across the board. And when we released ESRE last year, we talked about a lot of these different areas. And I think that we have the surface area about right. We're investing in the right areas. It's about depth and how far we can go and how good we can make our models, how good we can make the integrations for the open inference API. And how good we can make the vector database. So there's a lot of opportunity there. And I think, again, I would -- I have to say that all of these things have to fit together in a very easy to use and easy to understand developer model. So these -- all of these components are used kind of in different ways as they get leveraged into the applications that our customers ultimately build on top of them, the developer experience that we build around it and the tools that we provide to make that developer experience more seamless, are also a big part of what my team invests in, whether it's client libraries or recipes for getting started. A lot of that, especially in the space or an ecosystem that's changing very rapidly it's actually a very important part of how our customers can adopt the product and make sure that they're leveraging it effectively for the problem that they have in mind, that all falls into kind of my purview and the things that my team thinks about every day.

Interesting. One of the things I was -- mentioned before, we came on to you as I was at the Databricks conference is on this week, and it was mentioned a couple of times there compound models using multiple steps, I guess, in this inferencing process. That seems to me that, that would play in well for you guys as well to be part of that build?

Yes, that's exactly right. Many times, the solution to a particular problem in the AI space might take several round trips to multiple different services. Whether it's a single model or multiple models, oftentimes you will ask a question or retrieve some context and then evaluate how good of a results you get. And based on that, make the decision to either offer a remediation to the customer or kind of solve the problem for them at that point, or know that you need to ask an additional question or provide additional context. So there is very much so a development model, like a software development model that is relying on these things being componentized so that they can be leveraged individually or in succession or sometimes in parallel. But the programming model is not going to be exactly the same for every single application that gets built. So it's our job to make sure we're building our tool as a great developer tool that can be leveraged in a variety of ways very flexibly in a sort of nicely composable way.

Would a customer of yours -- and we're running up, I guess time here. We have a couple more minutes. But would a customer of yours be building their enterprise application, their generative AI application for, let's say, customer service department or what have you. I'm just trying to clarify by, there's a number of different providers out there if you think about Databricks platform or if you think about data or some of the other players out there where the model building type applications? Do you -- how does Elastic fit into that world? Are you the core with which the customer is going to build their application? Or are you plugged into some of these other platforms?

Yes. I think we interoperate very nicely with those applications actually. I mentioned earlier that we have the ability now to allow you to load your own models into Elastic search. So those models can be open source models that you take off in open source repositories like Hugging Face, for example, is a very popular model hub where people upload train models for people to be able to use. But also a lot of our -- the larger enterprises that we work with, they have their own data science teams. They've built their own models internally. They train them internally. We've, again, taken a very open approach so that you don't have to just use Elastic's proprietary models, although I mentioned that we've released one that's very good. Even so, we still allow you to bring your own model as well or take an open source model. So if you're using one of these tools, it allows you to build a custom model based on your data and you have the data science team for doing so, we interoperate that with that very well, and we would be another tool kind of in that tool chain where you leverage the model, in our case, for most likely for searching and getting relevant content out of the search engine.

Got it. So you're definitely in the flowing part of the process. And it really does give your existing customers, another a fourth sort of reason, if you will, to use you to use you to consume your platform, right?

Yes, that's correct.

Yes. Interesting. Interesting. Before I let you go here, crystal ball up for me a little bit, Matt, 5 years out, what are we going to see in the enterprise, what's different than what we're seeing now with your platform?

It's hard to say. I think there's certainly this question of how we bridge enterprise data with foundation models is -- will remain something that companies are always having to do, right? So I think that there's some consistency in what we're seeing there. What we can always expect, I think, is the models themselves, the foundation models are going to continue to get better and they're going to become more and more capable. And we're going to find -- and our customers are going to find more and more creative ways to utilize them. So I don't know exactly what applications those will be, but it's certainly an exciting time to be in the generative AI stack in one of those core components because we're getting to see a lot of the experimentation that's happening, and a lot of those applications will be invented and built on Elasticsearch.

Fantastic. Fantastic. All right. Well, thank you. Thanks very much for the deep dive. But you guys are -- it seems like you're really well positioned still and have -- the importance or the value that Elastic brings to its customers is actually going up in this very complex world we're currently in. Thank you.

Well, thanks for having me. It's great being here.