Hi, everyone. Welcome to Current 2022 in our investor session. Before we begin, I'd like to note that during today's program, management will make forward-looking statements, including but not limited to our business, strategy, customers, technology, market opportunity, products, growth, and future prospects. These forward-looking statements are subject to risks and uncertainties, which could cause actual results to differ materially from those anticipated by these statements. Further information on risk factors that could cause actual results to differ is included in our most recent Form 10-Q filed with the SEC. We assume no obligation to update these statements after today's program, except as required by law. Please also know that management will not provide financial updates during today's program due to our earnings quiet period. For planning purposes, we're scheduled to announce Q3 2022 financial results on Wednesday, November 2. Please save your financial questions for our earnings call. With that, let's begin today's program with a quick video. Life happens in real time, and so does data. Consider for a moment this scenario. Ordering a rideshare, then monitoring the progress as the car makes its way to your curb. You know to the minute when to step outside. We all take these experiences just like it for granted. Experiences enabled by a storm of data, processed and then presented all in real time. It hasn't always been this way. In fact, even today, most data is collected, stored in centralized databases, and then batch processed on the hour, day, or week. Imagine how some businesses could be transformed with real-time processing of live data streams or what we call data in motion. Finding patterns and responding to significant events as soon as they occur can allow banks to create personalized solutions that help customers meet their financial goals. Sound the alarm on cyber threats before they become massive data breaches. Alert supply chain managers of unanticipated stock depletion. Accelerate clinical trials, bringing critical medicines to market faster. There is no limit to the application possibilities, and it's not as hard as you think to transform from batch processing to real-time data in motion. Let Confluent show you how. Welcome to the stage Steffan Tomlinson, Chief Financial Officer. Hi, everyone. I'm Steffan Tomlinson, Chief Financial Officer of Confluent, and I'd like to welcome you to Current 2022, the Investor Track. Thank you very much for coming. We've been a public company for about 15 months, and we've had extensive engagement with the investor community. Based off of that engagement and feedback, we've created a set of material today that addresses a lot of the biggest areas of topics and questions that folks have regarding Confluent, and we're really excited to get into the programming. Today, Jay Kreps, our co-founder and CEO, will be discussing the data streaming era and all that it means and why it's important and how big it is. Jay will be followed by Chad Verbowski, Senior Vice President of Engineering, and Chad will be covering the data streaming platform, the key differentiation points, TCO, and other things. After Chad, Erica Schultz, our President of Field Operations, will be capturing how we're attacking the overall market opportunity in our customer growth go-to-market journey. We'll convene for roughly a 10-minute break, and when we reconvene, we will have an executive management Q&A panel up on stage here to answer any questions that you may have. Post that, Stephanie Buscemi, our Chief Marketing Officer, will be conducting a customer panel, and we'll also have Q&A there. For those of you who are in the room, after Stephanie's session, we'll be holding a cocktail reception with product demos on the seventh floor. We would like to welcome you all to join us there as well. It'll be great to mingle. To get the programming started, I'd like to introduce Jay Kreps, Co-founder and CEO. Jay, welcome. Thanks, Stephen. All right, I think it's worth it in the context that makes the most sense that we are operating with. Yeah, I'll recap just a little bit about the space. You know, we're now at a point where data streaming is out in virtually every part of the economy, and it's powering use cases in customer interaction. It's powering use cases in healthcare. It's enabling a next generation of manufacturing technologies and capturing data off the assembly lines in plants all around the world. It's actually helping to power part of the clean energy revolution with these more dynamic power sources that have to scale up and down continuously in a more intelligent grid that needs to have continuous data about how it's operating. I think all of these are examples of how software and the role of software in companies is changing. It's going from productivity applications that might be on the edges, you know, siloed applications here and there to something that's right at the center of how a company operates, that's right at the center of how it interacts with customers, right at the center of how it produces the goods and services it delivers, kind of right there in the drivetrain of the business. The problem that companies are addressing is really substantially different. It's no longer these siloed applications. It is really kind of directly interacting with what's happening out in reality, and that involves a very different use of data. You see that, you know, across the board in customer interaction applications, in IoT applications, in a lot of the logistics use cases. There's a real-time tracking of what's happening in a business, making decisions off of that, driving actions off of it. Increasingly, these software systems are just more connected than they used to be. The reason this is difficult, the reason it's challenging, is because, you know, the traditional tools that were available to actually power this don't really address that type of usage. You know, traditionally, when we think of how do we work with data, you have databases which were ultimately built as a platform for storage, for data at rest, for taking a pile of data, storing it safely, and looking up the bits you need when you need it. That makes a ton of sense. That's an incredibly powerful backend for applications. It isn't about how you react and respond in real-time. It's not about how data flows across an organization. There have been, you know, a long history of these kind of point-wise tools built for moving data. This is ETL products, message buses, application integration tools, you know, a wide variety of things. None of these really got the investment or the thought that databases did, and none of them have really scaled as the needs of a company have changed. A lot of what's changed is just the level of software, the amount of data, the number of new applications, SaaS services layers, and the connectivity of these, the fact that they have to come together and drive some kind of cohesive real-time interaction. That's what's driven the rise of data in motion, of this kind of real-time stream processing, this ability to, you know, tap into what's happening, capture it, react to it, process it, transform it, and build applications designed around this. The role of this technology in companies is incredibly powerful. You know, if you're spending more time at the conference, you can hear some of the customer examples. We're gonna bring some of those forward in this session so you can start to get a feel of what people are doing. In many of the companies that have adopted this at scale, this acts as a kind of central nervous system, where, you know, it's like the nervous system in an animal. It's kinda giving them the ability to tap into what's happening across all the different parts and all the applications they have. It's giving them the ability to react and respond. It's actually a powerful platform with a set of tools and ecosystem of use cases that surround it. At the heart of this is Apache Kafka. This is an open source system that was created by the founders of Confluent that has really formed as a foundational layer for this kind of data in motion, and that has become one of the most popular open source products in the world. You know, Kafka is now out in production in a huge majority of the Fortune 500, so over 75% of the Fortune 500 that we know of, right? As with many open source projects, it's impossible to track perfectly. This shows up in, you know, the largest companies in many industries. This has been a huge boon for Confluent, which has been able to go and interact with these companies and start to offer them our cloud offering. We've grown into a substantial customer base across these industries, and in many ways, we're just getting started in what's possible there. The rise of the cloud as a delivery mechanism for infrastructure really changes the monetization of open source. It's our belief that all of these companies will end up getting their platform for data in motion, you know, powered by a cloud service, and there will be a significant commercial opportunity around them. That really is our mission at Confluent. This is our focus, is to set data in motion and build this new platform. We think that this has the opportunity to be one of the major data platforms in companies. That's the opportunity I wanna outline a little bit today. When we think about data, you know, commonly, the data infrastructure world would be broken into the kind of operational databases and the analytical databases. We actually feel that data in motion represents, you know, very much the complement to what's out there today. It's not, you know, data where it sits. It's how it flows. We think this is a huge opportunity. In many ways, this is the most strategic place in the data stack because although it sits here in the data layer, it actually connects up and out into all these layers. This platform that actually taps into everything happening across your different apps and knows what's happening in a business in real time, that's an incredibly strategic position to sit in, and it's something that we think gives us a lot of opportunities to grow into over time, and I'll talk a little bit about that, as we get more into this. How do we go about commercializing this opportunity? What's our product offering in this space? Why do people choose it? Well, there's really three pillars that we've built differentiation around, that we've tried, you know, to create our commercial offering around. This helps form the comparison to the open source. When we answer the question, why would you use our cloud service versus just buying the open source? This forms the comparison to, you know, a lot of other competing products. These three pillars are, you know, first offering a truly cloud-native experience for our technologies. You know, we're choosing an open layer and ecosystem with Kafka, but we've done very deep engineering work to offer that as a truly elastic cloud-native service. What does that mean? Well, it's a very different thing for these kinds of systems to offer them as a cloud service, to be able to support multi-tenant operations with, you know, thousands of different customers. This allows them to consume, you know, just what they need and scale up. This is incredibly important in any of these technologies in streaming that are about how all the parts of a company come together. It's inherently a very dynamic use case that really requires that, and that really changes the game for customers as they deploy this. They no longer need to hire a large team of experts and figure out how to spend, you know, many months operationalizing this technology to put it into practice. They can just sign up for our service and treat it like a kind of utility and build against it, and suddenly have world-class expertise in this area. That's a huge jump forward if you think about where this technology came from. Early on, it was just the kind of large Silicon Valley tech companies that could form a big team and actually do all the engineering to bake this into their different applications. Now this is kind of available to every company. I think that's a very powerful thing. The next pillar is really offering a complete platform. Whereas these kind of Silicon Valley tech giants might just build it into their custom software, and they were building most of the applications they had from scratch, a modern business has a wide variety of older legacy tools, custom applications, SaaS systems. The ability to have the connectors to plug into all these, the processing capabilities to work with this data, and, you know, very importantly for our customer base, the governance tools to actually track the flow of data, guarantee the correctness and the freshness of this as it flows from place to place, ensure the compliance with all the regulations and laws around data is incredibly important. Finally, we offer this everywhere. We offer it across all the major clouds. We offer it in on-premises data centers and private clouds. We have technology that allows us to link all of these regions and environments together into one fabric for data in motion. That's a really powerful platform that uniquely allows our customers to connect their applications across all the places that they operate. This is a critical challenge for virtually every company today, is how to be able to build in new environments, you know, move applications into the public cloud while still keeping legacy technologies in other environments, bridging into other clouds where you may have acquisitions or other things operating in span, all of that. All of this adds up to a very significant savings for customers. When they look at doing this, based on the open source themselves and building a team around it or other ways of addressing these problems, there's a very crisp TCO, especially for our cloud offering. This is not always widely understood, but one of the most appealing things about getting this kind of infrastructure as a service is that compared to the kind of old way of just hiring a team and trying to piece together things with open source and writing a set of tools, you can get something which is better, those kind of cloud-native capabilities, the complete offering. You can get something that's faster, that actually performs better on the fundamental capabilities of an infrastructure layer, but is also cheaper. It is actually a better deal to get a cloud service. You no longer have all the waste in cloud infrastructure. You no longer have the team of highly sought after, you know, Kafka experts that's being hired away by competitors to run their streaming platform. All of this makes it an incredibly good deal for customers. We've done work with Forrester and others to validate this. This has become very much a part of our sales cycle with customers as we go in and work with them to express, you know, what the opportunities for savings are in their existing open source usage, what the opportunities for ROI and some of the use cases that they're just starting to think about. That's what allows us to go after this larger market opportunity. I wanna talk a little bit about this. You know, I think this is an area where, when I talk to investors, there's a lot of debate of, "Hey, what can Confluent actually turn into? What is this area all about?" You know, there's these message buses. Is it just that? Is there something bigger happening here? This is something where we have a very clear point of view, right? I've expressed that we feel like data in motion, this data streaming platform represents a very significant category. You know, we're showing here the 2025 numbers of what we think this category can be worth. I'll come at this in a couple ways. I'll try and show, hey, how do you get to a kind of large TAM here? What is it that you have to believe or feel is true to size this appropriately? With any new thing, there's some thought that has to go into what that total opportunity is. You know, I think the best place to start when you think about this is talk to some of the technologists, look at some of these, larger Silicon Valley companies that have actually built this platform out for several years. You know, how central is this to what they do? How big is the streaming area as a platform for them? You know, is it something that is, as important as some of these other data areas? I think that's one of the things as a technologist that gives me the most confidence in where other companies are going towards. It's not just that. The other areas of validation come as you start to look at a more bottoms-up model. One of the things that I think makes this a very practical approach for looking at Confluent is there's already hundreds of thousands of users of Apache Kafka. The fact that this could be a broad-based technology that's widely adopted, that's not hypothetical, that is actually the case. That number is growing extremely rapidly. I showed some of those usage stats in the keynote talk earlier. Getting to this scale of customer usage is not a hypothetical thing. I think that will happen. We further believe that the rise of cloud services dramatically changes the ability to monetize that usage. We feel like, hey, everybody who's out there doing this on their own, that is a much harder way to go. The ability to offer something better as a service means, you know, all of this open source usage is migrating to cloud services, and we think we're in a unique position to pick it up. That talks a little bit about breadth. The other dimension of this is depth. Hey, you know, how valuable is this? Is it really a major platform? Is it possible to kind of capture this large scale usage? Here I think the best data points are our large customers. You know, we disclose $1 million plus as a cohort. We have a number of customers in the $5 million plus. The number in terms of scale and what's possible, I think is very achievable. When we look at these large customers, we're not seeing any of them kind of tapping out. You know, this is still very much a platform that's gaining adoption. Data streaming is much newer than the traditional OLTP databases or analytics areas, so it's still very much in the rollout phase, and that's reflected in the growth we see in those customers. When you look at this from a bottom up point of view, you know, there's very clear data points that support what would have to be true. Now obviously, it's incumbent on us to go and make all these other, early adopters, in the Fortune 500 into very large customers, the ones who are just getting started now, the 25% that haven't even, you know, dipped their toes in the water. It's on us to, you know, continue to drive the breadth and continue the monetization of that. I think some of these earlier proof points of what's possible here, are, you know, make it very clear where this is going. The other view on this is, okay, what, you know, what does it replace? Is it just a message bus technology, or is there more there? Here I think again you can come at this, from different ways. We've clearly shown the capabilities for this kind of real-time streaming application development, the stream processing area, which is very different from the traditional message buses. We've shown the ability to replace a much broader set of data movement tools, than anybody would thought possible before by making something that's both, you know, real time, scalable, transactionally correct, and this is demonstrated by some of the work that we've done recently. We'll get more into this, but one of the announcements today was Stream Designer, which effectively provides an end-to-end data pipeline tool for building pipelines in a kind of low code or no code way on top of our platform. That's a capability that, you know, traditionally was only available on these kind of slow batch ETL systems that's now fully available in the real-time world. The breadth of what's possible here, I think is very different from kind of earlier generations of technology. You can see, you know, how we've broken this up across different areas, and we've given also a view here of what's happening in these segments. The exciting thing is these are growth segments. This opportunity is expanding when we look at what we're having the ability to address moving into the future. We've proven success across industries. When we look at our customer base, it spans virtually every industry, and it scales from, you know, the smallest, most innovative tech startups that are just getting started now trying to disrupt and have a kind of blank sheet of paper in terms of how they structure their architecture, all the way up to the kind of apex customers in each industry that are doing things at scale and need an industrial grade solution that works across a big, complicated, diverse business. Even within these customers, you know, there is a wide array of use cases. You know, this is a blessing and a curse for us at Confluent. It's always harder to explain a technology that has a broad set of use cases, but it's actually essential. You know, if somebody claims that they have some very broad data platform that's gonna be a big chunk of data usage, they should be able to point to, you know, really broad set of use cases across industries. I think one of the things that you can get a great sense of at this conference is how broad that is, what different people are doing across different areas. You could drill into any of these individual industries and actually see that, you know, kind of fractally, within that industry, there's 100 things that they're doing there. You know, for this one, we've kinda shown a view into telecom. This is an area that's been very good for us over the last year. Really exciting stuff happening. That's an industry that's moving to 5G and really redefining a lot of their systems as part of that, opening up a whole bunch of services around IoT, and then trying to change the customer interaction pattern from something that is kind of a drag on progress to something that's an advantage. All of that involves bringing together different capabilities. You know, we're gonna have to talk through this DISH who can give a great example of some of what's happening in that space. You know, they're rebuilding a telecom platform, I think in a really innovative way, around Confluent, and have some very interesting things to say about what's happening in the space and where that's going. You know, the way we work with customers is a key part of our advantage. Erica is gonna speak to this in more depth, but, you know, it's not the case that we need to land with a customer and kind of take them all the way to central nervous system all in one go. That's not how it works. You know, we land for individual use cases, and we expand out from that. We have a way of working with our customers throughout that journey. You know, starting with a low friction, self-service cloud experience and building up to large scale usage across an organization. We've put effort into how we do this at each stage. It's more complex to work down a long journey like that, but it's essential for a technology like us to really drive to scale in these customers. There's something that helps us that's unique to this space, which is most data platforms ultimately kind of sit as silos. You know, most databases, they serve a particular application. This data system is different. This is about the exchange of data across a business. There is a very natural network effect which drives adoption, you know, within a customer. The first application may come, you know, just for the features of our platform, but it brings with it a set of data streams. You know, in a retailer, maybe it would be the stream of sales. That stream of sales is probably the only way you can get the real-time feed of what's selling across all the different stores. It's probably the only thing you can tap into to really get that, and that attracts other applications. Those applications tend to bring their own streams to join into that, other data sets into the platform that they need to use with those sales data sets. Those data streams attract other applications. This is a kind of virtuous cycle that helps spin this up within customers and helps us get them to scale. I talked about the breadth of use cases. We think that this represents a significant opportunity for us over time. One of the exciting things about data streaming is it's new. It's not all done before. There's not vendors filling in every niche and use case around it. It really is a disruptive force that's changing how a lot of these use cases work. We feel that we have the ability to grow into some of these different usage patterns over time. We're starting with the ones that are the most common and the most obvious and present in the most of our customers, and we're trying to make that easier and easier to do. I mentioned Stream Designer, that's a very obvious one. If our goal is to spin up a central nervous system that plugs into all the data in a company, we wanna make it as easy as possible to build those kind of real-time data pipelines in a point-and-click way. By releasing that, we feel like we can accelerate that growth with customers and allow them to attack new use cases with, you know, less need for deep technical talent, and that's a really powerful thing. You know, key takeaways here. You know, first of all, this is one of the few things where there is a genuinely new data platform, which is very significant in size, right? We feel this is a $60 billion TAM, and really kind of represents a major estate in the data world. We've come after this with a differentiated product, which has a compelling TCO and ROI story for customers, and we're seeing great adoption and conversion to that out of the open source. It's a unique area which has network effects and is particularly sticky because it goes between applications, and we think that there are significant opportunities to grow beyond the core capabilities over time and have an unfair advantage in doing that because we're that location where all the real-time information of what's happening in the company is. That's a little bit about this overall area. We're gonna dive a little bit more into some of the details of the platform, a little bit more into how we take it to market. Next up is Chad Verbowski, who's gonna talk a little bit about our product. Chad? Thank you. To kick things off, I'm gonna talk today about why I joined Confluent. I'll give you an overview of this technology space that underpins what we're building here today. I'm gonna really focus on what we've done that differentiates us in the market. First, a little bit about me. I spent over 20 years working in research and engineering and development. I spent a lot of time, creating the systems management and cybersecurity group at Microsoft Research and the data analytics group at eBay. I also started a bunch of V1 products at Microsoft, and what I did there is created something that was called System Center, another one that was called the Azure Front Door, and one that was actually more recently renamed to Synapse, which is the Azure SQL Data Warehouse. What I learned through all of this experience is really how to build and develop technologies at massive scale that can support the largest workloads for every customer in the world. I also worked at Google for the last five years, and I built a product there called BigQuery, and I took that from something that was a relatively small, nascent cloud technology trying to do something different in the data warehousing world, to something that grew by more than 10x in those five years. What I learned from doing that is three important trends. The first trend is that no matter how great your analysis technology is, everybody wants it done faster and faster until really this is approaching real time. The second thing that I learned is that everybody has to work with multiple systems. It's not just going into one data warehouse or one data lake or one region or one cloud. It's gotta be everywhere. With regulations and other security things that are coming in, it's important that all of the systems that you work with can collaborate in this really distributed environment. The third thing that I learned is that everybody needs an open source interface, and this is because all of these systems need to talk to each other, and most importantly, nobody wants to be locked in to any given provider. What I found is that Confluent is actually providing an answer to all of these things and is really positioned well to be leading in this space. What I'd like to do is ground us all in a practical example. If we consider a typical financial business, they've probably got some kind of a legacy mainframe. They might be running something like Db2 on there that collects some information. They might have an MQSeries system that's collecting various messages. They've probably got various databases that they've collected over the years. They've got data warehouses, data lakes. They've got some SaaS applications, like they might have something like Workday for their HR department or maybe Salesforce that they're using in their sales department. They're also growing and expanding. They might have multiple regions. They exist in multiple countries. As they've made acquisitions over the years, these companies probably made slightly different technology choices. What this has resulted in is a set of components that are really rigid, that's complicated to manage all of these systems together, and it's ridiculously expensive. Business value is really coming from working across these systems, joining this data together, integrating it to produce interesting results, sharing that with other parts of the company that then build upon it in a virtuous cycle. It's really important that you maximize how everybody can work with this data. Really what we think you need is a new paradigm. What Confluent provides is the ability for everybody to build that central nervous system that Jay talked about, so that you can work with your systems, all of the systems that exist in your network, and in any location that they happen to exist. The important part is that you can do all of this in real time. We think that this takes three things. The first is you need an ecosystem of these connectors. You have to be able to attach and talk to all of these different systems in a language that they understand and pull it in to a common location so that you can work with these things as you need to. The second thing is you need an awesome storage layer, and this is Kafka. Kafka has been the first to really separate the compute and the storage parts so that you can collect these things with low latency and with the massive scale that you need. The third thing that you need is really the ability to build these stream processing systems on top of this. To do that, you have to be able to transform the data. You have to be able to integrate it together. You have to be able to filter it and join it all so that everybody can do this kind of analysis in the ways that they need for their particular domain. What Confluent provides is the ability to do all of this together in a streaming data platform. We've built it in such a way that everybody can now put together their central nervous system. To paint a clear picture of this, I'm gonna give you a real-world example of a top ten U.S. bank that we've been working closely with. Prior to working with Confluent, they used to collect and analyze data from all of their transactions and all the access that was going on in their system. They would analyze this roughly on the time period of days or weeks, and they would identify anything that was suspicious that they need to verify with their customers. They would send out about 50,000 of these emails. Now, clearly, that's not the best way to prevent fraud from happening on your system. What they needed, of course, was something that was more real time. Working with them, we were able to put that system together. It provided a much better customer experience, of course, 'cause we would all rather have prevented the fraud from happening than just reporting it later. With the Stream Governance capabilities that we had, they were able to really expand this data that they were collecting from the transactions and the interactions with all of the people in their company that should have access to this data and not have it accidentally leaked out to people that shouldn't. Now they're able to process 27 billion of these transactions every month in real time. They've won several awards for what they've been able to provide to their customers. It's a much better customer experience, but also they've been able to save about $150 per customer because of the efficiencies that you get from working with data in real time versus working with it in batch. I'd like to talk a little bit about why cloud native is so important for building a system that's really working with your data in motion. I think this is really good for our customers, and it's actually something that's super critical for how we differentiate ourselves here at Confluent. Now, cloud native is really about scale. You should be able to go from zero to infinity so that you can collect and process as much data as you have or need while it's growing. This is particularly important if you're somebody like a retailer. You might have Black Friday events where you have these spikes in demand that come and last for certain periods of time. You don't wanna have to have a bunch of excess capacity lying around if you don't need it. The other important piece about being cloud native is that you're serverless. You don't wanna have to manage all of the individual units that are required to scale up that capacity. The second thing is really completeness, and this is where we've gone above and beyond Kafka to build all of the infrastructure that you need to secure your data, govern that data, and also to connect with all of the systems that you have. Underpinning what you need to do is build those secure connections, the private links, the VPNs, to make sure that all of the data you're interacting with, and most importantly, these critical data services in your company, are only accessed in the most secure way with the auditing and governance controls that you need. We've of course got that network of ecosystem of connectors that we've put together so that there's more than 120 different systems that you can connect with right out of the box. The last thing is we have to be everywhere that your data is because it's critical if you're building a central nervous system that all of those pieces of data are reachable. It doesn't matter if you're in a different cloud provider, a different region, or even if your data is on-premises. We have the ability to seamlessly pull that data and push it around, and I'll be able to show you some of this in the demo at the end of my talk. This has been a huge investment for Confluent. This is proprietary stuff that only we have, and it's what makes Confluent Kafka much better than anything else in the industry, better than you can get if you're running it yourself, and better than anything you're gonna find from any of our competitors. Now, I'm gonna go a bit deeper into each of these three to really highlight the differences in what we've built here. The first thing is that we have re-architected completely the Kafka internals so that we can optimize it for how it should work in the cloud. If you're building and running things on-premise, or even if you're working with a traditional infrastructure as a service stack, you have to deal with these machine boundaries and the specifics of the hardware. When you build things in the cloud, there's no reason to expose those abstractions to the customer. I think this slide here is really gonna point that out. What it talks about is that if you're running Apache Kafka, the dark blue things are really all of the different pieces that you need to be working on. The middle ground is what some of the other cloud providers would provide with their instances of Kafka. On the right-hand side, what you're gonna see is all of those different layers that we are solving for you. Now together, we are the only fully managed cloud-native Kafka service that exists. Our abstraction really simplifies it by removing all of this complexity. What does complexity mean? At the end of the day, that is TCO for your business, so that you don't have to hire as many people to operate and deal with these tasks, and they don't have to be the experts in each of these domains. Why would you wanna be installing and upgrading operating systems versions, managing the Java instances, figuring out how many nodes you need to support the connections you have? You should be able to simply have the infrastructure take care of this. I think this is an area that we are significantly differentiated in. It's proprietary stuff that we've built, and we've been investing very heavily in this area. This is something that we're gonna be continuing to do as we move forward. Now to look at this in a little bit more detail. This here is a screenshot of what it looks like if you're running an instance of Confluent Cloud's Kafka. This meter here really tells you what your usage is, and it's nice and simple. If you can look at the speedometer in your car, you can probably figure out exactly how much Kafka you're using in the cloud. You don't have to worry about network, you don't have to worry about CPU, you don't have to worry about storage. We give you a nice simple metric for resources, the CKU, so that you can adjust what you wanna use however you want it, so that you can control, say, how much you wanna spend or how much you wanna optimize for what you're doing. I'm gonna drill into this in a little bit more detail because I think this picture really illustrates that point more clearly. This is a hypothetical graph here that shows in the green parts what would happen if you're running Apache Kafka or if you're running Kafka from, say, somewhere else. This is because you have to control how many resources you have at basically the machine level. You have to add or remove machines whenever you wanna make these changes, and it's possibly impacting your services you're making those adjustments. With our CKU system, where we can do it at a much more granular level, you can see that the red line, which represents our adjustments, can much more closely track the actual load of the system, which is represented by that yellow line in the middle. Being able to do that adjustment, of course, translates directly into that TCO, and it's simple enough that anybody in your company should be able to do it. What I'd like to talk about is another key differentiation that we've made, and this is something that we're uniquely doing. We've really separated the storage and the compute, and this is important. This is something that, say, companies like Snowflake have done as well. It's something that we did in Google, in BigQuery. What it really allows you to do is expand all of the storage that you have so that you can store data for as long as you want, and you can also store it for as little as you want. It's really up to you as to how you wanna make this work. We've completely rewritten the storage engine, and this is one of those differentiating points because now we can elastically expand to cheaper storage or to move the data around to make that as optimal as it needs to be for your usage. What I mean by this is when you're uploading data to Confluent Cloud. What we do is we partition that data. It comes in, we put it into different piles to spread it across these servers, and how that data looks might determine how that spread is going to happen. Occasionally, if you get more data of a certain kind in a business, it might make one part of that more busy than the other. What has to happen internally is something called rebalancing, where you decide how that's gonna be spread a little bit more evenly. With what we've built is we enable automatically rebalancing this in real time. This is again, something that customers don't need to worry about, that contributes, of course, to the TCO, but more importantly, it allows this to happen in a real-time way, so you don't have any impact while this is going on. It's something that a customer just doesn't have to manage. All of this, again, is intellectual property that we've built over time. This is proprietary to Confluent Cloud, and it's something that I think really reduces the complexity from running this system. The reality is, we've been able to offer, because of these redesigns, a 10x better SLA. It might look like, well, 99.9, maybe that's good enough, but in reality, that's about 45 minutes of downtime every month. I think going from something like three nines to four nines is a massive difference. The other thing that I'd like to talk about is really why what we've built. With all of these redesigns, we've built a system that we think is 10 times better than any other Kafka offering out there. We have over 3 million hours of engineering that we've re-invested in building this. We've also reimagined Kafka from the internal perspective to deal with that complexity and make it super simple for anybody to run. There's that separation of compute and storage that I've told you about, and there's that automatically load balancing as simple examples. We also have worked very, very closely with each of the cloud service providers. I work directly with the engineering leaders in Amazon and with Google and with Microsoft to make sure that we are using the most optimal APIs, and we have first access to all of the innovations that they've been building. This has resulted in us building a system that's 10 times more elastic, 10 times more resilient, and it allows you to store 10 times more data than anything else. As we talked about, there's a demo booth that we're gonna hold later, and we can walk you through this in more detail and even give you some live examples about how this works. The second major pillar that I spoke about before is completeness. Kafka is easy to get started, and it enables everybody to build some small projects. The problem is, the popularity of these projects means they don't stay small for long. As it grows, as the sources of data grows, and as the destination of data grows, we need some way for everybody to be able to collect and manage these things at scale. That's why those 120 connectors, the 120 most popular products that you need to work with, either pulling data from or pushing your results to, that all happens out of the box. Stream processing is also a core piece. You're not just collecting and moving data around, you need to work with this data. We make it very easy, as we pointed out with our new Stream Designer product, so that everybody can build these systems fast and share them around so that they can collaborate as needed. All of this is based on something we call ksqlDB, which is our declarative SQL layer for working with and defining how you wanna get that processing done. We also have the security governance tool so that you can ensure that everybody in your company that should have access to that data does, and they can start producing and working with these things to get those results. This again, I just really like to point out that in Apache Kafka, they don't really have any of the security or governance pieces in it. They don't have the ability to discover and share and show some of the lineage aspects that are critical as you're building these applications. That's something that we've got in Confluent Cloud. Going a little deeper on those connectors. We have connectors that will get you to basically any of the most popular sources that you need, the SaaS applications, databases, data warehouses, data lakes, and basically anything else. Even if it's on-premise, we can connect to it on-premise and use some technology that I'll tell you about in a minute that will enable you to bring all of that data into the cloud with a few clicks of the button. We think that this ecosystem of connectors is a huge advantage for us, and it's something that we're continually investing in. I'd like to talk a little bit more about this KSQL layer and why declaratively describing your pipelines is so important. If you can just define in SQL, say I have this piece of data, I wanna make this transformation to that data, and I wanna write it out to this spot. That is far more easy than figuring out what are all the file formats of that data, what are all the individual machines and shares that it's located on, or even when you're doing the processing, how many specific machines you need to process that. If you can just write those simple statements and have the infrastructure, which is Confluent Cloud, figure that out, you not only have a simpler thing to work with, you get a more optimal answer because you don't have to optimize how all of those pieces are collaborating together. KSQL allows you to build these ETL pipelines. You can also produce materialized view, which is just staging those results so that other systems can interact and work with them in a real-time fashion. We also can enable you to build event applications with this, producing events and results that trigger something else to happen, perhaps like a fraud detection application. ksqlDB is distributed, it's fault-tolerant. It also separates that compute and storage, and it allows you to build these queries in that fully elastic way. You can just worry about defining what it is that you need to accomplish. It covers aggregations, joins, windowing, and it also works with out-of-order data so that you can just really focus on any kind of thing that you need to get done. One of the things that we're launching is Stream Designer. It provides you with an end-to-end view of your data pipelines. It allows you to define all of these things in that GUI, so that if you're not as technical, you can build these pipelines and get them running. If you ever need to do something more advanced, you can bring in somebody that's more technical, and they can extend each of these nodes with something in SQL. What this allows you to do is to have people that are less technical, collaborating directly in the same tools with people that are perhaps more technical and thus optimizing that innovation cycle. It's future-proof, and it's easy to evolve because all of the things that you're working with, these connectors, you can change under the covers, and all of those pipelines will simply keep working. We've added role-based access controls so that you can view and edit any of the people that you think should have access to these parts. You might wanna leave some people to view it so that if they're debugging or they wanna understand how things are working, they can see it. You might also wanna limit access to who gets to change those things so that it's only the right people when it's out in production. The other product that we're announcing is Advanced Stream Governance, which provides you an end-to-end view of all of the data sources and all of the pipelines that you've been building. You can easily see how all of these pieces fit together, and that's very important because very often people are building these pipelines, you get to what I'll call the happy path of configuring it all so that it works correctly together. Quite often people will make a mistake. If they do make a mistake, it's very difficult to figure out where that mistake was introduced if you're in a complex system. If you happen to see that the number in one of the fields was a 7 instead of a 5, you can quickly look at this lineage view and see all of the potential sources, all of the analysis that was done beforehand, and you can walk through and find that area. That's something that we've got that it's very difficult to do in any other system. For example, imagine that you're working with a data warehouse, and you see a table that has that same problem. Your first thing you're gonna need to do is figure out where are the files that got inserted to create that table. That information isn't natively around in the system. By working within the Kafka ecosystem to produce these topics, use KSQL and Stream Designer to analyze this data into these flows, you have a much more manageable development environment. We've also announced that we're enabling annotations to all of the topics and all of the schema elements. Even if you're not familiar with the data source, you can very quickly and easily search for what you need and see how it's laid out so that you can use the optimal datasets whenever they're available. The other thing that I wanna talk about is something called Cluster Linking, because as we said, your data might exist in multiple regions, it might be in multiple clouds, or it could even be on-premise. What you need to do is to be able to move this data around as you need it with just the results that you need in a very simple way. What we've built is something called Cluster Linking. It exists everywhere your data is because it's natively built into the brokers that you have that are just a part of Kafka. What you can do is we have instances that are all around the world in all of the data centers, in all of our cloud providers, and right on-prem, you can very quickly integrate those pieces together. What Cluster Linking does is it enables these byte for byte replay of Kafka data between any of these systems. You can use these things for disaster recovery, migrating your data, or just if you wanna share and collaborate with folks in different parts of the world. We think that this is something that really differentiates us, and it's something that makes it easier for us to get access to all of those different data sources, where other competitors or even if you're running Apache Kafka yourself, it might be very difficult to set up, maintain, and do. With that, I'd like to walk you through a demo of the product. In this demo, what I'm gonna do is just focus on a very simple example. I haven't picked something that's in the finance industry or retail or any of those other pieces because I think that it's more important to really focus on what are the basic concepts that we're providing here, and to really illustrate how quickly it is to produce these pipelines. I think as you see what we're doing, you'll be able to apply what we're doing here to any of the multitude of different domains that we work in and all of the different problems that can be solved. What we're gonna work with today is really the real-time information that is shared by the New York bike sharing system, where you can rent a bike and drive it around the city. What we're gonna point out here is really how you can collect that data in real time, how we tag and catalog all of that information and store it inside our system so that another user could very quickly search and discover the data that they need. You can see the lineage of how all this stuff is working together. We're also gonna show just a little bit about how this data can be shared through connectors, it can be shared through a map, too, for another application so that everybody can see the positions of these bikes. We're also just gonna show how we can use that Cluster Linking to share this data with another group, say, in Europe. With that, you can see up here, this is what Confluent Cloud looks like. You can see that you can search very quickly for a topic related to bikes. As that comes up, you can see the different volume of data that's coming in. You have that description that somebody's put in about what this topic is doing. We can see that there's tags there marking it sensitive, and you can also see who the contact person is for this information. As we drill into the schema and the structure of each of these events, you can see that it's the latitude and longitude there that is marked as sensitive. We know that if we're gonna be sharing this data, we're probably gonna need to remove that sensitive data. If we click on the topic here, that's the external source that was showing all of the different bikes that are producing events. It's going into this topic of bikes. Then, as I mentioned before, there's these connectors that are sharing that information out to different systems and of course the bike map application that's drawing those pieces. If we're gonna share that data, we're gonna wanna create a brand new pipeline to filter out those sensitive fields. We've started by creating a new topic, and this topic is gonna hold the routing of that bike information that we're gonna work with to analyze those fields. The first thing is, we're just gonna create our new instance of our pipeline, which is the source of this bike data. You can see here that we're just indicating in that topic, which are the schema of events that we wanna collect. Now that we have the data that's really the source in our new pipeline that we're creating, we can take a quick look at the different messages that are coming through. Inside here you can see that every message is from a particular bike. There's the ID of the bike. You can see the latitude and the longitude that's giving that very specific information about the location that's sensitive. The first thing we're gonna wanna do is maybe filter this out so that we only see information about the bikes that are actually active. If there's a bike that's disabled for some reason, there's no point in sharing that data. You can see here that we can create a filter, and we can just filter out all of the disabled bikes, and it's just that easy. Point and click. The next thing we wanna do is we wanna project this data, because we're gonna grab that subset of information that we wanna share. What we've done here is we're just gonna name that projection, and then we're gonna go, and we're gonna look at all of the fields that are important. Of course, the first one is gonna be the identity of that bike, so that we have something that we're talking about. The next one is those sensitive fields. Very quickly, what we can do is we can round up those fields so that we can reduce the precision of that latitude and longitude, thus getting rid of any of the sensitivity that's involved. We did that for the latitude. We'll simply do that again for the longitude. What we're gonna do is round it to those two decimal places. We'd save that. We're gonna give a name to this, and this is really defining something that's gonna run as one of those KSQL queries. This is an example of where you could write it in SQL, or you could use this visual editor to define those pieces. The final thing is we're gonna host this data, the results of that data that we're gonna share with somebody else, the output of this pipeline. We're just gonna call it the clean bike data, and we're gonna name those events in there. Because it's using effectively the same schema, it's the same bike identifier and the same latitude and longitude, just with different position, we're able to just reuse that schema as we share it. We've activated the pipeline, so this is it. This is what it takes when you wanna deploy something to production. It's very simple. You just hit a button, and under the covers, we're figuring out how many servers you need, what resources should be allocated, and just stretching it to make sure that that works. You can see very quickly we've already got our results, the truncated latitude and longitude and the bike identifier. What I wanna do next is just really walk us through how simple it is to share this data with the folks in Europe. The first thing that we're gonna do is indicate that we're taking the data from our USA source. It's in New York City, and then we're gonna configure where it's going. We're gonna send it to Europe. We're gonna put it in Frankfurt. We could replicate all of the data that we have very easily along the way, but for now, what we're gonna do is just share that one topic. We're gonna name this so that it's easy for anybody else to discover it and see how it works if they need to. That's it. We click the button, and we're now sharing that topic completely between one cloud provider to another and completely in a different geography. What we're doing here is we're just picking that cleaned bike data and sharing it. With that, we're done. What I'd like to give you is these four key takeaways. Our market leading platform that provides you with the infrastructure you need to build that central nervous system for all of your data in motion. We wanna show you that Confluent is not just 10 times better than Kafka, but we're also the de facto standard for all of data streaming. The third thing is that Confluent also drives the significantly lower total cost of ownership because of those proprietary things that we've added as we've built it for Confluent Cloud. The last part is, as we've moved up the stack, we've built Stream Designer and Stream Governance, which has expanded and made it easier for not only more users to use our system, but it's also enabled us to take on many more interesting use cases. With that, I'd like to hand it over to Erica. Thank you. Thank you, Chad. Good afternoon. I'm Erica Schultz, President of Field Operations here at Confluent. Thank you for spending your afternoon with us. It's great to have you here. I'm gonna talk a little bit about capturing our market opportunity, starting with clicking down into the total addressable market that Jay talked about, and then I'll get into how we go about capturing that opportunity, how we go to market, and what our customer journey is that we align our resources to. Let's get into it. You've heard this already today. You know this. There are hundreds of thousands of organizations that are using Kafka today, and this presents a massive opportunity for Confluent. It also means that when we go to market, it's not an evangelistic sale because many, many organizations, many individuals are already using Kafka and are already familiar with data in motion. It's a large market opportunity for us to capture, to work with those organizations to convince them of the value add of Confluent, and we're building a very unique and differentiated go-to-market model to capture this opportunity. Jay shared this slide earlier, but I wanted to share it again just to add a little bit more color to the bottoms-up view of our total addressable market in 2022. Our bottoms-up view supports the top-down view that sizes our TAM at an estimated $60 billion. We arrive at this because the average ARR by cohort is supported by our experience with customers in each of these cohorts as we have landed and expanded them over time, and I'll show you a few examples. For, you know, as we get into the Fortune 500 accounts, we believe that our average customer over time will be spending $10 million a year with us. Similarly, as we get out to the broader enterprise market, we believe there's a market there where the average customer will be spending $1 million or more. We believe that our product today can support the $60 billion in TAM, and it's also true that we're in very early innings of capturing this. We, you know, many companies are still in early stages of adopting their own data in motion journey, and we're in early stages of building out our customer growth go-to-market to really capture this, which we'll talk about. Jay also showed this slide earlier, and I wanted to rehighlight that we have a really diverse set of industries represented across our installed base. It's really exciting for us because this is where we see kind of the endless plethora of use cases that customers come up with to put data in motion to work. It also gives us a really diversified portfolio, which is great, and gives us a number of growth vectors. We're just seeing real-time data streaming becoming more and more relevant across so many industries with so many use cases. I wanna call out a few of our referenceable customers in the Fortune 500. We have a number of them, and these are a number of the referenceable customers across many industries. A number of them are here today at the conference with us, but we're really honored to work with so many incredible companies and see them put data in motion to work to transform their business. We do count 172 Fortune 500 companies as customers today. Growing our large customer counts is something that we're very focused on. We wanna make sure that we get into these really high propensity accounts in a very intentional way, and then meet them where they are in their data in motion journey, first of all, and then partner with them to grow their capabilities around data streaming pipeline and their adoption of different use cases. We have 172 Fortune 500 customers today. 107 companies spending more than $1 million a year with us. Some of those are Fortune 500, some are not. Then 157 companies spending more than $100,000 in ARR with us. Each of those are up significantly year-over-year. I will share that we have a number of customers already spending more than $5 million in ARR with us and ten more than $10 million in ARR. Again, those are kind of the proof points for us where we see what's possible, and even in those largest customers, we know that we still have a lot of runway because of where they are in their data in motion journey, their adoption cycle, and the opportunity still to come. We can land small, we can land big in customers and companies, depending on where they are in their data in motion journey. Some companies may start early on in the journey and adopt Confluent in a moment of experimentation or building a new app, like some of the customers that you see on this slide who started small with us. Others might already be using Kafka in a mission-critical production application, and so when we first meet them, our job is to help migrate them and ensure safe passage from a mission-critical app built on open source over to Confluent. Oftentimes those initial lands are bigger, like the one that you see in the Fortune 50 bank. What's true across all of them is that once we get in, we tend to expand pretty significantly and consistently ranging from, you know, this, the online travel provider here who's grown 29x over the last six years and eight times, 31 times, 9 times in these different companies. We're very focused on, you know, especially now with Confluent Cloud, we're very focused on landing as quickly and easily and frictionlessly, if that's a word, as we can up front just to get customers going with Confluent Cloud and then worry about driving consumption through incremental use cases to help them expand. Let's talk about our go-to-market model and our go-to-market motion that helps us capture this significant addressable market. We call it the customer growth go-to-market model, and it has three core pillars. It's product led, consumption oriented, and purpose-built for the data in motion journey. We are very focused on maximizing each of these pillars so that we can add value to customers whatever stage they're at in their data in motion journey. We've deliberately named this model to differentiate, even for our own sellers and our own go-to-market team internally, that this might be different than how they've gone to market in companies past. This is very aligned to our customers' journey, which I'll show you on the next slide. Let me just give a little bit of detail behind each of these three pillars. First off, product led. We want our customers to be able to get into the product as early as possible in their engagement with us, not wait until after they buy, but as soon as they're starting to explore Confluent, we wanna get them into our product. We have a pay-as-you-go offering that they can get into self-service. Sometimes our sales teams will invite them in, give them an account to get them going on Confluent Cloud as early as possible to start experimenting, tinkering, building, in as early stages of the journey as possible. Oftentimes, this might even replace a demo, or maybe it comes together with a more robust technical proof of concept, but we wanna get customers into the product in their own account as quickly as possible. The next pillar is consumption oriented, and this is important because we want customers to be able to use Confluent and build that first application and even expand without friction. We don't want the increase in consumption to be blocked by having to execute a new transaction with us. We want to encourage consumption. We do this through usage-based billing in Confluent Cloud. This is really important. We want customers to be on that journey adopting more use cases and not having to worry about transacting with us every time that they do. It's really good for customers. Finally, purpose-built for data in motion. This is where we really differentiate because this is all that we do. Data in motion, data streaming platform, this is all that Confluent does. We wanna make sure that at every point in their engagement, whether customers are engaging with our product or engaging with our team and our expertise, that what they're experiencing is that Confluent always brings the most valuable expertise, the most opinionated talent to the table to help them along their data in motion journey. This ultimately, the combination of all of these, ultimately not only allows us to go to market in a really opinionated way and in an increasingly efficient way, but it creates a competitive moat for us because we are the only ones in the market who specialize in data in motion, and we can bring all of these capabilities to bear and show up as really differentiated than any of our competitors out there. This go-to-market model is rooted in the customer adoption journey and what we call the data in motion journey. What's inherent in this journey is it's often a journey from projects to platforms, from a single use case to multiple use cases, from experimentation to our the ultimate realization, our ultimate goal of a central nervous system within an organization. Our goal is to serve customers at every stage of the journey. Again, we meet them sometimes at different stages of the journey, not everyone at the very beginning, depending on their use of open source Kafka. But this is really the journey that that we anchor to when we think about how can we optimize engagement at every step of the way. The journey often starts with developers in an experimentation phase. Again, we want this to be really low friction. We wanna build developer love. We have lots of ways to engage developers, of course, in the product with a great product experience and documentation. We also have our DevX team, our developer relations team, and community, and lots of resources for them. Earning developer love is really key to success in these early stages. Then the product needs to be available for instant usage with all the needed features and the least amount of hassle. Again, we wanna get customers in using the product without creating the friction of having to transact with us or having to, say, size their usage of Confluent, the size of the application, the data, capacity they might need. We don't wanna ask customers to do that too early in the cycle before their application's even in production. This consumption-oriented focus is super important. Once applications get into production and might be mission-critical applications and disparate use cases, as you can imagine, the engagement with the customer is anchored around things like, getting through an infosec review, proving out our availability track record, connectivity, as Chad talked about, all of the different ISVs, the sources and sinks that we can connect to, operability, compliance, and predictable pricing that scales. Those are often the conversations we're having in those stages. Of course, as we get even more sophisticated and as customers are leveraging Confluent as a cross-company platform and ultimately that central nervous system, we're having conversations with executive stakeholders, about our partnership, about maybe building a center of excellence and about company-wide governance now that we've become a platform for their most mission-critical applications. I love this quote from Flō Networks, one of our customers. Flō Networks enables leading banks and financial institutions to grow cardholder usage through engagement throughout the customer life cycle. They've told us that Confluent sits at the very core of our entire platform and modern payments business, serving as the underlying data mesh for everything we do today and anything we may want to do in the future. I love this last clause here, because we hear this a lot is customers initially maybe bring us in for that one use case, and then they build out more use cases in the platform, and then they say, "Okay, now this is the standard for anything that we build going forward." That's a really exciting position for us to be in. This is a specific industry example of the endless number of applications and use cases that we can offer to our customers that can be powered by Confluent. This is an example in financial services, and across a number of different lines of business within, say, banking and capital markets. We often see customers engaged with one specific need and use case, and then they'll add additional use cases once they see the power of data in motion. I'll add that, you know, as we think about our usage expansion and consumption of Confluent, specifically Confluent Cloud, increases in consumption is really driven by incremental use cases. That makes Confluent really different and our consumption different. We're not a data destination or a data receiver like a database might be or a data warehouse. We're a data mover, and we're a data generator as we're generating events. It means that as customers are expanding their consumption of Confluent Cloud, they're doing it through adding multiple use cases, and it makes that consumption really durable. It makes us a really important partner to our customers. I'll give you an example of a specific customer, a Fortune 50 bank, to kind of connect this use case view with, maybe the customer ARR growth numbers that you saw on some of my earlier slides. In this case, this customer started out by using open source Kafka, several years ago, and so we met them when they were already familiar with Kafka and data in motion. The first use case that they brought us into was in the private bank. They were looking to kind of optimize, account hierarchies and accelerate customer onboarding, and so that's when we landed them as a Confluent customer in Q2 of 2018. We landed them pretty big, which was for $1 million in ARR out of the gates. From there, this customer started to expand to additional lines of business and specifically in the retail bank and personal banking. They're leveraging Confluent for all digital interactions with their customers through web, mobile, or any digital channel. Data from these streams are used for prototyping marketing programs. They're able to, in real-time, capture data from those customer interactions and then generate real-time marketing offers back out to customers. They've shared with us the return on investment that they're getting from this application, and it's pretty significant. From there, this customer then moved to leverage Confluent across a number of different lines of business in building really a unified data layer. This is where they really took Confluent into the institutional bank in areas like equity trade flows, FINRA reporting, futures clearing, and real-time analytics for products like global spreads are also supported by Confluent. Now as they've expanded across these lines of business, as they look ahead to the next project and the next line of business, Confluent and the data streaming platform are a standard. The next thing that they build will be built on Confluent as a standard across the bank. I'll point out that, you know, as you can see here, this is one of the customers that I mentioned that is spending more than $10 million a year with us today. We see growth to $20 million and beyond based on where they are in their adoption journey and the use cases and applications that are still out there to leverage real-time data. That's one example. What's happening underneath these use cases, Jay shared this earlier, but I wanna connect it to the use case adoption. What's happening is this network effect is very real, and it's really powering the adoption of the next use case. As you know, streams of data go between applications, our customers are adding streams to the platform, and then they'll unlock value for that use case but also attract the next use case because of the data that is being streamed in the platform. It's really a virtuous cycle of adoption that one application brings in the data that begets the next application, and that really helps to drive the use case adoption. It's a really exciting phenomenon that we see with our customers that leads us to getting to that platform stage, and we've designed our product and go-to-market journey to map to this. One thing I get asked a lot is, do you have a product-led motion or an enterprise sales motion? For us at Confluent, they're definitely an and. We think they're very complementary. We based on the different products or stakeholder personas that we serve in our accounts, we can meet those personas with the right engagement model and the right motion that delivers the most value to them. Developers, for example, very much prefer a product-led motion. Get me into the product, let me self-serve, give me great documentation, community support if I need it, and that's where we can meet the developers with a very product-led motion that we continue to optimize. Meanwhile, as customers progress through that data in motion journey, there are a number of engagement types that are best led by enterprise sales or an enterprise, account team. For example, as we're working with customers on an overall success plan and governance and SLA requirements and security and the master contract, that's where we wanna make sure that we're bringing in the right, support and enterprise account team to support customers. We leverage both of these in our model, and we view them as really complementary. I'll comment a little bit on our market segmentation and how we segment our resources to different opportunities in the market. Our market segmentation strategy, first and foremost, really drives focus for us, and it ensures that we deploy the right resources to the right accounts based on propensity and stage. For example, we have, you know, broadly speaking, an enterprise go-to-market team and a commercial go-to-market team. We have enterprise teams in each of the geographic theaters, and then we have a global commercial organization. They are roughly divided by the customer total annual revenue of $1 billion. Within those different organizations, we resource our account teams differently. In our enterprise segment, and particularly in our strategic account segment, you might think of, you know, a select number of Fortune 500 or Global 2000 accounts as being in that strategic segment. That's where we might have obviously more seasoned enterprise account executives, but also maybe a higher ratio of solution engineers and solution architects supporting them, or more customer success engineering resource. This is where these teams will partner more closely with the system integrator partners, that we're developing relationships with. We'll invest in those strategic accounts a little bit differently. Of course, the goal is to land first, but land very intentionally in the right accounts where we see high propensity, but then to expand to realize the full TAM in that account. In contrast, when you look at our commercial segment, this is a little bit more volume and velocity-based. Our resources in our commercial segment are based in hubs around the globe. We will have slightly less of a ratio of solution engineers, solution architects to support customers. We are looking to land a number of new logos, very focused on high propensity digital native and startup type companies. We wanna see a high volume of lands and then also, expansion as much as possible within that segment. This segment also, I'll point out, many of these customers start on our pay-as-you-go model, and we get them into the product quickly and expand and drive consumption from there. Just a little bit about how we align our resources. Finally, I'd like to spend a couple minutes on the role of our partner ecosystem in our go-to-market strategy. Our partner ecosystem is really essential to us realizing our full potential in the market and to delivering value to our customers. We're fortunate to have really strong relationships with a number of different partners in the cloud and data ecosystem. We divide them into categories, our cloud service provider partners. We partner with the big three here, global system integrators and regional system integrators, and then ISVs. I'll talk a little bit more about the cloud service providers on the next slide. Let me just spend a minute on the GSIs and RSIs and ISVs. We are in very early stages, I would say, of building out relationships and practices with the global system integrators, but we see big opportunity there and really clear opportunity for Confluent to fit into a number of their practices. Many of them already have a number of folks in their organization skilled up on Kafka, and that is part of a number of their transformation practices. We're working with them to make sure that Confluent is part of that. Regional SIs, as you may know, play a really critical role for so many of our customers around the globe. They're often the ones that have the account relationships and account control. Many of them partner very closely with the CSPs, and so it's important for us to help the RSIs build practices with us as well. Many of them are choosing us as one of a very small number of technologies to make a bet on as they build out their practices in their geographies. We have a broad network of ISVs that are very important to us. Chad spoke about this earlier, our connectivity strategy. We have integrations with over 100 different ISVs out there, and it's so important to our customers that we have these integrations and that they be simple for them to use, and that we show up in the market with a really clear reference architecture for our customers to leverage about how all these different technologies in the modern stack fit together. These ISV relationships are really important, both from a technology integration perspective, and then we also go to market very actively with a select few, with joint solution plays with partners like MongoDB and Databricks and a few others. All of our partner ecosystem are really critical to us, winning in the market and ultimately driving increased efficiency in our go-to-market model. I'll spend a minute on the cloud partners. This is something I also get asked a lot about or quite frequently, is how do you handle this kind of coopetition? Are they friend or foe, the cloud service providers? The headline here is they very much want to work with Confluent. We're really pleased with where our partnership is with AWS, Google, and Microsoft, and I'll click into a little bit of why they want to work with us. First and foremost, the goal with the three cloud providers is to be the best source of data sending data into their clouds and driving consumption of their services. Again, we're a data mover. We're not a data destination or receiver. We're a data mover, and so that's really helpful for them. We drive consumption of their services. We spin their meter, and so they incentivize their sellers to sell a number of different ISV solutions, but they've seen with Confluent that we actually spin their consumption meter on a number of services pretty significantly. First and foremost, they see a ready market, and they know that that Kafka enjoys very broad adoption in the market. In fact, one of the solution engineering leaders at AWS recently told me that the number one requested skill development, skill set development or training that their solution architects and solution engineers were requesting was around Kafka and Confluent, because they're seeing so much demand in the market for it. They see the market for it there, and they know that we're the market leader, so the opportunity together is obvious. The second one here is we do work together to construct joint solutions. For example, we've gone to market together with things like data warehouse modernization, where we can construct, you know, put a couple of the CSPs native services together with our offering and go to market together, and that's a really easy way for our joint sales teams to take solutions to market. Third, I think it's really important to point out that, you know, as customers contract with the CSPs through, say, their private offers marketplace, and they make big commitments, when they purchase ISV solutions through the private offers marketplaces, they can burn down those commitments, and the sellers get compensated for bringing in ISV solutions. There's really kind of a win-win-win. Customers win because they get to burn down money that's already allocated to the cloud provider. The CSP sellers win because they get quota retirement, and then on the back end, they drive more consumption of native services. Confluent wins because it gives us a route to market. We know that when we go through the cloud provider marketplaces, it does speed up our sales cycles, which is really advantageous for us. The fourth reason here is around migrating customers to cloud. I think of this as we can help the CSP's customers unlock or unleash the data that's sitting in on-prem environments and legacy environments, and oftentimes that helps them get new cloud applications going. Thinking about that data-led migration has been a really great opportunity for us. I've talked about this, but we really do increase data consumption for the CSPs. I think, you know, we're sending a lot of data to a lot of different services, and so it's both the advantages up front around burning down the commits, but then it's the advantages on the back end of Confluent moving data into all those services. To pull it all together, you know, I again wanna reiterate that we are in the building stages, the early stages of this unique customer growth go-to-market model, and we're building on a number of components. We are, you know, we're in a position where we're working on maturing each of these components individually, and then also building really strong connective tissue between these components of our go-to-market model, because both of those is what will help us really unlock improved efficiency in our go-to-market motion at Confluent. We're early in this journey. You know, we just turned 8 years old as a company, and we just released our Confluent Cloud offering in 2018. We just released usage-based billing and our pay-as-you-go offering in 2020. We just recently, around that timeframe, got into the cloud provider marketplaces. You add those up, and we're still pretty early in the journey of bringing each of these capabilities to market. We're very focused on building out these components, as I say, of the customer growth go-to-market, and then making sure that they connect together to drive even greater efficiencies. Just two examples of, you know, how they connect, I talked about the self-serve motion and the pay-as-you-go, and the fact that many of our customers start there. While connecting that with our commercial segment and how those sellers go to market, we are already seeing about 70-80% of our new subscription-committed customers in the commercial segment start on pay-as-you-go. That's through over the work we've done over the last year or two to make that happen. As we really optimize that improves the efficiency of our land motion in this segment where we land most of our logos. That's one example. I also talked about our strategic enterprise segment and landing very intentionally and deliberately in these high propensity accounts. We know that when we combine that, our sellers in that segment with partner ecosystem and an industry focus so that we can speak to, for example, our banking customers in their language, that really adds effectiveness and efficiency to that motion. We're building out all of these capabilities and stitching them together and early in the journey, but excited about the progress. These three pillars of the customer growth go-to-market are very connected, directly connected to our business performance. From a product-led perspective, we're tracking metrics like total signups and total customer count. From a consumption-oriented perspective, we're tracking metrics like our Confluent Cloud revenue. From for purpose-built and data in motion, important metrics here are RPO, NRR, and our large customer count and how that grows year-over-year. It's a really important time for us to make sure that these components lead to increased leverage in our go-to-market model. Here's a little bit more insight into the things that we're tracking. Certainly sales productivity is a key metric for us, and we've seen improvement in year-over-year productivity in our tenured rep population. We are expecting to exit this fiscal year with more than half of our sellers as fully ramped reps. If you recall, 2021 was very much not the case. It was a big investment year. We hired a lot of sales capacity. Now, as folks have come into that ramp, the mix of sellers between tenured and non-tenured is changing. We're seeing a faster ramp for our customers. We've put a lot of work into optimizing our consumption model to get our customer ramp time down, and we're currently at about six months for customers who make a more significant commit to start consuming at a rate that when annualized, is commensurate with that commit. That's down from where we started, and we continue to work on optimizing that. I mentioned that many of our new subscription customers do start on pay-as-you-go. More than 50% of our Confluent Cloud transactions are happening through the marketplaces, which is really positive. We have put up 130% or more NRR in the quarters since we've been public, and that is led by our Confluent Cloud customer cohort and our hybrid customer cohort, where we see the strongest NRR. These are some of the metrics that we're tracking to make sure that we're bringing increased efficiency into our go-to-market model, and we're really excited about what lies ahead. A few key takeaways that I'll land on. The first, as I mentioned at the beginning, because of the Kafka adoption in the world, Confluent is not an evangelistic sale. You know, we get to meet many customers partway on their journey to adopting data in motion. We're building out our unique and differentiated go-to-market model to capture market share, the customer growth go-to-market. Our large customers continue to show strong growth with a long runway for expansion. We're in the early days of really growing and harnessing our partner ecosystem. The increasing leverage in the model paves the way for durable and efficient growth. Put all these things together, as my team knows, I use the phrase a lot that we're just getting started. We're excited about what's happening in the market with Kafka and Confluent adoption and about the journey that we're on with our customers. Thank you very much for your time. I think we're moving to a 10-minute break. When we come back, we will do Q&A with the executive team. Thank you. All right, we're back for Q&A. You know everyone up on stage here. I'd like to turn it over to just the audience, and you guys raise your hands. Feel free to ask questions. Shane and Faheem have microphones, and we'll hand you the microphone so you can ask the question. Okay. Hey, Michael Turrin, Wells Fargo Securities. Thanks very much for hosting. I think the big question for a lot of us in the room is just where we are on the migration of some of the larger open source users of Kafka over to the Confluent platform. Jay, you had a fairly strong statement. I jotted it down on just our belief is all of these companies will eventually leverage a cloud service, and so maybe you can go into the mindset of what drives that belief state for yourself, and is it how much of it is go-to-market versus what you've done on the cloud platform side that can help bring some of those bigger propensity users over to Confluent? Yeah, that's a great question. Yeah, you know, it's really worth understanding this in detail. If you look at some of the, you know, older models for commercializing open source, it was selling kind of a proprietary piece of software in your on-premise data center. You know, effectively in that world, the, you know, productized version of the open source functions as a kinda premium product, right? You have kind of a freemium model. Some people will use the free, some people will use the premium, but most people aren't using the premium, right? Maybe you have, call it 5% conversion, it would be pretty common in that world. When you look at cloud, it's actually quite different. You know, the value proposition of a cloud offering, it's not a premium thing. If you think about, "Hey, my alternative is to go hire a big team of people and purchase all this cloud infrastructure and then run this data system there," it's actually a better deal. You know, not just a better product, not just a better outcome, but actually cheaper to get a cloud service. You know, that's a very different way of thinking and building. You know, for a lot of these tech companies, it may not be the way they started, right? I was at LinkedIn previously, where we created Kafka. They had big internal teams. They built lots of infrastructure, heavy investment in that. If you look at a lot of the companies now, what they're doing, you know, both more traditional enterprises as they move to the cloud. A lot of the tech companies, they're trying to get out of having these massively expensive teams running, you know, effectively internal platforms that are the same everywhere. You know, they want their people working on the things that are their competitive differentiation. Yeah, what do we need to do to go capture all that open source? Well, part of it's about that mindset shift. Part of it for us has also been having a cloud service, right? You know, we had to have a cloud service. It had to be, you know, especially for the bigger tech users, it has to be good enough that it serves all the things they're already doing, and it has to have a TCO story that's compelling, even at very large scale. As we've started to open that up, then we've been able to go and start to take some of these early Kafka users. You know, New Relic or Square, these were early users of the open source who are doing exactly that, you know, for a whole host of reasons. Better product, better experience. Usage across clouds and TCO are looking for a managed service that they can adopt. Yeah, I think that that's a trend which is going to both continue and accelerate. You know, when we talk to companies, it's very clear what their mindset is. Some have a do it ourselves in-house mindset, some have a let's get out of this mindset. If you look at the economics like we do, like we sell a software product, we sell a cloud service, so we compare them all the time. It is just vastly better to get a cloud service. I you know, I think if you look at a lot of these tech companies and you look at just how they're deploying resources, they need to drive efficiency. A lot of that is gonna come by focusing on the stuff that's unique to their business, and that is gonna drive, you know, adoption of cloud. If you look at what's happening in the cloud products, they're getting better and better at an incredibly rapid rate. It's not just a matter of getting open source Kafka as a service. You're getting this whole suite of capabilities, which is just incredibly difficult to replicate and practically speaking, impossible to replicate, you know, any other way. All of that, I think, drives that increasing commercialization rate that I kinda referred to. Long answer to a short question. Thanks. It's Tyler Radke from Citi. I wanted to ask you about the, you know, I guess it's kind of a go-to-market and product question. First, as you think about some of the new products that you announced today, both the Stream Designer and the governance side, how are you thinking about who you're selling that to, kind of the lay of the land competitively if you need to alter your go-to-market approach at all? Secondly, I noticed on the industry side, it seemed like healthcare was a little bit underpenetrated in terms of the commercial Confluent adoption. I'm curious what you're doing specifically in that industry to accelerate more adoption of the paid Confluent offering, given that it has really strong Kafka open source. That's great. Maybe I'll take the personas and product one, and I don't know if you wanna take the healthcare area. I would say over time, those will start to address different personas. We always start with a model of, hey, starting with the customer you have, serving them, and then branching out. When we thought about governance, you know, it's very much what are the things our customers are banging on the door and asking for to allow them to use our platform more. Let's solve that first. Over time, I do think that there's a broader role of what that product can be and how it will incentivize even more adoption of the platform, you know, where the chief data officer is going around telling you better, you know, do it through Confluent 'cause that's the thing that we have all the controls and safety around. That was how we thought about that. Very similar with Stream Designer. We said, "Hey, we wanna make it just dead easy to build streaming pipelines." It shouldn't be, you know, hard in real time or easy in batch. Like that's not right. You should get to kinda have your cake and eat it too. When we start that journey, we want to make something that works for developers, that has a direct translation to code, so you can see exactly what's happening. You can work with the whole developer tool chain, you know, so that you're, it's not like you have this trade-off between a kind of no code tool where you can kinda do simple stuff, but you fall off some cliff, and then you're stuck. You know, really has a direct translation to the underlying ksqlDB and Kafka topics, and very much is an active participant in that ecosystem. You don't have to know that. You know, you can use it just as a no code tool. You, by doing that, you actually can participate in that rich developer tool chain, and you can address the customers we have today who are right on the boundaries and are, you know, trying to do all this stuff and, you know, wanna have it be easier. Then you can push out from there. You know, first make your existing customers happy, then go get all the customers you couldn't get before with the new capability. That's very much the philosophy. Do you wanna speak a little bit to the healthcare area? On the question around healthcare, there are interesting opportunities there, and we have a few good, you know, customer use cases that we've already seen in action. I would say, you know, both in the payer and provider side of healthcare, probably more traction on the payer side. We're in a lot of the Blues across, you know, the U.S., for example, Humana is a customer that was referenced on the Fortune 500 slide, and they're kind of. I'll just give you a little bit of example of what they're doing 'cause I think it carries over to a lot of others in the payer space. They are, they're kind of leading the market in adopting what they're calling this interoperability standard and really looking for how can they stream data both, you know, data internal to Humana, but also, kind of in and out of Humana to achieve better efficiencies, but then also really optimize things even at the point of care. For example, they're streaming data to their home care, home healthcare providers. When they walk into, you know, a patient's home, they can diagnose, okay, what was the service that that patient recently received, and then they can get real-time contextual data that says, "Okay, this patient just had a hip replacement. You need to look at this home to make sure, you know, do they need a ramp? Is there a railing so they can get around?" That's a pretty cool application that's built on Confluent. They're also taking in, you know, pharmacy data and claims data. I think in the payer space, we're seeing a lot of, like, interoperability stuff kind of in and out of companies. Walgreens is another one that talks a lot about how they kinda deployed the vaccination this massive vaccination effort, you know, when vaccines first came out and how they had to take in data from external sources. We do have a number of hospital systems. I'm not sure who's referenceable, but a number who are leveraging Confluent as well. I wouldn't say that today, you know, the kind of payers and providers, maybe insurance more broadly is a top five or six industry for us. A lot of opportunity in healthcare as they continue to transform. Hi. Derrick Wood at Cowen. Thanks, great presentation today. Jay, you mentioned additional growth opportunities as you productize use cases upstack, and I'm just wondering what that looks like. Are those, you know, kinda industry-built solutions that could come down the road, more application frameworks that you could release? If you could elaborate a little bit on that. And then, Erica, you know, there was a demo I saw that was like a knowledge bot that basically sent alerts to account executives when a customer in the cloud, you know, turned on a new connector or had a new use case, and it alerted account executives via Slack. And it just made me wonder, as customers are in the cloud, do you see increased productivity out of sales reps? Does that accelerate that roadmap to, on a cross-enterprise connectivity, the central nervous system? You know, just curious how cloud is helping shape productivity and cycles. Yeah. You know, there's a ton of use cases, you know, virtually all of those could be productized in some way. When we think about, "Hey, what would we really realistically go after in the near term?" What's most compelling are the ones that are not industry specific, but are actually common across our broad customer base. The reason for that is, you know, first of all, that's where we have the, you know, focus and knowledge, and secondly, we can kind of take it out and sell it as part of our normal sales motion. Like, streaming pipelines, these kind of real-time data integrations, that's an obvious use case. Stream Designer makes it very easy to do that, right? When we look at what are other opportunities that we tend to fit into, you know, IoT, real-time analytics, use cases around logistics, use cases around, you know, kind of more data-centric streaming apps, there's a lot of these patterns. They tend to be a little more technical in nature, but those make sense to go after first because we can take them out to all the customers. When we think about, you know, kind of verticalizing more for industries, you know, we don't start with new products. You know, we start more like, "Hey, how can we get a little smarter about financial services? How can we get a little smarter about the tech companies?" Kinda show them some of the patterns that are in place and sell more effectively. I think that's a little bit more of it. You know, Erica or Stephanie could probably, you know, address it in more detail as well as the other question. Can you hear me? Great. To Jay's point, we have made a concerted effort to focus on those, what he's calling, referring to roughly as these horizontal use cases, those more technical use cases first. What we're doing on the vertical use cases, and I'll inject a little humor. When I came here, I said that use cases are infinite, and now I can't sleep at night because the use cases are infinite, and we need to focus the sales team and the marketing motion on key use cases. What we do is we look and we prioritize those vertical use cases as well as the horizontal out there based on a lot of different input. One, we can start to look at, like, product telemetry and things that our customers are doing that give a signal around use cases. We also look externally from a marketing organization at search engine information to tell us what people are trying to solve for their problems as in terms of the key audiences. We work very closely with our ecosystem too. What are they getting from there, particularly the CSPs, in terms of the primary use cases. Right now, we have a couple key vertical use cases that we are working together with the CSPs, based on target accounts and our focus there and the usage that we're already seeing. For example, we have a good footprint within financial services, particularly within banking. How can we take all that best practices, all that learning, package that up for them to get other banks started faster on Confluent Cloud? Derrick, I'll take your second question just around the knowledge bot that you saw that kind of alerts our account teams to different consumption patterns or activity in accounts. That is something that's in use. It's kind of in early stages, but you're exactly right that with a managed a service, you know, a cloud offering, we should be able to be really intelligent about how our customers are using our service, and then be able to kind of recommend the next best action for value or identify opportunities to optimize performance or streamline their environment. I'd say that's definitely been a big focus area of ours. As we've kind of tried to up our consumption know-how across the teams. We've equipped the teams with dashboards. We've equipped them with playbooks on, okay, this is what you look for, and then this is the next best action that you drive. Very much so. It should enable us to be more opinionated, more efficient, and deliver customers a lot of value 'cause we can see what they're doing. Brad Sills over here. Can you hear me okay? Yep. Thanks so much for a wonderful event. Brad Sills from BofA Securities. Wanted to ask a question about some of those customers that get to that $5 million, $10 million level ACV. What went right in those accounts? I mean, was it just a certain persona that you got to early? Was it sold through a cloud-native marketplace that helps kind of grease the skids for more expansion activity? Was there certain executive sponsorship? We can see the expansion activity on some of those slides. You got to over time. Really, what went right in those accounts from a go-to-market standpoint to really drive that kind of adoption within some of these larger accounts? Thank you. Yeah. I'm happy to take that. It really is a mix of the bottoms-up and the top-down, you know, the product-led and then the kind of the enterprise motion. The reason being is we want to be running these parallel streams of, you know, with the bottoms-up motion, kind of building out the capabilities within the account of developers and architects who know how to build applications leveraging Confluent and, you know, get to that platform stage. Meanwhile, we want to be working with economic buyers and line of business owners, to talk to them about what's possible in terms of what are the use cases that might need, you know, or see value from real-time data and how could they or maybe already using Kafka, and how can they leverage those for Confluent. We wanna be doing both at the same time. You know, for the first, in terms of building out developer capability in the account, we have lots of tools to do that. We'll bring in, you know, a lot of our technical folks to run, you know, big workshops and really skill up people. Meanwhile, we're taking those use cases to the different economic buyers. Of course, you know, working with our partners in those accounts as well. Maybe, you know, we'll go to market with one of the cloud service providers who's working on, you know, the next kind of workload migration to the cloud and partner with them to be a part of that solution. Hi. Phil Winslow, Credit Suisse. Question sort of actually following on the last one about sort of how to drive that velocity and network effect inside of existing customers to get them up to size. When I think about the one of the announcements, you know, this week was Stream Designer, that seems like a potential accelerant of that, looking for new personas. I guess the idea I had was sort of the more streams, the better, the greater the network effect, the more personas, etcetera. But how do you see potentially that being accelerant? Is this the right way to think about it? And then one follow-up to that. Yeah, I think that's exactly right. When we think about our efforts, there's kind of a key paradigm shift towards streaming in real-time. You know, early on, as Confluent was getting started, only like the biggest tech companies could really take advantage of that because they would have to, you know, spin up some huge team to run it, so it was operationally difficult, but then it was also difficult to take advantage of it. They would have to, you know, put a lot of software engineering in baking this into each of their applications. When we think about Confluent's efforts, it's really to make it easy, right? The same value, same paradigm shift, but, you know, without all the investment. On the operational side, that's cloud, right? Just take that problem away, do it for them. On, you know, the development capability side, cloud doesn't solve that. Just because you're getting it as a service, it doesn't mean that you automatically can put this into practice for all the use cases you have. You still have to do that work, so how can we make that easier? That is about that climb up the stack. You know, I think really in terms of kind of three layers to the cake, you know, the lowest is the core of Kafka, which just takes these streams, multiplexes them, stores them, allows you to kind of go back in time and consume them. The next layer is that ecosystem of connectors and stream processing capabilities. The connectors are critical because if you can just plug into all the systems you have and get the streams, and you don't have to do custom integration work, that's all code you don't have to write. The stream processing capabilities make it really easy to build applications with small amounts of code, you know, SQL, things developers already know to take advantage of this. The third layer of that cake is the kind of higher level interfaces, right? If we say, "Hey, sure, this is a general purpose platform for data streaming, how can we specialize it for pipelines and just make that really easy so it's like no code?" That can make you go even faster. The reason we started with Stream Designer, in terms of use cases to go after, was because the way we think is about that network effect. How can we unlock the most data the most quickly? When we sorted all of our use cases, we thought, "Hey, data pipelines, it's not necessarily the most valuable, critical thing, but that's okay," because they build the critical applications over time. They'll build the inventory management system, they'll build the next generation risk system. They'll build all of that once the data is there and starts to pull in those use cases. How can we seed that network effect as quickly as possible? It's make the pipelines easy. That motivates a lot of data flow, that gets a lot into the platform. It's a low risk thing to start with, you know, if you're just dipping your toes in the water in this area. Yeah, when we were thinking about these higher level interfaces, that was why we started there, and we're very excited about what that can enable over time in terms of allowing our customers to move faster. Got it. My follow-on to that is about governance. Sort of, okay, go fast but stay in the guardrails. I think, when you think about governance, how much does governance and the enhanced capability there play into what you did? Which is just- Yeah. It is directly connected, you know. Like, I guess back in the day, Facebook, it was, you know, move fast and break things. Like for most companies with data now, it's, you know, move fast and don't break anything, right? Those things are in conflict. It's not enough for us to just be an infrastructure provider and say, "Hey, you know, we're gonna allow you to stream data really quickly. We're gonna allow you to process it really quickly. We're gonna allow you to connect across the organization." If we don't provide you the tools to do that in a way that's safe. That's correct, and that's dependable, and that is in compliance with all the rules that you have, and that is observable and visible in terms of what's happening, then you're not really gonna be able to do it. You're not really gonna be able to unlock it. That central nervous system vision, that won't really be possible for you. Yeah, you know, that is probably the most demanded set of features from our customers, is, you know, the streaming stuff is taking off, and they're like, "Okay, great. Now we need the visibility and the protection that allows us to really do this, at scale." You know, I think that actually ends up being a great enabler as well. When you think of governance, you think of it as, oh, it's preventing bad things. Actually it's enabling broad usage of a platform. To unlock something across a big development team, you have to have some of these things in place. You know, for some companies just because that's common sense, but for other companies because that's the law, and there's a set of regulations that they have to abide by in how they use things. These capabilities are actually quite important in motivating usage and making that something that's, you know, the easiest, most obvious way to plug into the data flow of the company. Just one follow-on to that. It really goes back to the nature of the workloads that we're doing. These are core operations that companies are using to run their business. This is not like an analytics play or just a database play. These are core operations, and that's why you need the governance related items that Jay's just said. They need the security that we bring to the platform, and it's because it's these core operations that are being run to run the business. Hey, Ryan MacWilliams from Barclays. I wanna get Chad Verbowski involved and actually, you know, follow on from this question just a little bit. You've worked on kind of really big platforms so like with Bigtable, et cetera. Like, from what you see at the moment, like, where do you think you're going to spend your time in terms of driving the product further? Because, you know, I can see the compliance angle, I can see the scalability in the presentations today. Where are you going to focus your time? Thank you. I think that our focus is obviously in a few areas. The streaming piece that we've built, we've got to keep investing in that to make sure that it scales, it's easy to use, and basically that every piece of data that you have, it should obviously be flowing through what we've got with streaming. We think we've got a lot of that with our Kafka start in the ecosystem. I mean, our biggest competitor probably is just getting all of that stuff put into our Confluent Cloud, and I think we're making great inroads there. Part of it is making sure that that keeps going forward. I think ultimately, when you deal with large amounts of data, it's really about making sure that those connections are easy to use. We're gonna keep investing and making sure that we can speak with all of these other data systems through that connector ecosystem, so that anyone can discover all of the data that's available to them, and they should be able to securely use that and build an application. If I think about where these biggest problems are from my experience in various companies and various products, it's really that people problem. How do I figure out where is this piece of data that I know I need, and where is that clean, secure, proper location of that data that I should use? Because oftentimes companies might have five copies of this data in a table. The first one's the raw piece, the second one that's cleaned it up, the third one is the one that we've barely validated and tested. If you're searching for the right one to use, how do you know which one it is? That's why, again, as Jay was saying, these Stream Governance pieces are supremely important. The fact that you can discover data that's in any of your systems, that you can just get access to it directly or figure out even who owns it, I think that is paramount to enabling people to work with data at scale. Some of that is infrastructure that we are of course going to build. As you can see here, there's a partnership part where we're gonna make sure that we're partnering with all of these providers and all of these other systems so that that integration is seamless. Customers shouldn't have to see these boundaries between these parts, and that information should flow very freely. I think that's a piece that I wanna focus on for our innovation. Sanjit Singh, Morgan Stanley. Thank you for the program today. It's been super helpful and informative. I wanted to talk a little bit about the sort of lines that are blurring between the data platforms trying to also become application platforms. If you look at some of the players, not just through the purview of like the hyperscalers, but if you look at the Databricks of the world and Snowflake's of the world, they're using M&A to build more, you know, win over the hearts and minds of developers with new application tools. In that context, I wanted to get both Chad's view and Jay's view of if that's sort of the battle lines for the next 5-10 years, what's the case for data streaming remaining a sort of standalone capability or product market versus something that gets subsumed within a larger data/application platform? Yeah, maybe I can take a stab at that, and you may have a view as well. You know, so I think if you look at what's happening with streaming, that's a paradigm shift that I think is affecting almost everything that touches data, right? The operational databases are developing capabilities to produce out a stream of what's happening in them. You know, the SaaS world is building connectivity really both for ingest and kinda egress into this area. You know, a lot of the analytics platforms are getting the ability to kind of take streams faster into them. All of that I think is very positive for us. You know, when we think about, hey, what are the boundary lines likely to form around, I think it mostly is, hey, what's the problem that you're solving for the customer? You know, I think there's a very big difference between being an operational database, being a kinda data science or analytics or reporting kinda warehouse platform, being some SaaS application, and then what we're going after, which is the central nervous system and that ecosystem of applications that's around that and kind of in that real-time reaction area. You know, what's different about it? The workloads are different, the people doing the work are different, the personas are different. The kind of needs from the product are quite different, like how does it perform? How does it do well? If we look at, you know, what's happening in that whole ecosystem, I would say, you know, there's obviously interest in broadening capabilities. But if anything, what you're witnessing is probably additional diversification. You know, the rise of cloud means a lot of the burden of adopting new capabilities has gone down. You know, you no longer have to operate a net new database if you get a new thing. I think if anything, the world's getting more diverse across more clouds with more systems. The importance of being able to tie all that together, that central nervous system, that's really our role, and that's what we're going after. The fact when we look at streaming showing up everywhere, there's obviously some workloads that could push back and forth between operational databases and, you know, the data streaming platform. There's obviously workloads that could be done on a data streaming platform or could be done in some vertical SaaS thing often built on top of that. It's true in observability, it's true in security, and there's definitely workloads that could kind of come back and forth between the analytics world and us. I think the case for that being a standalone thing is really the role it plays in connecting all of those together and the kind of personas and people and use cases that you end up serving. I think the reality is today we're seeing, you know, more specialization and extension. I think it's a little bit like if you think about the SaaS application world, it went through a similar translation, right? Maybe on-premise, there was a relatively concentrated set of big enterprise applications. As you move to the cloud, you definitely see some big conglomerate ones like, you know, the Salesforces of the world, but it's not like you see some collapse where everything is just Salesforce, a feature in Salesforce. You actually see a diversification of more use cases. I think it's very hard to be the connective tissue between all of that if you're also one of the kinda destination systems because it just isn't really your nature or your real focus to help enable all the other things. You know, I think that's kind of what will help, you know, set these dividing lines. It's true that that whole ecosystem is unfolding, so it's a, you know, it's a wild world that will look different five years from now. I feel very secure in kind of the position we're building into in that. You know, Chad, of course, worked on a data warehouse and can probably give a good, you know, good answer as well. Yeah. I think there's a fundamental engineering reason of why that we're in a better position over Snowflake and Databricks, for example. I'd like to draw a comparison to help illustrate that point. If you look at, say, 10 years ago, who you thought were the biggest data analytics providers, Oracle, which must own 40%-45% of that market, Microsoft SQL Server, you think about Teradata and all of these other systems. With the cloud, if it's so easy and they have literally decades of experience and it's software, why didn't they just run it in the cloud and win? Why is Snowflake so successful? It's because when you wanna make these paradigm kind of shifts, when you wanna move from on-premise to the cloud, what we learned is that all of those companies optimized for that on-premise kind of thing. They built 80 million lines of code, and they have thousands of customers that depend on it working in a certain way because everything that uses that system requires it. When Snowflake and all the other cloud-based ones, Databricks, et cetera, moved along, they said, "Hey, we can do that better." It's still batch, still batch processing. They end up bolting on these streaming pieces to get that data there in real time. Fundamentally, when they're working with data, the literally millions of lines of code that they have are treating it in batch. The real question is, do you think Snowflake and Databricks are gonna throw away all of what made them successful today and rewrite that with the many years of experience, the literally millions of engineering hours we've spent to be streaming right from the core? I think that's the fundamental issue. They're gonna have to keep investing in this batch part 'cause it's core of their business. They're gonna bolt on some streaming to do the best they can to make this work, and we have the opportunity because this is what we've built from the start, is to keep evolving and expanding into those streaming use cases because that's at our core. The second thing is we also collaborate very closely with them. All of their data has to come from somewhere, and that somewhere is typically some kind of a Kafka system or a tool that's built on top of Kafka. We've got kind of the first crack at making these customers that are using some Kafka infrastructure build some real-time applications. All right. We have time for one more question, then we'll go to our customer panel. Rudy, go ahead. Great. Thank you. Rudy Kessinger, D.A. Davidson. Appreciate the presentations today. I wanted to ask, you know, you gave the bottoms-up TAM analysis, which I appreciate. I'm curious on the Fortune 500 customers, you said on average you think, you know, they represent a $10 million-plus ARR opportunity. Where do you derive that figure from? Is it based on your visibility into, you know, what they're spending on open source Kafka and analysis of, you know, what they're spending currently versus where they're at in the customer, you know, adoption journey? Where do you get that $10 million figure? And then secondly, Steffan, I don't know if there's any finer point you might be able to give, you know, what percent of your revenue comes from those Fortune 500 customers. We can make some assumptions with some other figures we have, but curious if you could touch on maybe where you're at in terms of penetrating those 172 that are existing customers already? Okay. Yeah. Yeah. When we looked at that, we're obviously looking at, hey, what you know, we have some view of what the maturity curve of one of those customers looks like, right? It takes some years to kinda get to that, right? Any of these infrastructure layers, you add use cases as applications kind of naturally turn over, and that happens over a number of years. You know, the way we came up with that was if you look at that curve for some of the customers we've been working with, and you look at what the opportunity is to kind of spread and start working with all of them, and then where do we think that would kinda start to cap out? Where do we feel like, okay, you're getting to good penetration in the customer. Yeah, that's how we came up with, you know, a view of what's possible really in each of those segments in terms of average customer size. I'm sorry, there was a second part to your question. Yeah. Just, I don't know, Steffan, if there's any other, you know, details you could give. I know in the past, at one point you shared what percent of revenue was from your Fortune 500. Obviously, not all of them are over $1 million currently. You've got 172 Fortune 500s, only 107 $1 million ARR customers. I'm curious if there's any other details you could share as to what they represent currently. Yeah. We don't break out the percentage of revenue coming directly from the Fortune 500. What I can tell you is when you look at the cohort of customers that are spending more than $100,000 in ARR, that accounts for right around 85% of our revenue. The Fortune 500 would be a subset of that. I think that one of the biggest takeaways is, as you've heard from the different presenters up here, even in our largest accounts today, we still have a lot of wood to chop going forward. We're nowhere near being fully penetrated. The opportunity that is in front of us is much larger than what we've already booked, you know, today for nearly all of those accounts. Okay. All right. That concludes our Q&A session. We're gonna now turn the mic over to Stephanie, who is our Chief Marketing Officer, and she's gonna conduct a customer panel. Awesome. Thank you. All righty. Thank you all for hanging in there. It's great to be here. As I said, as Steffan said, I'm Stephanie Buscemi. I'm the Chief Marketing Officer here at Confluent, and I'm excited. I've got two wonderful customers here to have a little fireside chat. No fire, but the chat. I'm gonna introduce them, and then we're just gonna dive in. We're gonna go through. I'll lead with a couple questions just to kinda soften the ground, and then we'll open up for all of you to ask your questions as well. With that, if Brian from DISH and Andrew from New Relic can come join us on stage, let's give them a round of applause. Thank you both for being here today. Are you enjoying the conference? Yeah. I am. My pleasure. Good. It's great having you both. We'll just kinda do a little bit of speed dating here, a couple questions. First, I think it's just great context for this room to know a little bit about each of you, like where your role today and a little bit of your background. Don't be humble right now. Give a little bit of your background and experience so they have context for how you're thinking about data streaming and Confluent. We'll start with you, Brian. Sure. Brian Mengwasser. Very nice to be here with all of you. Thanks again for the invitation. Yeah. I work in the network technology and architecture team at DISH Network. I'm specifically focused on exposing functionality that we've built into our network and cloud in order to create a platform and build an ecosystem of what we call network apps on top. The first time ever, we're actually planning to allow our customers to control the network that we're providing to them. A little bit about my background. I've had the opportunity to work prior to DISH in a number of data-centric roles at both large companies and small companies. Large companies, you know, multinational telecommunications, you know, high tech satellite companies. Then I've also built some companies, founded a remote sensing data generation startup. Data is kinda the common thread for me. You know, we know there's value there, but how do we use it, right? How do we exploit that value? Unlocking data. I love it. Okay, Andrew, tell a little bit about yourself. Awesome. My name's Andrew Hartnett. I'm a Vice President of Engineering at New Relic. I lead a group called the Core Data Platform. We're the largest engineering group within New Relic, and we're responsible for all of the data ingestion, data munging, otherwise making it available for customers to then query, products to query on top of it. In the past, you know, I've been in the cloud and hosting space for a lot of years, mainly the last 10 years or so, you know, in the intersection of data engineering and security, and have been a Kafka user for many years. Fantastic. Tell us a little bit. We'll dive into each of your organizations. Let's start with you, Andrew, and tell us a little bit about New Relic. I think people might pretend they know, but they don't actually know. So orient the room here, New Relic's mission and then some of your business priorities. And then correct me if I'm wrong, but I think New Relic is in the top 20 largest Kafka users out there. Is that? Yes, we are. We're heavy Kafka users. We have been running Kafka in production since it was pre-1.0, you know, dating back 8 years or so. That's another subject we'll talk about in a little bit here. You know, New Relic is an observability platform. We give, you know, developers, operations folks, product managers, data scientists, whoever needs it, the data that they need in order to solve the problems that they're trying to solve. We are a company that is growing month-over-month very rapidly, and that's part of our reason why Confluent Cloud was something that we chose. That's fantastic. Thank you. Brian, tell us a little bit. I pretended when I first talked with Brian that I knew what DISH did, and he's like, "We are so much more than the dish outside your house, Stephanie." Tell us more about DISH and your business priorities. Well, to be fair, it's changing a lot in the past few years. You know, most people are probably familiar with DISH from a television video broadcast and, you know, let's say existing lines of business. I specifically work in what we call DISH Wireless, which is our newest division. We like to call it a $10 billion startup because we've committed to spending that money to build out the network. Fundamentally, DISH is a communications company, and so we're always trying to think in advance about what kind of communications is coming, how is that landscape changing. More and more we see that the motion of communications is between devices or apps and the cloud. One way I like to think about DISH Wireless is that it's a communications initiative which specializes in moving data between the cloud and the devices and, you know, in order to facilitate that value. You know what you may know, what has been discussed is that this is, you know, built on 5G technology. Lots of, you know, ways that we're changing the technology to make it more suitable for this purpose that I mentioned. I don't think it's an overstatement to say that we've rewired and we're reinventing the cloud and communications to bring those much closer together. In addition to enabling the types of communication that we see in the future, our priorities are to parallelize the innovation in communications, right? It should be easy to communicate between different devices, and unfortunately, that's not where we believe we've been in the past, but where we wanna go. We're also pushing for a much healthier ecosystem, you know, where you can actually be involved in the way that your data is moving around, you know, from a networking perspective, rather than be subject to this kind of black box. "Oh, I have to communicate via the network." This is what we're doing in this initiative and, you know, some of our priorities and focus. You said to me when we were talking about, you know, the mission really of connecting people and things and, you know, this lofty goal really here about reimagining kind of connectivity or how connectivity works. Can you talk a little bit with this group about the role of data streaming against that lofty goal? We'll come on to specifically Confluent. Sure. I think telecommunications provides an interesting perspective to data streaming. Obviously we're thinking about data streaming from, you know, a Kafka perspective and extracting value from, you know, back-end systems. From a telecommunications perspective, we're moving data all the time. In a sense, the only thing we do is data streaming, because it turns out you can't make a call, you know, in batch, right? We're doing this at titanic scale, right? We measure in hundreds of petabytes or exabytes per day. My take on this from the telecom perspective, and I think one of the main reasons that I'm here and, you know, motivated in this partnership, is because I'm thinking in the future about what kind of communication modalities we're gonna see, right? As we're seeing more machines communicate with other machines, right, we're seeing changes in the way that we're, you know, moving data from devices to the cloud, as I said. There's a real scenario where, you know, WhatsApp and Facebook and, you know, video streaming doesn't dominate the communications landscape anymore, right? Is there a scenario where 5%, 10%, 20% of our network are devices and apps using a Kafka type mechanism? Absolutely. you know, again, we're not here to say, "Oh, it has to be this way or not," but we are here to enable that, because the last thing I wanna do is get in the way of connecting devices that are speaking over Kafka, for example. Thank you. That's super helpful. Andrew, you were one of the, as you stated, earliest Kafka users. Maybe talk to this group here a bit about the shift from going from, you know, migrating from an open source to looking at Confluent. Kind of help us with what was hard about doing it on your own with Apache Kafka, and what actually sparked for you that confidence and movement to Confluent Cloud? That's an interesting question. I'll start with the pain point that we came to is we were running at the time the single largest Kafka cluster in the world trying to keep up with our growth in a data center. The reason that we initially discovered that we just can't do this anymore was we were running out of physical space. We literally could not grow our cluster any bigger than it was. I would have never put that on my resume anyways, having the single largest Kafka cluster in the world, but it was an architecture when I came on board that we were dealing with. The pain points forced us to make a decision. You know, there was. When I was actually a customer of New Relic, 2017 and 2018, there were some dark days for them. They had some pretty significant outages that were around, you know, issues with open source Kafka being on such a new version. And, you know, they again, they got to the point where they couldn't grow, they couldn't upgrade to take advantage of the reliability with new versions of Kafka that come out. And it was, it's a headache. Unless you are prepared to spend a massive amount of money on large teams that support Kafka 24/7, it's very, very difficult. That's what we were doing at the time, was trying to figure out how we could do that. What we discovered is that there's a better way, and moving to a fully managed Kafka service, like Confluent Cloud, was our decision. You know, we went through sort of an intermediary step, but you know, what we've discovered is this is the sort of partnership that we need, both technically and culturally, to be able to solve our problems. Very helpful. Brian, you are on a similar journey, where you're using the open source Kafka and you are migrating some workloads to Confluent. Maybe talk a little bit about why that is happening. What were the limitations with open source Kafka and then your decision to actually move to a fully managed service? Yeah. We use Kafka in a lot of different ways. Some of those ways are embedded in products that we're consuming from our other vendors. Just to put numbers to it, we're looking at 3-4 petabytes per day. So it's extensive. I mean, it's embedded. So when we start thinking about, okay, that data's there, it's streaming, but how do we start to reap the value of it, right? We started thinking about, well, we wanna create data products. Actually, we wanna unlock our network to enable our partners or developers to come build data products with us. How are we gonna transact those data products? Well, it's probably not gonna be something that's sort of locked down and embedded instance of it. It needs to be more open, right? It needs to be something that we can transact with thousands of our customers and developers on. It became clear that we needed to have a different instance. As far as the decision to build that instance as an open source versus Confluent, there was no question, right? There's such strategic alignment with where we wanna go in the future and how big we see, you know, data streaming as part of our overall, you know, communications portfolio. I specifically remember being in the boardroom saying, "Well, we could do it, but that would be silly, right? Because we've got other things to do, right? Let's focus on our business objectives and, you know, bring an expert partner in to help us facilitate that. That's fantastic. Can both of you, each of you share maybe a use case today within your organization, and then even I think everyone here is probably trying to imagine the art of the possible in terms of what are some things we can do in the future too, with data streaming. Brian, maybe I'll start with you in terms of how are you using it today, and then let's sort of talk about the art of the possible here, where it could go, particularly in an industry like telco. Sure. The primary way I'm driving our teams to use it is because we're an online system. It's critical infrastructure, it's hyper-distributed. I have thousands of operators, and by operators I mean software, making millions of decisions every second, right? Like filter these packets over here, decide to communicate on this particular frequency band over here. All of those operators are having to make, you know, real-time decisions. The only question is whether those are gonna be some sort of policy-based or rules-based decision, or if we can bring enough information to those operators, can it be an intelligent decision? That's how we're trying to internally benefit from, you know, better ways of federating, distributing data, so we can make data-driven, intelligent decisions rather than rules-based ones. In terms of where we wanna go externally, and again, this is my primary focus, we talk a lot about, you know, different verticals or use cases, and we partner with, you know, some large companies on these. I'm thinking again, from a communications perspective. Let's take a scenario like a public safety first responder kind of scenario, where you have, you know, ambulances, fire trucks, you know, responding to a particular scene. We don't know exactly what's going on. There's a dispatcher somewhere, but, you know, these first responders are converging in order to provide aid. They need information, right? What have we learned so far about the incident, right? Maybe a helicopter comes overhead and, you know, they can be providing some information directly. It's easy for me to envision multiple, you know, communications modalities where all of these vehicles are connected via cellular. Maybe some of them are connected via satellite backhaul or Wi-Fi or Bluetooth in the vehicle. But actually, from a data layer perspective, you know, as soon as you have these, you know, vehicles and responders kind of converging on the problem, they need a way to communicate directly, right? They don't need to go back to, you know, some centralized cloud instance. They need to be able to talk to each other and just by the virtue of that they're nearby, you know, or there's cameras nearby in kind of a smart city scenario. You can start to benefit from that information in a much more elegant way. When we work on this use case, we said, "Well, why don't we make it Kafka first?" Because it makes more sense for the application to be Kafka first, and then we can communicate the intent to the network. Oh, yeah, you know, I want to be able to communicate between these devices. We can worry about fulfilling that. In my mind, there's no reason why, you know, a public safety provider of equipment should have to go to Confluent to buy a cluster and then come to me to buy something like a SIM card, right? Why don't we make this much more seamless and frictionless? This is a real case that we're working on right now. It's really exciting. It's a fundamental shift on the communications, just cutting across devices, systems, all of it, potentially with Kafka and data streaming. Andrew, tell us a little bit about your use case now and where you see it going. Sure. I'm gonna steal a phrase that Jay used, and that is Kafka for us is our central nervous system. Everything, all of our services, all of our products, all rely on Kafka as our streaming mechanism. It's part of our DNA. It's part of every single thing that we do. I can't overstate that. Basically, you know, the way that New Relic works is we take data from around the world. I think we're at about 7 billion data messages a minute that we ingest from IoT devices to browsers to point-of-sale devices to, you know, any of the infrastructures or data streams that come from any of the hyperscale clouds, from people that are running agents on their own data centers. All that data is coming through, and we need to be able to ingest it in a timely manner and get it into both rest and streaming options in order to serve different products and to give the data to our customers. It really is, you know, a core part of everything that we do. It's about pushing it out to the customer and unlocking. That's right. More value for the customer. How quickly can we get that data to our customers? Some customers need the data real-time, and some customers would like to look at it over a historical span, right? All sorts of different use cases for data coming through Kafka. Fantastic. I am gonna ask Shane if he would like to make one last round with the mic, and we're gonna open up for some questions here on the floor for our customers here at DISH and New Relic. We have one up here, one there. Hey, Eric Heath from KeyBanc Capital Markets here, and appreciate you guys doing this, Andrew and Brian. It's really helpful. I guess for both of you, I'd be curious to hear, it sounds like, Brian, you also made the Kafka to Confluent decision as well, but, Andrew, you definitely did. Can you walk us through kind of what your Kafka team looked like from what was your headcount for your Kafka team? What was essentially, I guess the How did you reallocate these folks once you kinda moved to Confluent, if you will? And how do you look at it from like a TCO perspective in terms of more of a hard dollar situation in terms of looking at the difference in cost, if you will? TCO was not something that I brought up earlier, but that is one of the key reasons as well. When you are having to manage Kafka 24/7, it can get expensive. Recently having some conversations with colleagues of mine and at LinkedIn and at Facebook talking about Kafka. The size of their Kafka teams are large. We had a very large team. I think we were up to 16 at one point, which was total operations. Hands on keyboard, monitoring Kafka every single moment of the day. It was something that we needed. By moving to a managed service, I was able to redirect pretty much that whole eight to 16 people to move on to something else. At New Relic, we generally hire software engineers that have specific specialties. We had some very heavy, you know, Kafka operations specialty that we didn't need anymore, and moved on to different parts of the company to work on different things. You know, what we really wanna get to is having our engineers provide value to our customers, and being Kafka experts was not providing that value. We had a slightly different scenario because of how aggressive our schedule and ramp-up was. Still is. For us, it was not so much about what's the existing team, can we reallocate them and so forth. It was more like, how do we get going as quickly as we can? I think we estimated we would need to build a team of 20 engineers to support Kafka the way that we were intending to use it, even in, like, first generation. In 18 months to actually launch the network, we don't have time to think about building this team and getting it set up. Again, back to where is it best for us to spend our focus, it's more on what data products should we be publishing, not are the clusters working, is the reliability what we want? I think we pushed Confluent pretty hard on the idea that we're trying to build a five-nines service, so we need the best expertise that you have to help us build fully HADR extremely reliable systems. Again, I would much rather find that in a partnership, someone who's willing to come with us and grow with us rather than spend unnecessary cycles building a team when we should be focused elsewhere. Yeah. I'll share another story here, and that is when we originally did the POC with Confluent Cloud a while ago, our goal was to break it, right? We had worked with other providers, and we knew how to break things very, very well. My goal was I wanted to see, okay, you know, how is their support organization? That's where I wanted to get to is I wanted to break it, and then I wanted to see how quickly the support organization was gonna be able to come up. Now given more time, we probably could have broke it, but we could not break it. It was one of the things that sold us. We had, you know, with past providers, we had many things that we knew could topple over Kafka, including ourselves, when we were running it. That was pretty great. I see we have a question back here in the room. Shane, can we? Sorry. Hopefully I'm not the last question. Andrew, on that note, like, the breaking part, do you think they kind of engineered on the cloud version the Kafka better? Was it like a slightly different version of Kafka that enabled them to be so scalable that you couldn't break it? Or is it just like they optimize how to run the stuff in the cloud because that's their job? Then how difficult is it, if you think about it, listening today, it just makes total sense to run it in the Confluent Cloud. What are the hurdles to kind of move over? Like, what are your experience of kind of trying to kind of move from self-supported to the cloud? Like, how difficult is it? Thank you. Yeah. I think your question was around, you know, either how hard did we try? We did try. Like I said, we had runbooks that we could tell have knocked over competitors and knocked over ourselves previously, and we could do it. We ran those same ones and then cranked it up. As a matter of fact, a couple of their architects tweeted at the time that, you know, their throughput was more than they'd ever seen before, and the cluster was still totally fine. That was a fun little experiment there. From my perspective, I'll add, as I mentioned, we're more like a cloud than a telco, so we embrace that mindset. From the earliest days that we set up and we turned on Confluent, we've been running chaos testing against it continuously, and we will, because it's important for us to know how it's working currently to control for drift as we're making changes to our network. You know, we'll find ways of using it or breaking it, and so on and so forth, but if we don't know that, we have no hope of adapting and, you know, achieving the targets that we have from a performance standpoint. I have one more thing to add, and then maybe that's the last thing, and then everybody can go. One of the major reasons that we chose Confluent Cloud, though, is because our goal at New Relic is to get as close to our customers as we can, right? So that's in every cloud in every region that we can. Getting as close to our customers is better. That was difficult, and we wouldn't have been able to do it. Having that, you know, sought after single pane of glass to have the same experience across clouds, across regions was very important for us. All righty. How are we on time, Shane? Can we take one more? We have time for one more question. I'll give it to Sanjit. All right. One more. I teased you all. I'm really sorry. Hopefully, this will be the last one. I wanted to get your perspective on, we're going into a tougher economy budget environment, and you guys made the case how this is super strategic and operational to how you guys run your business. I just wanted to get, like, your view on just sort of cost and optimizing costs, not just only with Confluent, but also with some of your other cloud consumption sources, whether it's your data warehouse or your database. How do you guys sort of think through budgets and spend when it comes to this category? Well, Brian, you have your own cloud. I do have a couple points around that there. You know, we are constantly looking at reducing COGS. I mean, it's part of every single thing that we do all the way down to the engineering team level. It is part of our core. Now that we're in the cloud, you have to understand that cloud is not free, and you will be charged for it, right? You know, Confluent Cloud is the same way. Looking at tools like, you know, Stream Designer, you can easily see where you're having redundant operations, where you're having services, for example, you know, pull data from the same topic and push it back to the same topic, to be able to go in and say, "This is something that needs to be optimized." We lean on that heavily. We have a very cost-conscious mindset. We're always thinking about that aspect of it. For us, it's very much a zero to one scenario where you know we're building and fielding the first you know virtualized O-RAN 5G network in the world for less than the cost of our peers less than the cost that they pay for maintenance every year. You know, $10 billion's a lot, right? It's really not a lot for building you know fundamentally rewiring the cloud and building a network from scratch. When we think about that, we're thinking very strategically about okay how can we cultivate new vendors into the ecosystem rather than have something that's dominated by three or four, right? Why don't we have 50 or 60? Can we actually use some of the capabilities that we're building in order to do that? I think when it comes to Confluent specifically, we think of them more as a way to increase our value and increase our time to market than a cost optimization. I know, you know, we've been discussing many of our peers thinking about it, you know, is it more cost efficient to not have this team of 20 people, you know, or not? Really for me it's if I can present a much more seamless way for this public safety use case or any of our customers to say, "Look, I wanna run a cluster locally on DISH, you know, Edge cloud," and, you know, we can now run Confluent Kafka covering 20%-70% of the country this year, sub-20-30 milliseconds, that's a fundamentally new capability. We're driving a little bit more towards that zero to one, you know, go to market, accelerating what we're trying to do and be, you know, disruptive, rather than cost optimization. We're certainly, you know, feeling that as well, and I think we're gonna land in a good place. All righty. Well, I wanna thank you both a lot for being here at the conference, your time, your partnership. Let's give them both a round of applause. I will ask them maybe if they can stay a few minutes after around here, so if anyone had a question and we didn't get to it, maybe you can catch them here in the front of the room. Thank you all, and have a great rest of the day.