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

Hi, everyone. Thank you for joining us today. We're fortunate to have Janesh Moorjani with us, CFO of Elastic. We have no shortage of material to discuss in the next 45 minutes, but please feel free to submit questions to the tool, be happy to work those in. So Janesh, welcome, and it's great to see you.

Yes. Great, Kingsley. Thank you for having us.

So yes, we'd just like to start out with just sort of a broad overview. Just maybe for some generalists, Elastic's identity is very clearly as a search company. And your core search technology has found different use cases over time. If you could just provide a little bit of a vague overview there.

Yes, I'm happy to. So as you said, our roots are in search, and we always prided ourselves as a search company around the ability to index large volumes of data and ingest those and index them and then return near real-time search results on those. And search starts to find the application in so many different use cases, whether you think about things that you experience as a consumer where you're searching on large pools of data, where it could be you're searching for something on Wikipedia, you're searching for something on -- you're searching for a restaurant somewhere, you're searching for another human being in a dating application, all the way to enterprise buyers and to business environments where there are large pools of data being generated, whether it's in the areas of logs or APM or security events. So as a general search, as a general-purpose search tool founded on this power of technology, we also had a free and open distribution model. And so we started to get users that were adopting us for all kinds of creative use cases, not limited to the way people traditionally used to think about enterprise search. And sure, in the initial use cases, folks thought about us as putting a search box on a website. But through the examples I gave you, you can see that search is so much more than just a search box on a website. And along the way, people started to use us for logging and said, hey, if I ingest my logs into Elasticsearch, I can start to analyze my logs there and it could be a great set of outcomes. And the same for many other use cases as well. So because we are so close to the community and because people would use us in these creative ways, we started to see certain patterns and trends emerge. And we wanted to make sure that in our history as a company, we didn't get boxed in into any one particular category, but really that we could as core search capability to be relatively extensible across different kinds of use cases and solution areas. And so folks are to use us initially for enterprise search and then for logging. And along the way, we also started to see people increasingly start to think about areas like monitoring and security and even APM. We acquired a company several years ago that had some APM tools, which we then built natively into the Elastic Stack. And we are only limited by the ingenuity of our own users in terms of how they would use Elastic. But as we started to see certain trends emerge, we started to see certain use cases are more popular than others. We also recognize the need to continue to give users and to give our customers the benefit of capabilities that they would get from purpose-built solutions in those areas. And so we started to focus really on 3 main solution areas: enterprise search, observability and security. And enterprise search for us includes the way people would traditionally think about search, whether it's searching in an app or a search box on a website in the form of site search and also just searching through core enterprise data with our Play search product. And with observability, it covers the pillars of observability that now are widely accepted as the 3 legs of observability, which is monitoring and APM, and of course, logging. And then on the security side, as we continue to get used in ways where customers were using us to solve security problems, it became very clear to us that, that people were effectively trying to use us as a SIEM tool. And so we went ahead and built our own SIEM functionality for our users and customers. And we launched that a little over 1.5 years ago, I think. And then about a year -- a little over a year ago, we also acquired Endgame, which is an endpoint security company, and we folded endpoints into the stack as well because we saw this future where endpoints and SIEM would come together because the value is in the underlying data, which needs to be stored in a data store. So for all of those reasons -- and that's been the journey that we've been on, just staying very close to our users. The free and open model that we have allows us to listen to our users much more closely than you would otherwise expect, which makes for a much more efficient R&D model as well from the standpoint of not having stranded development efforts out there. And so that's how our journey evolved from using search for a variety of use cases to focusing on these 3 specific solution areas.

That's an amazing overview. Thank you. So just to touch on the sort of the enterprise search area. It's where you began, it's where many customers have originally found Elastic. I think observability itself drove a lot of growth in the business. So where do you see that enterprise search market today? And is there something that you think could happen that would catalyze its growth further?

