Elastic N.V. Status update

Please proceed. Good morning, everyone, and welcome.

I'm Alex Kurtzman, Vice President of Investor Relations here at Elastic. Thank you for joining us today for a deep dive into our new metrics offering. Joining me are Baha Azarmi, General Manager of Observability, and Santosh Krishnan, Senior Vice President of Security and Observability Solutions. For today's agenda, Baha will start with a brief presentation, followed by a short customer video, and then we'll open the floor to Q&A. First, let me quickly run through our legal disclaimer. Our presentation today will include forward-looking statements, which may include predictions and expectations regarding the market and demand for our products and solutions, as well as expected capabilities of our products and solutions.

These forward-looking statements are based on factors currently known to us, speak only as of the date of this presentation, are subject to risks and uncertainties that could cause actual results to differ materially. We disclaim any obligation to update or revise these forward-looking statements unless required by law. Please refer to these disclaimer of risks and uncertainties shown here, as well as those more fully described in our filings with the Securities and Exchange Commission. With that, I'll hand it over to Baha.

Thank you, Alex. Let me go to the next slide. If I can. All right. Hey, everyone. I'm Baha. I'm the General Manager of Observability here at Elastic. I've been at Elastic for 11 years, and it's a pleasure for me today to present you with our new metrics offering. Our new metrics offering has been launched almost at the beginning of our fiscal year in June. What we've done with this new metrics offering is entering this market with a solution that is not only meeting our customer requirements, but also surpassing some of the best metric solution in the market. You will see in this presentation how we did it.

But in the high level lines, we re-architectured the Elasticsearch for metrics, and we are also meeting our customers where they are, and we also made sure that we're building our metric solution for what our customers are doing today, namely looking at AI workloads. So 3 characteristic for metric solution. First, it's blazing fast. If you enter the metrics market, you have to be fast, and that's one of the guiding principle for a solution. We looked at benchmark against competitive solution, such as Prometheus and Mimir. I'll get into the numbers more in details later in this presentation. The other thing we've done is we don't want our customers to go from one solution to another when they have their logs, their traces, and their metrics with us. They need to stay in the same platform. The data store should be the same.

It's completely transparent for them to store all those signals with us when they do observability, as well as when they query the data in Elastic or they go through the different experiences we have for observability. Everything lives in the same platform. Lastly, we build it for AI. When the workload shape has changed with AI, having now agents more than traditional application, it brings much more signals, much more data, and much more metrics than before. So, we thought about our metric solution to be as efficient as possible to cope with that new type of workloads. But before I get into more details about what we've done, just a level setting with everyone. If you're not familiar with what the metrics are, metrics is the main signal in observability. That is literally what wakes up engineers at 3:00 A.M.

in the morning when there is an incident, page people when there is something to look at. So when you use an observability solution, you create rules. Those rules are triggering alerts, and 99% of the time, those rules are based on metrics. So couple of example here on the screen. Say you have an application, a web application, and you're looking at the traffic on this application. You will look, for example, at the number of HTTP requests. This application relies on an infrastructure, on an application stack. There's different technology involved and resources that are allocated to this app. So you will look at the resource utilization, such as the CPU. Or you can also look at things like the latency of the request going into the APIs you're exposing through this application. So lot of those characteristic of your application are emitting metrics.

Your application, your infrastructure are emitting metrics. Those metrics are capturing observability solution, and then you create rules that triggers alerts that then page people. The thing that has changed is when you look at a traditional application, say, a banking application, and you go yourself as a user in your bank account, and you look at your statement, you scroll through the statement, you click on an item. All of those are predefined path and transaction into those applications that are quite traditional. You have a front end, a back end, a data store, database, microservices, cloud deployments. All of that, I put this into the bucket of a traditional application. So not only those transaction are well known, and in addition to this, like I said, this emits traces, logs, and metrics. So there is a predictable volume you could expect for it.

But for agents, it is very different. AI is really causing an explosion in metrics. When I say AI, you can think about the different type of workload or things you need to observe, such as LLM calls, GPU cycles, RAG queries, agent and harnesses. All of that is creating a new set of observability signals that needs to be captured. The challenge is, as you all know, when you interact with an LLM, there are reasoning steps, and those reasoning steps, they depend on what you are asking for. It goes into tool calls. Those tools are not necessarily known in advance. Now you have agent calling your traditional application probably exposed through MCP, and it is really unpredictable amount of turns you will get with agent. That causes now a new paradox for customers.

First, customers have to think about, how am I going to cope with all that data? We know that there are solution out there that are penalizing customers, and they are not able to keep all the data. The problem with this is, then they start to have blind spots. They have to compromise on the number of data they can keep. Then when there is an incident, they do not get the full fidelity on what happened. It becomes difficult for them to understand what the root cause is. New challenges with AI. When we started to think about how we will go to market with this new metrics offering, we set couple of guiding principles, and I will explain those more in details in later slides.

First, we introduced a new way to store metrics, and not only to store them, but also to manage them. It comes with functionalities that will automatically roll up, down sample or compress the data. Second, we wanted to make sure that users of metric solution will feel familiar when they land with Elastic and use our metrics offering. We put a particular attention to support standard in the market such as PromQL, and we will see that. Lastly, again, we build it for the AI scale. You saw that AI is bringing more data and new things to observe, and we build it for that with the efficiency that is required to cope with that workload. You know Elastic probably for logs. Our customers are trusting us for their messy logs. We are more than happy to receive all that unstructured data.

At the core, we are a search engine, so very good for structured and unstructured data. Logs are flowing in. They get into a document store. We extract those fields, and then we make them available for aggregation. We can full text search on it. That is our story on logs and how we do it. We use a document store. For metrics, the game is very different because metrics have a different shape than logs. There are numbers. They come with labels. For example, you have something like a number that represent the CPU usage. You have a timestamp. You have dimensions. It belongs to this host that is deployed on this Kubernetes pod, that is deployed on this region of the world, that is deployed on this cloud provider, et cetera. So many different dimensions. For this to cope with metrics, we completely re-architectured Elasticsearch for it.

We build a column store within Elasticsearch because metrics are coming with their own challenges. I just talked about the dimensions. First, the dimensions is something that is very hard to manage for existing metric solution in the market. We wanted to make sure that we were not limiting our customers in terms of the cardinality. Those are the words you will hear a lot with metric solution out there. Cardinality is something we don't want to limit. You can have as many dimensions as you want. Then we say that, and then our user is like, "Okay, but what does that do in querying?" Because when you have a lot of dimensions, it start to be difficult to manage all that data in memory.