Good afternoon everyone. Blair Abernethy here, Software Analyst with Rosenblatt. Thrilled to have Matt Riley with us from Elastic here. Matt is General Manager of Enterprise Search Solutions at Elastic, so welcome Matt. Thanks for having me, Blair. Maybe if we just want to give a little context to the audience that may not have followed Elastic recently, just give us a bit of an overview of the business and the market problems that you guys solve or address for customers. That would be really helpful. Sure, yeah. So again, thanks for having me. Elastic is the company behind Elasticsearch, which is a distributed search engine built for real-time search. Probably one of the most downloaded open source products in the world at this point. 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 company or adding search to a website, an e-commerce store for example. Then we've also built businesses in the observability and businesses as well, both of which also heavily utilize the search capabilities of Elasticsearch. But observability is all about monitoring your technical infrastructure and then security is about securing that. So all of it again on the same platform. But those are sort of the three primary pillars, business and the product offerings that we have. And it's literally millions of downloads of the search product. Right? So yeah, over 4 million at this point. So many, many people all the time around the world. Hundreds of thousands of enterprises, you know, get to try it out, use it on a limited basis I guess compared to your full stack subscription level. Correct. Yeah, the free and open source version has a lot of the functionality, the core search engine. So we have a lot of, you know, businesses who use that. 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 came to Elastic about seven years ago now through the acquisition of a company that I started back in 2012 and joined forces with Elastic in 2017. So I've been with the company for seven years now, leading a lot of the work that we do in our core search capabilities and how we ultimately leverage that into the observability, 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 make the most of those technologies. Let's talk a little bit about Elasticsearch overall. Let's call it your AI strategy. How are you guys approaching leveraging this technology, you know, within your products, you know, 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 interna lly? Yeah, exactly. So it's really kind of a two-pronged approach from the way that we, the 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, you know, the ability to do vector search, we've been investing in quite heavily over the last few years. So we're capable of helping our customers when they need the best 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 and more relevant content out of the data that they have indexed there, which ultimately ends up being a really critical component for any AI system that's interacting with the foundation model or one of these very large language models. And so that's kind of the first component. The other component is, as I said, we also offer observability and security solutions. And over the last year and a half 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, these security products. So we have a security assistant which is sort of like a copilot that automates certain security tasks for the people, 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 the discovery of attacks from massive data that you're indexing in your SIEM for security. So it's first moving those component capabilities into Elasticsearch itself and then in other cases exposing those to make our product simpler for our customers to use. If they're using the security or observability products 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 like 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 you started talking to your vector search technology and the ESRE engine last year. Maybe talk to us a little bit. Thanks. Sorry Matt, I'm having difficulties on my end. You were going to 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? Yeah, so ESRE stands for the Elasticsearch Relevance Engine. It's really the collection of components that I was describing around these different technologies needed for bringing AI applications to market. One of those components is the vector database itself built for Elasticsearch. We also have capabilities like bringing Transformer models into Elasticsearch directly. So when you hear people talk about text embeddings, which is the reason that they're using the vector database in the first place, there's a process for creating those text embeddings. You take human readable text and then you turn it into a vector embedding and turn that into a vector database. The process of the creation of that vector is typically through what's a Transformer model. 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 searched, and then also at the time when a user is asking a question. The question also needs to be vectorized. Bringing transformers into the system means that it's all sort of one seamless process. You don't have third-party components that you're having to call out to kind of punch 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 of some of the large language models that are popular. GPT-4, Gemini, 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 reach for a kind of collection of tools. They have one entry point for building these applications. What sort of stage are customers at with building these customize or leveraging your ESRE engine? Are they just still piloting or 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 foundation models and what needs to be done to leverage them appropriately. 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, 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 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's position within the landscape of broader ecosystem remains as the bridge between sort of company enterprise data and the foundation models that are trained on data. So our proposition remains pretty stable. But as models get better and their capabilities change, we see all new cycles of experimentation. You use those foundation models for new and more impressive capabilities and leveraging Elasticsearch in a similar way as they build the kind of next stage of applications. 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. How are you guys looking at the large language model world? I think you recently open-sourced some additional technology, didn't you? So we've done a lot in this space. Our general view of the large language model landscape is we keep in a very agnostic view. We want a very open view to all of them. We want our customers to have the option to work with. Any model we're keeping is the appropriate model for the application they have in mind. As I said, sometimes that changes over time as different capabilities improve in various different ways. 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. That's given us the ability to again continue to play the role that Elasticsearch plays. Because we're not a foundation model provider, we don't have our own large language models here, training in the market. 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 is really important and kind of fits with the flexibility and the nature of Elasticsearch as a developer tool. Kind of where we all started with wanting our customers to build whatever application they have in mind and have the flexibility of an open source ecosystem. It seems that... How do you see the themes that your core search and then you opened up the market for observability yourselves as an additional solution for your customers, and then you moved into the security SIEM space as well. 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 applications with Elasticsearch today, where Elasticsearch is basically playing the bridge between their own private or enterprise data. And the foundation model 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, 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 the search interface and then feed that into essentially a context or a prompt for a foundation model to help synthesize that data and help those agents become more efficient over time. Answers really quickly. So that's how we're sort of seeing the. Our place in the ecosystem of building LLM AI applications is for Elasticsearch to do that. And again, when I said observability and security, are these solutions on top of it? We're leveraging Elasticsearch to do exactly that, but sort of as our own internal solution that we built to deliver the more packaged piece of software. Customers who want to buy an observability solution from us or a security solution from us directly were built on top of Elasticsearch in the same way some of our other customers are building their own applications on top of it. Got it. Got it. The question just come in from the audience. The question is, how do you compete against Honeycomb and so many other dedicated search companies? Honeycomb being an observability company, I think is there's competition? There is probably unrelated to how we've discussed, the question around how we compete with other vector database companies, I think is 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 retrievable vectors that represent unstructured data that has been vectorized as some process. And so the fact that we're already a search engine is a very great piece 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 who are adding vector databases into existing systems like Snowflake for example, where we really differentiate there is Elasticsearch has also always been until around the idea truly as a real-time search engine. So you can retrieve data in milliseconds to be utilized in these real-time applications. They're meant for production consumer-facing workloads. So if it's a financial services app where it's powering like a banking mobile application or something like that, or an e-commerce store on the Internet, these are all ways that consumers are interacting with it at high scale. They expect answers very, very quickly. Elasticsearch is really very well positioned to be able to provide that. As we've built our vector database capabilities into the core of Elasticsearch, it benefits from all of the same scalability 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, keep them into production, put them on whatever cloud provider is the cloud provider of choice because we have partnerships with all of them. 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 is it Pinecone? I'm not familiar with that. Sure. That's definitely another competitor in the vector database. So the same differentiation that you just laid out there? It's pretty much so in the case of many of—I would call them—one of the sort of pure play vector databases such as purely a vector retrieval system. The things where we have the capability of combining those searches with lexical searches or doing filtering and aggregations on top of the search results that come back in 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 capabilities of the platform at an enterprise level. The compliance and security posture that we've tied to that as well is a pretty strong differentiator, especially for customers in the enterprise segment who want to take these applications into their own production workloads. Yeah, I was going to ask about that. 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. Europe's recently enacted AI Act. Does that impact you guys at all or? I think that 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. 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 you've always been concerned with. So we have customers all over the world. Some of those customers want to make sure that they never leave 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 for some time. And the compliance posture around ensuring that is true is something we invested in. It is quite a lot of work to bring a cloud product to market that is that capable and that compliant. As you know, as the landscape changes with AI and everything that's happening there, customers are reaching more and more for products that have those enterprise-grade capabilities in their DNA. And so I think that's in place for Elastic and we're seeing that. If you think about some of your customers that maybe are trying to build Gen AI applications, where does Elastic sort of fit in that application stack, if you will? And who would you say is competing against you there? At that level, the customer would have some choice over what they want to use. Yeah. So the way that we're technically leveraged in the GenAI stack is that retrieval system. So what people commonly refer to as retrieval-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 foundation model should be aware of is kind of the way that we allow customers to do things. Like again, I'll build on the customer support example from earlier. If a customer is writing in about a product that they purchased 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 have they submitted in the past? All the context kind of that customer. Of course, that's private context. It'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 that bridge. When asking an LLM to help answer a question, we need to be able to provide it for our customers, need to be able to provide the LLM context. That context needs to be very relevant to the question at hand. That's what we trust. Search engine like Elasticsearch, we can index all of that internal credit data, how can customers' interactions with your company and 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. Then it's ultimately able to answer a question about something that it didn't necessarily training time because it's given the context of the question as part of the essential 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 similar to what happened if you're building an internal workplace search type of experience where employees need to be able to ask questions about education policies or 401(k) policies or how they open a job req or something like that internally using HR systems. All of these systems internally leverage internal knowledge that's specific to a company in order to enable kinds of 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 the bridge. The fact that you're, you know, if you take one of your existing large customers and you index portions or a significant part of their internal data already 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 prominent search engines in the world give our customers this leg up. All they have to do is use the latest version of Elasticsearch. They have this fantastic 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. Currently any data that they've indexed historically can be processed using these new techniques to leverage it into applications. Interesting. If we shift over to observability, your observability solution that's been in the market for two years now and has grown to be a pretty significant part of your business, what sort of sees there in terms of where your technology is going, where your capabilities are going, and how is observability going to leverage AI? I think as with many what I would call application level products, where Elasticsearch is cool, with many components that can be leveraged in a development environment to build applications like our observability solution is one of those applications built here at Elastic. So much of what we're doing in terms of leveraging AI is essentially trying to make those products easier to use, making 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 these problems as quickly as possible. Maybe historically, most observability tools are about alerting you when there's a problem. With the 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 these are the steps that you would take to manage 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, some problem, some downtime or something like that, 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 synthesizer remediation for you, that's absolutely something that we're aiming to help do for our customers so that the 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. There's some pure play players out there, the Datadogs of the world and Dynatrace. But how does Elastic's position itself when you're going after observability kind of opportunities? I'm probably the wrong person to specifically for observability positioning. Just in my. I lead all of our core search capabilities but with I think one 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 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 as part of our serverless strategy, which essentially allows you to have infinite storage of any observability data which you can get 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 at 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, large, very large amounts of data. Being able to find the most relevant piece 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? Yeah, we continue to invest in these core capabilities, for example, making sure that we're the best vector database in the world. It's an important investment for us. A lot of the work in these core capabilities it never really fully complete. So there's a lot of optimization work you can do, too, once the database is 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 environment, 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 all of its search retrieval, which again is a precursor to passing data along to one of those composition models. So we built what we call ELSER is a 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. When we released ESRE last year, we talked about a lot of these different areas and I think that we have the surface area of outright, 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 we can make the integrations for the Open Inference API and how we can make the vector database. There's a lot of opportunity there. I think again, 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. All of these components are used 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 that 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 a space or ecosystem that's changing very rapidly. That's 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 my purview and the things that my team thinks about every day. Interesting. One of the things I was mentioning before Giovanni was I was at the Databricks conference is on this week and it was mentioned a couple of times there compound models using multiple steps in this inferencing process. That seems to me that would play in well for you guys as well to be part of that build. Yeah, that's exactly right. Many times a 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 result you get and based on that make the decision to either offer 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. 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 and in a sort of nicely composable way. Would a customer of yours and we're running up against time here, we have a couple more minutes. But would a customer of yours their enterprise application, the generative AI application for let's say, you know, customer service department or what have you. I'm just trying to clarify this. There's a number of different providers out there. If you think about, you know, the Databricks platform or if you think about Dataiku or some of the other players out there where you know the model building type applications, how does Elastic's 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? Yeah, 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 Elasticsearch. So those models can be open source models that you take off repositories like Hugging Face, for example, is a very popular model hub where people load train models for people to be able to use. Also a lot of our larger enterprises that you work with have their own data science teams, 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 ELSER one is very good. Even so, we still allow you to train your own model as well or take an open source model. So if you're using one of these tools that allows you to build a custom model based on your data and you have the data science team for doing so, we interoperate very well and we would be another tool in that tool chain where you leverage the model. In our case, we're likely searching and getting relevant content out of the search engine. Got it. So you're definitely in the flow in part of the process. And it really does give your existing customers another, you know, a fourth sort of reason, if you will, to use you. To use, you know, to consume your platform. Right, that's correct, yeah. Interesting, interesting. Before I let you go here, kick the ball up for me a little bit. Matt, you know, five years out, what are we going to see in the enterprise that's different than what we see now with your platform? It's hard to say. I think that certainly the question of how you bridge enterprise data with foundation models will remain something that companies are always having to do. Right. So I think 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 will be, but it's certainly an exciting time to be in the Generative AI stack, one of those core components, because we're going to see a lot of the experimentation that's happening and a lot of those applications will be invented to be built on Elasticsearch. Fantastic. All right, well, thank you. Thanks very much for the deep dive. You guys are. It seems like you're really well positioned still, and the importance of the value that Elastic brings to its customers is actually going up in this very complex world we're currently in. So thank you. Thanks for having me. It was great being here.