Yes. I think enterprise search is a really exciting opportunity set for us. As I mentioned, it encompasses app search, site search and workplace search. And particularly, when you think about the volume of data that's getting generated now, that finds application in those enterprise search use cases, it's pretty extensive. So if you think about in the effects -- given the effects of the pandemic, we've seen a significant increase out there in terms of just e-commerce and more people buying things online. All of those shopping cart experiences, those online buying experiences, they're powered by something. Because when you first go on to a website to buy something, what do you do? You search. You search for the product you're looking for, you search for the service you're looking for. And it's not just about that finding that initial product and then putting it in a shopping cart and checking out. But that entire experience needs to also then be monitored at the back end to make sure that your experience as a consumer is exactly what the seller would want it to be. So it actually extends into some of the other solution areas as well. But that's been a great story for us. And then on the workplace search side, it's something that we're actually really excited about. If you think about the volume of data that's getting generated now in the workplace, it's significantly more, particularly with people working in a distributed way or in a remote way, it's significantly more than what it used to be several years ago. And voice conversations are not searchable, but these kinds of interactions that happen online are searchable. With workplace search, what we also did was launch the ability for our customers using a single search box to search across multiple different SaaS assets. If you think about how enterprise content has evolved, many, many years ago, decades ago, it used to be that all the content of the enterprise used to sit within the 4 walls of the enterprise. But as SaaS solutions and SaaS-based applications have become much more popular, so much of enterprise data sits outside of the 4 walls with an enterprise. And to be able to search across all of that data with a single search box, whether you're looking for content in Salesforce or Dropbox or across a hosted e-mail offering somewhere or across developer tools like Jira, across workflow tools like ServiceNow, all of that becomes incredibly valuable to be able to search across all of that with a single search box. And it's not a trivial problem to solve because if you think about your own role, you've got different personas in each of those applications. You've got different privileges. All of them have different APIs. There's different response frameworks that they all use. And so if you think about the complexity of that problem, to be able to simplify all of that into a single search box, it's incredibly powerful for our enterprise customers and commercial customers who want a workplace search solution.

Right. I think you have the versatility of the search. It -- just in your standing, like workplace and app is something that is truly differentiated. So I think what is not necessarily well understood by every investor is just kind of the dynamic path Elastic could take through an organization just to build as with a -- to build their usage. So I mean I guess it could happen a number of different ways, but could you provide any high-level trends and how it might move across buying centers or grow maybe as they adopt security or adopt -- observability on top of search?

Yes, it happens in a number of ways. So it could be from enterprise search to observability or security. It could be from observability or security into some of the -- into one of the other solutions. In the case of enterprise search, I used the example of that shopping cart experience. And it's not just about searching for the product on the website, but also about monitoring that experience and looking at the logs that are getting generated. And then if your experience is what you'd expect it to be, then why is that? And that starts to move more into an observability related use case. I'll give you another example where somebody could be deploying us for logging, and they could be analyzing large volumes of logging data as well as attendant with that APM traces or infrastructure monitoring -- the data from the infrastructure and using that for monitoring. They could be using us for observability, but if you think about the importance of making sure that, that data is secure, every log is also a security event. Because when you have a security breach or when you have a security event that you want to go analyze, what do you do? You go back and analyze, among other things, the logging data. So when companies start to import a lot of data into their SIEM tools, very often, those SIEM tools that they're importing data into is logging data. And so you start to see these lines start to blur, where does logging end and where does security really begin? And so if you think about it from that perspective, what we did with our security solutions is we made every developer threat hunter. Now every one of them has the ability to also use the security tools that are available in Elasticsearch as part of our security solution in the Elastic Stack and go ahead and use that even if they are deploying us for an observability related use case. Even in the industry, you start to see this movement towards this concept called DevSecOps, which previously used to be just DevOps, which in itself is a relatively modern movement. But going from the idea that if you develop your tools, you are also responsible for running the tools as in DevOps. Now the concept is if you're responsible for developing the tools and running the tools, you can also play a key role in making sure those tools and the underlying data is secure. And so we start to see those barriers start to break down a little bit. So very often, people who start with observability will extend into security. And in many instances, it's even hard to put a label on something and say this is observability or that security because it has shades of both.

