I'm going to actually move over here because I can't even see any of you guys, and with you in the middle. Olivier is obviously a much more interesting and important person than me. For those of you who don't know me, I'm Peter Weed from Bernstein. I cover software. There's actually two of us at Bernstein that cover software that you might know, Mark Moerdler and myself. I do kind of IT infrastructure, dev-type software, which is kind of my long-term background. I've been kind of around it since the late '90s. You may know Mark, my colleague. He actually was a database entrepreneur back from the same time, so he covers databases and mostly functional line-of-business applications. We are really fortunate today to have Ollie from Datadog join us. Ollie is one of the founders and the CEO of Datadog, a company that has been really instrumental in a category that has really kind of emerged over the last decade that we now call observability, which is all about helping. When you ship a cloud application, you expect it to run. This is a company that helps ensure that it's both up and it's running at performance. Before you even put it into production, you can predict how it might behave. I recognize the audience is probably going to be a variety of background in Datadog and kind of where they are. I think it may be relatively obvious from some of the stock price action recently that things are going pretty well. Ollie, I thought it might be just interesting to kind of reflect on the last three to four quarters and the acceleration that you've seen, and where has that really been coming from? Yeah. Look, first, thanks for having me here. We have seen acceleration for the past few quarters. I won't bore you with the exact numbers. They're all in the filings. We've seen acceleration. What's the most exciting to us is that it is not a specific customer, a specific set of customers, a specific side of the business. We've really seen acceleration across the board. The way we look at the customer base today is we look at both what we call the AI natives, which are largely companies that were started in the last few years, built on AI, or companies that were selling a little bit before that are essentially the large builders of the most important building blocks of AI today. We see acceleration in that category, which sort of makes sense. Everybody knows AI is happening right now. What's even more interesting is we've seen acceleration of the business outside of that, so in the non-AI companies. For us, that's a mix of the older cloud natives, which existed before AI, and also all of the larger enterprises, whether they are large enterprises or mid-market. We've seen acceleration across all of that. On the AI side, obviously, the AI companies are consuming a lot of infrastructure, building a lot of applications, running a lot of applications, and that's what we see on a day-to-day basis. On the rest of the market, we see also more applications, but we also see some growing adoption of AI itself. We've disclosed in our last quarter that we've seen very large increases in volumes of our AI-specific products, whether that's the traffic we see to our MCP services or whether that's the traces we get into our LLM Observability product that really gets traces produced by AI agents. We see inflection across all those points. Ollie, I think you've done a really nice job helping people kind of understand how you get paid and how you kind of ride the cloud wave. Maybe describe how you think about where your value comes and where your growth equation kind of comes from over long periods of time. The value comes from helping customers be on top of the complexity they create with their applications. Meaning they ship applications, they have to understand what infrastructure is part of that application, how it's running, whether the application itself is running, if it's fast enough, what the users of that application are doing, whether the application is creating the right outcomes for the business, whether the application is safe and is secure. All of that's what we do for our customers. One way to think about the growing importance of what we do is that over time, developers have become way more productive. When you go back 50 years, or even more than that, developers were hand-coding every bit on punch cards and writing every single piece of code that was running. After that, there's been higher-level languages, better interfaces, compilers. After that, you've seen open source software, you've seen cloud, you've seen SaaS, and internet. At every single step of the way, you've seen an increase of productivity. What it means when you get higher productivity is that you produce more in less time, which means that you don't really get to spend as much time on it. You don't understand what's actually going on. You see an even bigger acceleration of that today with the coding agents, where engineers can, in a few minutes, whip up an application. They just have no idea what's going on. They probably don't even read the code. They combine all sorts of different components into an application. That increase of productivity creates a dramatic increase in complexity. The problem we solve for our customers is we actually understand that complexity, we manage it for them. In the future, we want to do even more and automate basically the way their applications run after they've written them. It's interesting. I think one of the bear cases that has been pervasive around software is like now that we actually have these agents, this complexity can now be handled, and can't we just go ask whether or not it's Anthropic Claude or any of these LLMs to just do it for us. How's my system doing? Tell me when it's down. Why does Datadog still have a role in a world where we have these AI agents? Maybe it's not today, but maybe three years from now, they get smart enough to do this. Yeah. A few things I'll say. First of all, the companies that are building these kinds of models are also using our product to manage their infrastructure and their applications and everything else. It is a hard job. It is consistently a harder job than writing the application itself. That is why there's been this race against complexity over time, and everybody's going after it, including the leading companies in AI, be they AI builders or the hyperscalers. That's one thing. The other thing I will say is that the kind of problems we solve are somewhat different in nature from what these fundamental models or foundational models are built for, and operate at very different levels of data volume and real-time requirements. We have five or six orders of magnitude more data than what is typically put in an LLM. We need to operate in near real time. The analogy I would give to understand where we stand with the problem we solve versus what these models do is compare it to self-driving cars. Today it's working pretty well. You have self-driving cars everywhere. You could, if you wanted, take a photo from your dashboard in your car and upload it to Claude and ask what you should do, and it will give you an answer, and it would be a pretty good answer. It will tell you, "Well, actually you should turn on the right, and that's why, and this is what's going to happen there." The problem, though, is that Claude will do that, but it will not drive your car in real time. If it did, it would do it poorly, way worse than the algorithm or the model that's running in your car. Also it would cost you $10,000 a day to drive your car. That's a way to understand what these models do relate to what we do, in our case, for observability, automating the life cycle of an application, automating the availability, the validation, the security of an application. I think the other bear narrative, when you get through that, oh my gosh, there's actually a difference between deterministic programmatic software and kind of probabilistic software. It's like, okay, well, I still have these code suggestion tools, and we've got some open source. Why can't I just ask it to build me this bit of programmatic software? You're obviously not seeing that happen. What's the disconnect between that narrative and the reality of why the most innovative companies are turning to use Datadog as opposed to do it themselves? Yeah, it doesn't make economic sense for you to do it yourself, typically. The reason for that is that what we provide gives enormous leverage. Typically, for any dollars customers spend on us, they're going to spend $10 or $20 on their cloud provider. They're going to spend $20 to $100 on their engineering team. With the rise of coding agents and AI models in general, maybe some of that $20 to $100 they're spending on their engineering team is actually going to go to these AI models instead. We're talking about huge amount of leverage. By the way, we help our customers make the most or optimize their spend on their cloud provider, on their engineering team, on their AI models, and on all of that. We're basically the small part of spend that helps our customers make the most out of the rest and accelerate and make more money. At the end of the day, it makes no sense for any of them to do that. I'll give you a few more examples that we've had more recently. We mentioned over our last earnings call that we also had a number of hyperscalers that started adopting our products, in their case, for helping with the development and training of their AI models. These are companies that culturally, basically don't use any commercial software. They write everything themselves. They use open source. They're completely homegrown by nature. Even those companies had to come to the realization that actually, it didn't make sense for them to do that. They would get better outcomes. They would get faster delivery of what mattered the most to them. They would get better economics of it. That would be better for the business in the long run. We didn't build Datadog to serve a handful of hyperscalers. That's not our business model. Our business model is to go after every single other company out there, have products with very broad appeal. We think, though, that this is a great example of these hyperscalers just going for the first time, maybe through what every single other company has to think through, which is, okay, so what do I need to own? What should I not own? How do I get the best return on investment? What am I trying to achieve? I need to get growth. I need to get better economics at scale. What's the best way of doing that? I have finite resources. What should I focus on? I think that's what we're seeing at play here. If can't be replaced by AI, just asking questions, can't be coded. This place still has a tremendous number of startups. I spend a lot of time on Hacker News, for better or worse. I would say every month there's somebody who's celebrating the fact that they're trying to build some new observability platform. You and I were talking about this a little bit, but beforehand, my history, I'm an old product manager, years ago at Microsoft, in the middleware category. The one thing that has stuck with me this whole time, and when I worked at McKinsey and other places, is that I always watched the buyer. For me, what I noticed is that the greatest chance for a new entrant coming into a market was when the buyer changed, right? You could say, why does Salesforce exist and replace prior CRMs? Because the buyer moved from the CIO to the head of the function. Why is Datadog, I think, an amazing company that replaced prior generations of what we might have called monitoring software? Because we got the site reliability engineer and a new set of expectations and requirements when we move to cloud delivery. and management. If we look at AI, it appears, and I think you've made a good case for when we've chatted in the past, the roles might compress again. There may be several roles that need to get redefined if we're really going to have high velocity shipping. Security might need to be grouped in as well, and that looks like one of those scenarios, kind of like the site reliability engineer that collapsed some old roles together and gave you an opening into the market. I think you guys have been thinking about this almost from day one, about why that type of change actually is what you're almost hoping for because of the upside as opposed to being a threat. Mm-hmm. A couple of things on that. The first thing I'll say is, I think you're underselling it when you say there's another new engineer building an observability product every month. I think it's every two weeks. Yeah, that's probably true. It's been like that since the very beginning of Datadog. I still remember the first fundraising meeting I took with VCs way back in 2010. The first words that came out of the mouth of the investor were, "Oh, monitoring," because that's what it was called at the time. "Monitoring, crowded market." It went downhill from there. It's always been like that, and I can't blame people for doing that, and that's what I did. I'm an engineer. I started an observability company, and that's the nature of it. I think we did approach it a little bit differently, though. Our starting point was not, "Hey, let's build a better product X." "We're using that, we hate it, we're going to build a better one." "We're using that, it's too expensive, let's build something else." The starting point for us was, hey, I used to come from development. My co-founder used to come from operations, technical operations. The two teams fought all the time, and we thought, "Okay, so maybe we can bring them together, and have one platform that bridges the gap between the roles and things like that." That vision actually lended itself very well towards adding more roles, bringing more people into the mix, expanding the footprint over the lifetime of the company, and that's what we've done. We were actually quite lucky because what we didn't understand when we started that was that the collapsing of the role at the time between dev and ops were at the center of cloud adoption. The whole DevOps movement was born at that time, and that's when you saw those roles become closer, and we saw that pull in the market. You see even more of that happening today. You see security is being brought in. You see with the advent of coding agents now, instead of large teams with specialists, you're going to have smaller teams with people wearing many hats across product design, engineering, security, and many other functions. I think we're going to see even more on that. The last thing I would mention, because you talk about resisting disruption, and we built also the company very deliberately in a way that keeps us in touch and honest when it comes to the low and bleeding edge of the market. We have more than 30,000 customers, but the bottom half of those 30,000 customers represent about 1% of our revenue. We do not serve that bottom half for money. Actually, it costs us money to serve those customers. We do it because those customers are small companies. They're individuals, students. We also have people on the free tier that we don't even include in that. What those people do is they keep us honest with respect to the simplicity of the product. They also help us see what's coming in the market. We see they adopt all of the new stuff way before the large companies do that. We see that coming. We get an idea of what we need to build for. Whenever we break things, because we try hard to accommodate our largest customers that have very sophisticated needs and that make our products more complex, we see actually, and we hear from those smaller customers, and we also see in the numbers that really something is not working as it should be working there. The alternative is what most software companies do, which is they quickly understand that most of the money comes from the higher end of the market. As a result, they focus to care mostly about their large enterprise customers, they end up being on the path towards feature escalation. Before you know it, you end up with products that are what I call enterprise abominations. We all live with them every day in the office. We know exactly where they are. I think that you don't come back from that, basically. That's where you become irrelevant over time. I think we've focused a lot of this conversation on some of these bear cases. Yeah that people have. Maybe we should turn it a little bit to some of the opportunities, right? You all don't rest, obviously. I think you spend more on R&D than pretty much the entire rest of the sector put together, so you're shipping a lot of things. If we look historically at the S-curves that the business has gone through, maybe you started with metrics, actually, really kind of collaboration and then metrics and then APM and then logs. These have each kind of grown to being kind of billion-dollar type opportunities. There's several things that you've been putting out that you, I think, have been very hopeful that could become some of those next S-curves. Whether or not it's security, whether or not it's AI monitoring, the GPUs m onitoring that you guys have been putting out. When you look at the acceleration that's going on right now, how much can you thank those new things for this versus your existing footprint? What's interesting is most of the acceleration, mathematically, it comes from the existing stuff. Yeah. When you think of we have the I think we said 14 of the top 20 AI companies using us, including the very largest of those. They use the same traditional products as the rest of our customer base. By and large. That gives you a sense of the shape of the market in general. When you look at the observability category, there's this Gartner number that we quote every year, but we're number one in observability according to Gartner, or at least the category they have that's closest to observability. I forgot the exact name of the category. We only have about 13.6% of that market right now, and it's a market that is growing pretty far, pretty fast. It doesn't take a ton of imagination to see where there's a 5X from there to just from the core, the observability, looking at infrastructure applications, end users around those applications, logs, and all of that stuff. That's that. The new part of the market is everything that relates specifically to AI. Part of that is what we call AI for Datadog, which is how we can do more for our customers and really expand beyond the observability category. Basically automating the whole cycle for them. Not just being in the business of telling humans how things are going, but being in the business of fully running and automating the application, its promotion to production, its repairing it when there's an issue, making sure it's secure at any point in time. There's a lot of automation we can do with that. Another area is what we call Datadog for AI, which is observing and understanding all of the AI components our customers are using. Mostly, this fall into two categories. One is the AI models our customers are using within their applications or within their agents, which are non-deterministic models, and which can't just be tested in development and then validated and then shipped to production. You have to keep observing them all the time. They're like humans. You have to get to know them, and you spend time all the time, and you keep watching, and you see what's going on, and you keep adjusting. That's one big area. Another area is adapting to the whole new world of agentic coding, when developers can produce a lot more applications a lot faster. What they still can't do faster is getting those applications to production. They still need to make sure that those work, that they do what they're supposed to be doing, that they provide the right outcomes for the business, that they're secure, that they keep working once they've been put into production, and when other people are also making changes to the world around them. That's a huge, right now we see a huge increase in the volume of code changes that are being made and applications that are being shipped. There's a big opportunity for us there, too. I think there's probably two natural places to take this. Maybe we start with Datadog for AI. If we think about some of the things that are going on there, obviously, there's some very basic uses of AI. As we start to get to agents and what may be beyond coding copilots, there isn't a lot of depth of use of agents. As we get more and more of that, there are some kind of unique observability problems that come up with essentially monitoring the behavior of the agents over time. There are some companies that have come out, things like LangChain and Braintrust and these types of things that are designed to kind of tackle some of that job. How do you see Datadog working alongside of or instead of some of these kind of born-in-AI components that are there to observe the behavior of agents? Yeah. I think there's two extremes to that market. There's one side, which is everything that's in production. When you talk about things that are in production, it doesn't make any sense to separate the AI from the non-AI components. For one thing, what the agents do is, they have a lot of reasoning, but also they use a lot of tools, and the tools are actually apps. When you monitor the whole thing, you basically end up monitoring largely apps with a little bit of AI sprinkled on top. When you're on production, it doesn't make any sense to have different tooling, and that's something that we developed. We have an LLM Observability product for that reason, and something that we will want to own in the end. On the other side of that spectrum, you have what happens in development. When developers are tinkering, they're playing on their laptop, they're testing various things. Historically, that side hasn't been very platformy, in that in a company you don't have one of them and everybody plugs into it, but rather you've had many of them, and these were more a matter of choice and taste for the individual developers. The equivalent there would be the IDEs the developers were using. I'm old enough to have lived through some of the Emacs versus vi wars. I remember people being very opinionated about the editors they use and things like that. Whereas observability, you have only one production application, so everything has to plug into one environment, to one thing in the end, and that's platformy in nature. What's not completely clear to us today is how much of that is purely developer, purely local, non-platformy, lots of diversity of usage in any company, some homegrown, some open source, et cetera. What parts is there and how far basically back there we have to go to own fully the production side of things. When you look at that opportunity going forward, I think perhaps one of the challenges is it's very dynamic. Yeah. How we want to do all of this stuff is somewhat of a work in progress. How do you think about your own investment in being part of the frontier there, so you're in the right place at the right time, when things start to solidify and become a little bit more common across organizations? We spend a ton of time watching our customers and what it is they do and how they work. We have the luxury of catering to every single layer of the stack in the customer. Most of our business is with large enterprises. We also serve a lot of startups in AI, whether they are the super large scale model makers or the companies one level below, that are largely AI native and building on AI. When you look at the largest, it's interesting to see how they work, but it might not be completely transferable to the rest of the market. Because those companies have unlimited access to inference, for one thing. For a number of them, like a almost vertical wall of demand in front of them. They're not in a situation that most other companies are in. They might make different choices and the way they operate might not carry across. When you look at the tier below that, though, the companies that are still very successful, growing fast in AI, but are still buying most of their inference from somebody else, and have to make some hard prioritization call in terms of what they work on and not, and have more relatable growth for the rest of the market. I think from there's a lot we see and we can learn in terms of where the world is going. We see the trends pick up a few quarters before the rest of the world might see them and we get some interesting insights in terms of how our products are being used and what we need to be able to support those companies as they do that. I feel dumb. I feel like I should have almost even asked the question in a slightly different way, because I realize for the audience, they might not fully appreciate your product-led approach to the organization, which you're describing some of the outputs of. Product-led is something that I've been in love with ever since I got enamored with Atlassian's flywheel approach. Back around 2010, I tried to apply it to several businesses, like building it out of Dropbox and things like this. Maybe help people understand what is special about that product-led approach to the organization, with the growth function and with product management being so tight. Yep discovering these opportunities and delivering and why that allows you to stay so innovative. Yeah. The whole business is built around bottom-up product adoption. Our product is typically adopted by the rank and file and the people who actually do the work. We build around a unified platform, which is very important, meaning every single new product we build is part of that platform. Whenever we do M&A and we acquire a company, we replatform. Everything is part of that tightly integrated in one single platform. We charge per usage, so the whole business model is usage. There's a few tiny parts of our revenue that are seat-based. That's because we compete in categories that are purely seat-based. The vast majority of our revenue is completely usage-based, which also is interesting because right now it allows us to Basically, we don't have any transformation to undergo to get into an AI age where the notion of seat gets disrupted and you have to charge per outcomes, per value, per something. We're already usage-based, we can very easily adapt our model. Everything around the business is geared towards the adoption of the product. When we land a customer, we're already deployed typically, and we just see the usage start growing from that time. What this gives us as a business is a great way to understand which products to build and not build for our customers, and which is valuable or not. Again, we're usage-based. We're fairly religious about having that usage or having new products being attached to a new SKU, meaning that we get very clear signal about what's valuable and what's not in our products, which allows us to keep developing a lot of the right things. If you follow the business, we're known in the industry for very quickly expanding a product footprint, very quickly improving the existing product, and being very good at growing all those different new lines of business. We have a lot of stats in our earnings around the adoptions of those businesses. The other things we get from having this product-wide approach to the adoption and bottom-up adoption is that we have a very efficient go-to market. We spend significantly less as a% of the top line on go-to market, than the typical enterprise businesses. Which allows us to invest about 30% of the top line on the R&D, which then feeds the flywheel of building more product and building more differentiation, and being relevant for the long term. Maybe the asterisk on that now has been that you are actually starting to build some enterprise sales capability. What drove that evolution where you keep kind of the product-led core, but you realize that some enterprise overlay was important, and how has that kind of worked in together? Oh, enterprise has been around for a while. We built that team many years ago, so all that's a big team. What's important to understand is that it's enterprise, but bottom-up. It's never the case, or maybe it happened once. It's never the case that you call up the CIO and you're super impressive in your golf game, and you end up with a deal that gets done. That's not what happened. In our case, we start with the teams, the teams adopt us, then we make sure that we connect between the teams that are adopting us and the leadership in those enterprises, so that they understand what is it they're buying and what the ROI is and things like that, so that we can enter growing and longer term agreements with those companies. Even with the large enterprises, we mostly land very small. Like in the ASPs, when we land, are in the, let's call it mid five figure to low six figures every year. Which is very small for this kind of enterprise deal. Then we grow those customers for the very long term. We announce on the earning calls, we typically have very interesting land deals or consolidation deals we make in the six, seven, eight figures annualized. Most of our deals start small and they grow, and we tend to have very efficient sales thanks to that. The one thing that we're doing today that is a little bit different, it's a new sales motion we're adding, is that we're adding some overlays for selling security very specifically to the CISO, because that's not the muscle we had before. We find that it's a little bit different enough to warrant a slightly different team to handle that. That's specific to security, to a CISO in the largest enterprises. By the way, maybe talk about that a little bit, like why is security such a natural part of what you're doing? Obviously you have security vendors that are also making some acquisitions into what look like competitors in your space. How do you see that playing out between your role in cybersecurity and what some cybersecurity vendors are doing? Yeah, look, at the end of the day, the thesis we had when we started the company that you should bring DevOps together, also extends to security. It doesn't make sense for security to be separate. The teams should work well together. They should speak the same language, achieve the same roles. We see this accelerated by the adoption of AI, where you'll have the same person basically having to wear many hats and care about security as well. We think that that bottom-up adoption from the developers and the ops people, is going to reach into security, and is, in the end, it's going to become much more of a bottom-up motion than a top-down motion in terms of how that adoption is taking place. From a technical perspective, most of the signals you need to secure an application, you get in observability. You have everything that happens in production environments. You have everything that happens on the way to production in the code, in the testing environment. You have the behavior of the end users. You have the behavior of the developers. You know exactly who's changing what, when. All of that is the information that you really need to feed into those security models, and we're uniquely positioned to get that as well. We went down the path right now of some of the expansion opportunity, the organization, and the commercial motion and why that's really helped you be successful. I think you pointed out there's the other side, which is AI for Datadog. While it's still relatively early, there's kind of several investments that you're making there. Everything from the Bits AI agent to some of the new modeling stuff with Toto that you guys are doing. Maybe help the audience kind of understand some of those things that actually can add incremental value, reduce the human time, add more predictability that you guys can do. Yeah. The high level goal there is to automate, right? To do more than observe and to really automate. One thing a lot of our customers go through is, they use us to observe and monitor the applications, and something breaks at 3:00 A.M. We wake them up. Then they start a Zoom call with 20 people on it that lasts three hours from 3:00 A.M. to 6:00 A.M. The site is down, the business is upset. You can imagine the thing. It's very costly. Yes. Very costly, very disruptive, not anyone's favorite part of the job. There's a huge opportunity to automate there. It used to be fairly hard to do that, but with the new technologies in AI are really opening doors that were just not quite available before. What we do today is we have products on the operation side and on the security side that do that automation. We have a Bits AI, that's the name of our AI, Bits AI SRE agent, and our Bits AI security agent. What they do is they run investigations for you. For example, in the case of the outage I mentioned earlier, instead of having a three-hour Zoom call with 20 people on it, four minutes into it, you get an analysis that says, "Oh, by the way, I found out what was broken. This is what it is. These are the three people who know how to fix that. This is the fix I propose. Should we do it?" That's already life-changing for those customers. Typically, this is the way they see it. They turn this on, maybe they forgot to turn it on, they get this incident, they get onto that long Zoom call. After the Zoom call, they look at their notifications, they realize, "Oh my God, four minutes into it had it already." That's the light bulb moment for them, they start pivoting to that. We have a similar agent on the security side that does security investigations, and there, the focus is mostly to cut the noise out. The teams that do security response have tons and tons and tons of investigations to run. 95% of them, or more even, are just benign. A big part of the job there is to make sure to get to the benign ones super quickly so they can focus on other things. We do that as well. That's what we do today. If you squint, you could say, some of that you could also do from, actually you could use Claude or GPT-5, and you give them OMCP tools to query the data, and maybe they can come to the similar reasoning and come to a similar conclusion. The next level of what we're building, though, is about having that intelligence directly inside the data plane, with all of our real-time data, and to drive the automation itself. Yeah. Models that are specialized that can run on very large volumes of data at a very attractive cost and with very low latency, so we can fully automate the operations there. There is some first outputs of that you can see. We published two versions of a time series model, like a foundational time series model, which is called Toto, and you can look for it online. This model is very interesting because it is a model that was trained on observability data almost exclusively, but that generalizes very well to other types of time series. It is state of the art across domains, not just for observability. It is actually really good at weather forecasting, even though it was trained on mostly application observability data. What's also exciting about it is that it's a model that scales, meaning that you can train a larger model from the same dataset, with the same architecture and even the same hyperparameters, and you end up with higher performance. That's not something that had ever been achieved in time series models before. It had been achieved very famously in language models, starting the most visible case of it was GPT-2. We know what happened next. I think we start to see the same opportunity with these models. Now we're busy basically extending those models beyond time series. When I say time series, these are mostly timestamps and values. We're extending that towards including the rest of observability data, whether that's logs and traces and application topology and network data and user data and all of that stuff, so we can really fully model and be predictive on our customers' infrastructure. The idea there is, if we build that properly, we can automate a lot of our customers' operations. I think the point being that an LLM is designed to represent human language. Yeah. It's a semi-structured set of data that you would love to have a model like an LLM, but now this is a machine learning model optimized for that. As a result, its performance is much better than you can ever get out of LLMs. Yes. Also, these are very different types of data. LLMs are very bad at time series, for example. Even though the models are transformer-based, and it's deep learning, transformer-based, so a lot of it is similar, but the architecture of the model is actually fairly different. Yeah. Well, LLMs don't understand ordinality. Yes. You need a model that has that as a structure of it for this to work. It can be different ways. We can obviously go much deeper on some of these things, but before we run out of time, I think it's also important to perhaps reflect on some of the deployment model flexibility that you've been providing customers. It's almost exhausting when you think of the level of innovation you guys have been able to put out. I think that you could probably help us reflect on, from a buyer standpoint, one of their frustrations when they're forced to have a single deployment model that may not be ideal, whether or not it's for data residency or credits they already have. So maybe help us understand some of what you're doing with Bring Your Own Cloud. Yeah Some of these models. Yeah. Just to zoom out, customers in general, they face just an explosion of the amount of data and applications and everything, right? In observability, there's a perpetual quest for efficiency and making sure that what you spend on measuring, auditing, operating your application remains predictable and within range of what you were expecting. For that, there are three core mechanisms. One is you need to have a feedback loop that lets you understand what you're consuming and what's valuable and what's not, and what you need to do more or less of. That's something we built. A big part of our product is making sure that the right people have the feedback loop, and the people who care and who capture their information see exactly how much value they're getting out of it and how much it's costing them. That's one part. Another part is to get ever smarter on how much of a sample you need to understand the data. That goes back to all the smarts we're building, the models, et cetera. The third part is to keep innovating on how efficient you can be at storing and querying and managing that data, and all the various topologies you can employ to make that work for various customers. On that last one thing we started doing last year, and we see quite a bit of demand for and we're accelerating on, is we're doing some what we call Bring Your Own Cloud options for our customers to deploy our product. Meaning that they can store the data on infrastructure that they manage themselves, even though we still run and update the application for them. The reasons for that are, obviously, cost at large scale is one of them. If you have petabytes of data, that's something that you probably want. Other reasons would be data residency laws, and we see that the world in general is fracturing into smaller zones as opposed to one big zone, so we expect a lot more of that in the future. Even though today it's still an afterthought for most customers, we expect that to be more front of mind maybe in one, two, three, five years. It's hard to tell when exactly. The last reason might be that customers, maybe they have a large data center they already built and they want to use. Maybe they have a large commitment with a specific cloud provider, and they want to use what they've committed already for that. There's all sorts of reasons why customers might want to control more of the deployment there. Historically, we had focused on being purely SaaS. There were a few reasons for that. One is, I mentioned earlier, we thrive on being product-led and product adoption, meaning it's very important for us to be able to iterate very quickly and also to understand what customers are using and not using, and what's valuable and not valuable. We never offered an on-prem version of our software early on for that reason. We thought it would be a huge tax on innovation, and also it would make us a lot dumber in terms of how we build product. We've seen that play out. Most companies that start having a product that has some success in the enterprise get offers they can't refuse early on of building on-prem versions of their product. That's usually a great idea in the short term and a horrible idea in the long term because those companies end up slowing down immensely after that. The way we built this technology now, this Bring Your Own Cloud, allows us to have the best of both worlds because we still manage and run and update those applications and meter those applications. At the same time, we can run a data plane fully within control of our customers and on their infrastructure. Between this and some of the stuff you guys have done with FedRAMP, perhaps this even leads to some of the opportunity you could see the scale around, because if I look at many of the other software companies I cover, somewhere between 7% and 15% of their revenue come from federal. I think you guys are, if David's comments earlier were accurate, closer to 1%. Yeah. You could see even just on that one customer category, the type of revenue opportunity that it opens. We only have a couple minutes left. You talk to a lot of investors. You talk at a lot of these different events. What do you think the most underappreciated aspect of Datadog's forward-looking opportunity is? There's really two halves to it. One half is the world is exploding with AI right now. This means so much more stuff, so much more complexity, so much more infrastructure. We see that play out with the large AI natives today. That's going to come to the rest of the market. That's a huge opportunity for us. If there's only one category that remains, I know everybody here has been debating is software ever going to be worth anything ever again? Yes. Yes. Well, the answer this week is yes. If there's only one category that is left in the world, it's observability. Because the one job that remains for us humans is to control the machine, understand what it's doing, understand whether it's delivering the right outcomes, how much it's costing, and whether the intent of what we want it to do is actually what it would get performed in the end. I think that's a huge opportunity for us. There's a lot to build there. It's a challenging market because it's changing really fast, so there's that muscle we built on product innovation, I think is going to be brought to bear, but we see that as huge opportunity. The other half, the more boring half, is that all of that is driving the need for standard observability. Those large AI companies are consuming large amounts of infrastructure and applications in the same way the other companies are. As I said earlier, we have less than 14% of that market, and that market is growing. It's going to grow faster, I think now, as you see these huge CapEx investments in infrastructure in general, and it's not just GPUs anymore, it's GPUs and CPUs and everything else, as these agents need to use tools. I think that part of the business, the boring, the existing part, the part that's not new form factors, new applications, new anything, that part has another five or 10 X into it, and that's very exciting. Well, you heard it here first. The only business that will remain after the robots take over everything else is observability and Datadog. Make sure that you're ready to be an SRE in your future. Olivier, thank you so much. I really appreciate you taking the time here and sharing with the audience your experience and where Datadog's going. All right. Thank you.