Yes, exactly. Yes. I mean we've seen recently that it's not only something that you can do, but it's becoming more imperative than if security's an afterthought. It's not a -- it's sort of a broken model. But just, I guess, a little bit on the types of buyers that may be exposed to the product and how they react differently. Or is there a typical number of buying centers that may emerge in an organization you found, maybe it's like it's 3 or 2, depending on the revenues [indiscernible]?

Yes. I think it can vary quite a bit just based on the nature of the organization. We've got some very large customers, Fortune 50 customers, Fortune 100 customers. They have highly decentralized IT organizations, highly federated system. So a person in division, A will be buying something from us, and that person is responsible only for division A and how many other divisions they've got. There's that many buying centers. Some of the larger enterprises that we engage with also have what I'll refer to as centers of excellence, where it's one buying center that buys Elastic and then deploys it. And internally, within that enterprise, makes it available as a service to their respective divisions or departments. And we've seen that model with some very large customers as well. If I think about the core functionality around enterprise search, observability and security. In the past, the security buying center has been different with the office of the CISO, focused on information security and the infrastructure, apps by -- being in a different part of the organization but usually also reporting after the same individual at the group level. So we've seen some of that in the past, and I think we have the ability to extend into those areas. What's really important to understand about our sales motion is that very often when we engage with a customer, it's already a very warm relationship. We're helping them connect the dots because it's the free and open distribution model. People download the product. They're familiar with the product. Our salespeople typically don't have to explain features and benefits of a product to a customer. And because of that warm relationship that already preexists, the nature of the conversation is much more about how do you translate that into a commercial relationship. And given that before our sales people are very often the ones helping customers connect the dot, letting them know that their peers or their colleagues in a different group are also using the product. So I think that bottom-up adoption model has served us really well in that regard. As we move forward, it's also incumbent on us to continue to build capabilities that allow us to call higher up within the enterprise. And that's been a focus over the past period of time where we've continued to hire and build those capabilities as we move further up into the enterprise by organization. And I think that's been working really well for us. And there's more work to be done on that front, but that's working really well for us so far.

That makes sense. And would you describe those as more of mimicking like traditional enterprise software sales? Or it's sort of a -- sort of like an expansion of the type of model that you already have, with a focus on customer success and driving use case across different departments?

Yes, it has flavors of both it. The bottom-up motion allows us to be a lot more successful within that customer's environment. But certainly, when you're having a top-down conversation building relationships for the first time at senior levels, there is a fair amount of work to be done to build those relationships, to help translate a technical conversation into a business value conversation, to continue to establish relevance and help people understand why they can get significant more business value from Elastic than they can from alternatives that might be out there. And I think we've started to see that happen quite a bit. And we've seen some very good signs of that as we've continued to move further up in the enterprise. I'll give you an example. We talked about, during the course of this fiscal year, we've had pretty good execution, I would say. We've been proud with the way the sales team has executed despite a pandemic. And we've been quite transparent about the headwinds and tailwinds we've seen where there's broad pandemic related headwinds. But then as customers are also looking at the composition of their spending and shifting their spending around and focusing on digital transformation efforts, they're shifting spending towards areas where our solutions are very well positioned. And our sales team has been able to help customers see that value as well as close those transactions in a timely way and deliver that value to the customer as well as back to Elastic. So that's a great example of how we continue to explain and establish business relevance and help customers see that, and it's helped us from the standpoint of execution here in the last few quarters.

Great. That's really helpful. So we keep touching on open source, but there's a lot to go into here. I mean, I noticed you've changed your licensing a few times over the years, but more recently, made another change to help protect your own IP against some other cloud providers that had been sort of hosting it as their own product. So could you -- I guess, could you provide a brief overview of how this protects the best interests of your existing customers today and how it can just help you grow as a platform?

Yes, happy to. So the change we announced, I think it's important to sort of step back in time a little bit. A few years ago, 2 to 3 years ago, the way we used to go to market and what we used to sell, we always prided ourselves in having this free and open model. But what we also recognize is that when -- typically when customers think of open or free or users think of open source or free, there's really 4 attributes that they are thinking of. One is, is it in fact free; the second is, can I inspect the code and play with the code and look for security bugs or just understand how it works; the third is, can I have the same rich interaction model with the developers who wrote that code and learn more about it and get advice on how to deploy it if I need that advice; and the fourth is, what's the licensing mechanism that covers that software. And as you think about those 4 elements, 3 of them directly pertain to value and what are relevant to people. And what we decided to do is give users the benefit of all of those aspects, but put it under a proprietary license. And that was when we started to expand our -- what we call our basic subscription tier, which is proprietary but free. So it's governed by a proprietary license but it's a free software, free download. By the way, I will qualify that in the world of cloud, in the world of SaaS, nothing is free beyond a 2-week trial. Every bit and byte is monetized in cloud. Even things that are downloadable for free when you deploy them in SaaS, you pay more than the underlying hosting cost of the infrastructure. So we monetize that in the SaaS world. But we started to expand that swim lane quite a bit with the goal of making sure that we continue to widen the competitive moat and give users the value for those that they had come to expect from Elastic in that free tier but making sure that the intellectual property is protected by a proprietary license. And we call that licensee Elastic License. And now what we did in January is as we've widened that competitive moat sufficiently, when you think about the last development -- the development in the last 2 to 3 years, most of the capabilities that we've got in the solution areas around core elements of value that customers or users derive, that's all covered by a proprietary license. More than 90% of our downloads were our default distribution, which was that proprietary Elastic License. So only less than 10%, so call it single-digit percentage of the downloads versus traditional pure open source downloads. And so the change we made now was to say we're no longer going to publish the open source distribution but all of our future development will be governed by 1 of 2 licenses at the user's choice, either the existing Elastic License, which the vast majority of our users and all of our customers are already used to because we're all on that Elastic License anyway; or alternatively, there are some folks that in the industry that have gotten comfortable with a different proprietary license, which is called the Server Side Public License or SSPL. And we said, hey, if you prefer that, no problem. We're good with that too. You can license the software under SSPL if you prefer. So we gave customers and users the choice around that. As part of that change in terms of what effects we expect that to have going forward. So I'd say, first off, the immediate change was actually very little because the goal of making that change was, as you mentioned in the question, was to prevent cloud companies from taking our software for free and then turning around and deploying that as a service without contributing back to the community or without letting us participate in those economics. And that's the primary restriction that exists in the Elastic license and effectively in the SSPL as well. There are a couple of more minor things. But generally speaking, these are very permissive licenses in favor of the customer or the user. So that was the primary goal. And sure enough, as we expected, Amazon, in response, said that we're going to fork the branch from the open source version as it existed, and that's perfectly fine from our perspective. Because over the last few years, as I mentioned, we've widened the competitive moat so significantly that we think that we've got pretty significant advantage out there from the standpoint of features and functionality. The other thing that Amazon said is that they're going to stop calling their product Elastic Search, which, again, is just fantastic from our perspective because it avoids any confusion in the marketplace where people might think that they are getting the fully featured Elastic Search service. And now they'll at least be aware that what they're getting is not fully featured. And if they want the fully featured service, they have to come to us. So I think over a period of time, I see this generally being a good, solid tailwind to our cloud business, but I do see it paying out over a period of time.

Yes, definitely. So you mentioned the 4 criteria that sometimes could define what buyers view as open source or what developers view as open source, with the fourth being licensing. And so I think it's either the Elastic License v2 or SSPL. So I'm curious, say, that they're not open source -- and so I guess just in terms of a label, is that -- how are you embracing that or navigating that just as you grow as a platform?

Yes. It's a great question. I mean, look, first off, there'll always be the noisy minority that believe that open source is almost like a God-given right as opposed to part of a commercial or business model. And they are certainly entitled to their views. As I said, when we made the change, none of our customers were affected because they're all covered by an Elastic License anyway. Over 90% of our users who downloaded the product were not affected because they download the default distribution anyway, which is governed by the Elastic License. So you have the noisy minority. By the way, the other thing that just sort of happens is natural selection bias, right? If you think about the vast majority of the people for whom this was a complete nonevent, you wouldn't see them reacting. It's only the few people that feel strongly enough about it will go make a noise about it. In any event, I think that happened for a little while on Twitter, and I think that -- and maybe other social media or other websites. And I think that's behind us. In terms of users and customers and partners. I think, generally, everyone has been incredibly supportive and to a degree, then even celebrating the change. So I think that's actually worked quite nicely. We feel pretty good about continuing to stay with our messaging to our community and our promise to our community that a portion of the software will remain free and open. It is free, and it is open. It's not open source, but the code is open and they get all the benefits that they would want to. But they understand and appreciate the importance of us having the licensing protections that we need, while continuing to give all the benefits that they would traditionally have on their open source to do them, to customers and to users. So I think it's actually worked out quite nicely. And we define ourselves based on that free and open model that we have, and I think that continues to work quite nicely for us.

That makes sense. I'm curious on just sort of the thinking behind the timing of the change because I know that this has been a central portion of Elastic forever and still is in terms of its -- the licensing of its main products. So was it a decision that you think that you're at the right scale and that it's the -- you have enough support from your customers as well as achieve enough growth existing? Like in the past that you -- this is the right decision to make now? Or just curious about your thoughts over the past few years into what went into this licensing change.

Yes. I think from a timing perspective, we always knew we could make the change at any time. The question was when should we make the change, and we wanted to make sure it was a time and place of our choosing when we felt that it would be the right time from the standpoint of having given ourselves sufficient room and having customers and users feel comfortable with the change. And that's why when we opened the code a few years ago and started to expand the swim lane even further, I think our progress over the last 2 to 3 years has given us a lot of confidence, both in terms of the comfort that our users and customers have with downloading the proprietary version and the acceptance of the Elastic License as well as the widening of the competitive moat, as we continue to invest in features and functionality for Elastic with respect to the proprietary capabilities that we've built into Elastic that gives us significant long-term competitive advantage. So both of those things went into the decision. Could it have been some months sooner? Could it have been some months later? Yes, it could have been. These things are always a continuum. As I said, it was always a question of what's the right timing for us and for doing it at a time and place about choosing when we felt that we had the strength of the community with us as well as the strength of the feature differentiation.

Right. Yes. No, I think the timing seems attractive. I guess, in terms of the -- where we are, like as an industry or just software companies that use open source business model or like distribution models compared to 20 years ago. I mean, you've been a pioneer with your own model with, I guess, Elastic License v2, and Mongo has worked on SSPL. Do you think we're at a position where it's more sustainable to build open source business today? Like we've solved some problems with the licensing models. And then how much do you think that this is like still a ongoing work in progress?

Yes. I think the -- to your point, the industry has evolved quite a bit. And I think companies have -- like Elastic and like a number of other companies, have figured out ways in which they can give immense value to the community and to our customers and scale businesses, while also building a strong commercial business model on top of that, and licensing is one portion of it. I think the existential threat to open source used to be the public cloud providers. But I think they've also generally evolved. And you've got some great companies like Google and Azure and some of the other large cloud providers that are more regional players. When I think about our partnerships in China, for instance, in all of those cases, we partner very well with those companies, and they've continued to build great businesses for themselves, and we've built a great business together with them. And so we certainly see the scope and the opportunity for the partnership. I think the industry has evolved to accept that, and that's all actually worked to the advantage of customers and users. From time to time, you might have folks that try and extract value without contributing back to the community. And I think whether it's through licensing mechanisms or other market mechanisms, I think that corrects for itself. But that free and open distribution model, which I'll distinguish it's a distribution model, it's not a pure business model because we do recognize the need to have commercial features that are paid for and monetized, I think that's here to stay. And again, I think I mentioned this earlier, but -- when on the cloud side, all of those features are still monetized. But the price point for any of the features that are distributed for free, when those are deployed in the cloud, is more than the hosting costs underlying that. So there is a monetization of that, that happens in the cloud regardless.

Right. Yes. This is -- I have a question just is kind of maybe more theoretical, but -- about what's fair in open source. I mean AWS would -- like they'll use open Source products. They do contribute a relative amount back to some of these projects, yet they're one of the largest companies in the world. So it seems to not be completely black and white issue. I mean, do you have any thoughts on what makes open source, like, I guess, fair in some cases? Or is it really just that -- not necessarily, but that it's right for your business to pursue your own interest?

Yes. I mean, look, I'll go back to what I said earlier. We think about free and open as a distribution model and recognize the need to have a powerful business model on top of that. I don't -- personally, I don't feel like it sort of matters in terms of where you draw the specific lines in open source and all of these conversations about what should be or what shouldn't be and should software be free and should software not be free? Our focus is on making sure that number one, users and customers get significant value; and number two, we can build a sustainable business on top of that. The rest of it is a little bit of a distraction. So does Amazon contribute enough back to the open source community or not? At one level, it's an interesting theoretical discussion. But from my perspective, I go back to those two key questions: are we giving enough value to our users and customers; and are we building a powerful business model on top. And I think the changes that we made allow us to do both of those things.

Absolutely. I agree. I think it's a distraction in some ways. So sort of relative to open source. You recently announced a partnership with Grafana Labs. It was a joint plug-in. You had a longer history with them, the sort of forking off of Kibana. So I guess, it seems like the development of the plug-in itself was preliminary or just relatively limited. So do you see more strategic partnerships in the future? Or like growing more development efforts with Kibana?

Well, both. We've always been open to partnerships on all fronts. And to your point, what started off as a fork of Kibana, I think they've done some really good things with the visualization capabilities there. And we want to make sure we continue to give our customers incredible value. The underlying value of Elasticsearch is in the data. It's in the data that's stored in Elasticsearch. The data store is where customers see a lot of value. That has a lot of gravity to it. That's what we monetize when we talk about the resource footprint. And so giving customers the best tools to be able to leverage the value that sits in their data is, again, just a core underlying philosophy around what we do. Some folks might prefer Kibana. Some folks might prefer other tools. Folks can build custom tools on top if they want as they look at the data in Elasticsearch. So to us, it's more about giving customers more choice and giving users more choice. And so we're certainly open to those kinds of partnerships. And we've demonstrated that also in various other ways. If I think about our cloud business, we've got deep partnerships with Google and Azure. For us to partner with Google as a search company, and for them to endorse us as a search company for the solutions that we offer, it shows you how when folks think about the customer journey and the customer value in the right way, you can build some really good partnerships in all of these different areas. So we're always open to that.

Great. Okay. That makes sense. I want to touch on the searchable snapshots. I think as you said before, just the significant data presences that these customers can have. And sometimes, they've been forced to make tough decisions about what data they can observe in one platform and what they can't. So I guess, like as an overview, like what is -- is this more enabling customers to put more data into the platform in terms of expanding spend? Or is it sort of just increasing customer retention? What other things does it enable for Elastic besides necessarily just increased spend?

Yes. I think searchable snapshots is a really powerful feature because it allows customers to store so much more data and make it all searchable. And the power of searchable snapshots was that because they can now search across data that's sitting in cold storage, sitting in AWS S3 or other cold storage or optic storage, it becomes -- it reduces their total cost of ownership on the infrastructure side. And what we've seen in the past is when you bring that cost point down for them, that they tend to store more data rather than less. And those reductions in TCO, by the way, are all on the hardware side, nothing to do with our software. In fact, if anything, customers will spend even more with us on the enterprise subscription tier rather than less. So for us, it was about making sure that customers actually get significant value. And that they can continue to do -- store more data in Elasticsearch, while continuing to do that in a way that's effective for them in terms of their cost points. We've seen this playbook before. So it's actually -- they tend to store more, they can get better outcomes from that data. It plays more directly to our advantages in terms of our speed and our ability to search very quickly in your time across these very large data sets. So from a competitive standpoint, it starts to create differentiation on us as well. And I think it just sets us up really nicely for the long run. Also, searchable snapshots is only in the enterprise tier. So for our customers who are on gold or platinum that want that capability, they would have to upgrade to enterprise. So it drives a nice motion there, too.

That's a good point. So yes, in terms of the pricing and spend. Would empowering customers with a slider bar of different SLOs or just like a bill -- price per cold tier or frozen tier or warm tier, does that make them more cost sensitive? Or is it really just -- it's -- as you're saying, it's like Elastic increase in demand that will generate more revenue?

Well, I think different customers will approach it differently. What we've generally seen in the past is that because data is growing at such large rates, and it's almost growing at exponential rates within the enterprise. And as customers see the need to correlate data from more sources to get better outcomes, so it's not just the volume of data growth from a particular source but also ingesting data from more sources. Far too often, they let data drop on the floor because they don't have a place to put it. And so helping them with that just gives them the ability to actually store a lot more data in Elasticsearch. If I think about going back, call it, 5, 6, 7 years, when people started to first use us for logging, the reason they were using us for logging was because they were -- the alternative tools that they had were too expensive, and the data was falling to the floor, and they didn't want the data to fall to the floor because there was value in the data for them. So as long as you believe that there's value in the data and as long as you believe that the data has gravity, customers will want to store more data to extract more value from it. And that's why we think that, that playbook in the future will repeat itself, whereas there -- as customers have more power to choose between whether they store more data for the same price or whether they store the same amount of data for a lower cost, we think that, generally speaking, the way the industry will evolve is that people will store more data for the same price point. And again, from our perspective, I'm really happy to be at a point where, as a company, we are agnostic to that. If a customer wants to reduce their spending on infrastructure by paying Elastic, I'm fine with that. If they want to search more data by keeping more data in Elasticsearch and spend the same money that they did earlier. I'm fine with that, too. Both of those play to our advantage.

Great. Let me try to fit maybe 1 or 2 more in. But -- so there -- we talked about AWS, but you're great partners with Azure and Google. We're also just seeing, in general, partnerships across the space deepen from being earlier product integrations to now including things like -- billing integrations are also joint sales initiatives. So I guess, where do you see public cloud and the observability space interplaying over the next like 3 to 5 years? Do you think public cloud could become more of this procurement platform where more spend flows directly through them initially before coming to an observability company?

Yes, I think it will actually be customer-led. In many instances, customers have a certain preference, and they may prefer to buy through a marketplace or through one of the public cloud providers because they can use that as an opportunity to meet commitments that they are making to the cloud providers as well as commitments that they are making to us. In many instances and just depending on where customers are in their journey and pricing differences and so forth, people will prefer to buy directly from us. And when I say directly from us, they'll still go host it on that same public cloud provider. Because the deployments will tend to be wherever the apps and infrastructure reside. If you're generating a lot of logging data from applications that are running in Microsoft Azure, you're not likely to go deploy Elasticsearch or whatever tools you use for logging analysis and GCP. You're likely to deploy them in Azure where your organization sits now. You could do that by purchasing that directly through Azure or you could purchase it from Elastic, and we'd be hosting it on Azure. Or in some instances, folks prefer to download it and manage the software themselves. And they will still deploy it in Azure in that example, but they prefer to manage the software themselves rather than having a managed offering. So our promise to customers is that we'll be there for them wherever they are. And we focus on building all of these different routes to market so that whichever path the customer chooses, I think it works to our benefit and where the -- will the industry move towards having a more heavy predominance towards 1 route to market versus the other? I think that's harder to predict. My sense is that it will really be dictated by customer preferences more than anything else over time.

Great. I'd like to ask more, but I think we're about running up on time. So Janesh, I really appreciate you joining, and it's been a great conversation.

Yes. Thank you, and thanks again for hosting us. We appreciate it.

All right. Thank you.