Confluent, Inc. (CFLT) Earnings Call Transcript & Summary

Hi, everyone. Welcome to Current 2022 and 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 note 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. And with that, let's begin today's program with a quick video. [Presentation]

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. So 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. And 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. So 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 our -- how we're attacking the overall market opportunity in our customer growth go-to-market journey. We'll then convene for roughly a 10-minute break. And then when we reconvene, we will have an executive management Q&A panel up on stage here to answer any questions that you may have. Then post that, Stephanie Buscemi, our Chief Marketing Officer, will be conducting a customer panel, and we'll also have Q&A there. Now 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. And we would like to welcome you all to join us there as well. And it will be great to mingle. So to get the programming started, I'd like to introduce Jay Kreps, Co-Founder and CEO. Jay, welcome.

Thanks, Stef. All right. So I'm going to start and talk a little flavor of [indiscernible]. but I think it's [indiscernible] that makes the most sense. [indiscernible] that we are operating with. I'll recap just a little bit about the space. So we're now at a point where data streaming is out in virtually every part of the economy. And it's powering use cases and customer interaction. It's powering use cases in health care. It's enabling the 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, [indiscernible] and a more intelligent grid that needs to have continuous data about how it's operating. And I think all of these are examples of how software and the role of software and companies is changing. And it's going from productivity applications that might be [indiscernible] edges, 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. And to do that [Audio Gap] All right. We'll give it a try. So the problem that's being addressed now is actually [indiscernible] different. Okay. All right. Yes. So -- the problem that software is addressing in companies now. [indiscernible]. I have a special magical touch with these things. So -- so the problem that companies are addressing is really substantially different. And it's no longer the siloed applications that is really kind of directly interacting with what's happening out in reality. And that involves a very different use of data. And you see that 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 the business, making decisions off of that, driving actions off it. And increasingly, these software systems are just more connected than they used to be. And the reason this is difficult, the reason it's challenging is because the traditional tools that were available to actually power this don't really address that type of usage. 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. And that makes a ton of sense. That's an incredibly powerful back end for applications, but it isn't about how you react and respond in real time. It's not about how data flows across an organization. And then there have been a long history of these kind of point-wise tools built for moving data. This is ETL products, message buses, application integration tools, a wide variety of things. But 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. And 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. And that's what's driven the rise of data and motion of this kind of real-time stream processing visibility to tap into what's happening, capture it, react to it, process it, transform it and build applications designed around this. And the role of this technology in companies is incredibly powerful. And if you're spending more time at the conference, you can hear some of the customer examples. We're going to bring some of those forward in this session, so you can start to get a feel of what people are doing. But in many of the companies that have adopted this at scale, this acts as a kind of central nervous system where -- it's like the nervous system in an animal, it's kind of 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. And it's actually a powerful platform with a set of tools and ecosystem of use cases that surround it. And 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. And 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. And this shows up in the largest companies in many industries. And 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. And so 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. And so it's our belief that all of these companies will end up getting their platform for data in motion powered by a cloud service, and there will be a significant commercial opportunity around them. And that really is our mission at Confluent. This is our focus, is to set data in motion and build this new platform. And we think that this has the opportunity to be one of the major data platforms in companies. And that's the opportunity I want to outline a little bit today. So when we think about data, commonly, the data infrastructure world would be broken into the kind of operational databases and analytical databases. But we actually feel that data emotion represents very much the complement to what's out there today. It's not data where it sits, it's how it flows. And 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. And this platform that actually taps into everything happening across your different apps and knows what's happening in the 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. So 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 3 pillars that we've built differentiation around that we've tried to create our commercial offering around this. 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 a lot of other competing products. And these 3 pillars are: first, offering a truly cloud-native experience for our technologies. 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. So 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 thousands of different customers. This allows them to consume just what they need and scale up. And this is incredibly important in any of these technologies in streaming that are about how all the parts of the 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 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. And 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. And now this is kind of available to every company. And I think that's a very powerful thing. The next pillar is really offering a complete platform. So whereas these kind of silicon die, 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 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. And then finally, we offer this everywhere. We offer it across all the major clouds. We offer it in on-premise data centers and private clouds. And we have technology that allows us to link all of these regions and environments together into one fabric for data in motion. And that's a really powerful platform that uniquely allows our customers to connect their applications across all the places that they operate. And this is a critical challenge for virtually every company today is how to be able to build in new environments, 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 and span all of that. And 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. And this is not always widely understood, but one of the most appealing things about getting this kind of infrastructure as a service is it -- 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, kind of cloud-native capabilities a complete offering. You can get something that's faster that actually performs better on the fundamental capabilities of an infrastructure layer, but it's also cheaper. It's 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 Kafka experts that's being hired away by competitors to run their streaming platform. And 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 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. And that's what allows us to go after this larger market opportunity. And I want to talk a little bit about this. 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? There's these message buses. Is it just that? Is there something bigger happening here? And this is something where we have a very clear point of view, right? And I've expressed that we feel like data in motion, this data streaming platform represents a very significant category. And we're showing here the 2025 numbers of what we think this category can be worth. And I'll come at this in a couple of 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. And 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. How central is this to what they do? How big is the streaming area as a platform for them? 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. But it's not just that. So the other areas of validation come as you start to look at a more bottoms-up model. And 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. So the fact that this could be a broad-based technology that's widely adopted. That's not hypothetical. That is actually the case. And that number is growing extremely rapidly. I showed some of those usage stats in the keynote talk earlier. And so getting to the 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. And so we feel like, hey, everybody who's out there doing this on their own, that is a much harder way to go. And the ability to offer something better as a service means all of this open source usage is migrating to cloud services, and we think we're in a unique position to pick it up. And so that talks a little bit about breadth. The other dimension of this is depth. Hey, how valuable is this? Is it really a major platform? Is it possible to kind of capture this large-scale usage? And here, I think the best data points are our large customers. We disclosed $1 million plus as a cohort. We have a number of customers in the $5 million plus. And so 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. 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. So when you look at this from a bottom-up point of view, 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 dipped their toes in the water. It's on us to continue to drive the breadth and continue the monetization of that. But I think some of these earlier proof points of what's possible here are making it very clear where this is going. The other view on this is, okay, what does it replace? Is it just a message bus technology? Or is there more there? And here, I think, again, you can come at this from different ways. But 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 with thought possible before by making something that's both real time, scalable, transactionally correct. And this is demonstrated by some of the work that we've done recently. So 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. And that's a capability that traditionally was only available on these kind of slow batch ETL systems that's now fully available in the real-time world. And so the breadth of what's possible here I think is very different from kind of earlier generations of technology. And so you can see 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. And so this opportunity is expanding when we look at what we're having the ability to address moving into the future. And then we've proven success across industries. So when we look at our customer base, it spans virtually every industry, and it scales from the smallest most innovative tech start-ups 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. And even within these customers, there is a wide array of use cases. And 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. If somebody claims that they have some very broad data platform that's going to be a big chunk of data usage, they should be able to point to a really broad set of use cases across industries. And 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. And you could drill into any of these individual industries and actually see that kind of fractally within that industry, there's 100 things that they're doing there. And so for this one, we've kind of 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. And so we're going to have to talk through this [indiscernible] who can give a great example of some of what's happening in that space. They are rebuilding a telecom platform, I think, in a really innovative way around Confluent to have some very interesting things to say about what's happening in the space and where that's going. And the way we work with customers is a key part of our advantage. Erica is going to speak to this in more depth. But it's not the case that we need to land with a customer and kind of take them all the way to a central nervous system all in one go. That's not how it works. We land for individual use cases and we expand out from that. We have a way of working with our customers throughout that journey. Starting with a low friction self-service cloud experience and building up to large-scale usage across an organization. And 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. And there's something that helps us that's unique to this space, which is most data platforms ultimately kind of sit as silos. Most databases, they serve a particular application. But this data system is different. This is about the exchange of data across a business. And so there is a very natural network effect, which drives adoption within a customer. And so the first application may come just for the features of our platform, but it brings with it a set of data streams. So in -- retailer, maybe it would be the stream of sales. And 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 the sales data sets. Those data streams attract other applications. And so this is a kind of virtuous cycle that helps spin this up within customers and helps us get them to scale. And 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. And so it really is a disruptive force that's changing how a lot of these use cases work. And so 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. So 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 want to make it as easy as possible to build those kind of real-time data pipelines in a point and click way. And so by releasing that, we feel like we can accelerate that growth with customers and allow them to attack new use cases with less need for deep technical talent, and that's a really powerful thing. So key takeaways here. 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. And 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 is 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. So that's a little bit about this overall area. We're going to 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 going to talk a little bit about our product. Chad?

[indiscernible] innovating in the stream development space. And I think this is critical because in the future. [indiscernible] All right. So to kick things off, I'm going to 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 going to really focus on what we've done that differentiates us in the market. So 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. And 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 5 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 5 years. And what I learned from doing that is 3 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 got to be everywhere. And 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 into any given provider. And so 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. So what I'd like to do is ground us all in a practical example. So 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 MQ Series 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. And as they've made acquisitions over the years, these companies probably made slightly different technology choices. And 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. And when it -- 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. So really, what we think you need is a new paradigm. So 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. And the important part is that you can do all of this in real time. And we think that this takes 3 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 the language that they understand and pull it into 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 it can -- you can collect these things with low latency and with the massive scale that you need. The third thing that you need, it's really the ability to build these stream processing systems on top of this. And 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. So what Confluent provides is the ability to do all of this together in a streaming data platform, and we've built it in such a way that everybody can now put together their central nervous system. So to paint a clear picture of this, I'm going to give you a real-world example of a top 10 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 e-mails. 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. So working with them, we were able to put that system together. It provided a much better customer experience, of course, because we would all rather have prevented the fraud from happening than just reporting it later. And 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. So 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. So 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 0 to infinity so that you can collect and process as much data as you have or need while it's growing. And 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 want to have to have a bunch of excess capacity lying around if you don't need it. And the other important piece about being cloud-native is that you're serverless. You don't want to 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. And we've, of course, got that network of ecosystem of connectors that we've put together. So there's more than 120 different systems that you can connect with right out of the box. And 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-premise, 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 going to find from any of our competitors. Now I'm going to go a bit deeper into each of these 3 to really highlight the differences in what we've built here. The first thing is that we have rearchitected 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. And I think this slide here is really going to point that out. And 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. And on the right-hand side, what you're going to 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. And 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 tax. And they don't have to be the experts in each of these domains. Why would you want to 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 to take care of this. I think this is an area that we have 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 going to 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 Kafka. This meter here really tells you what your usage is, and it's nice and simple. If you can look at this 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. And we give you a nice, simple metric for resources, the CKU, so that you can adjust what you want to use, however you want it. So that you can control, say, how much you want to spend or how much you want to optimize for what you're doing. I'm going to 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 want to 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. And 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 and BigQuery. And 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 could also store it for as little as you want. It's really up to you as to how you want to wake this work. So 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. And what I mean by this is when you're uploading data to Kafka 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. So occasionally, if you get more data of a certain kind in the business, it might make one part of that more busy than the other. So what has to happen internally is something called rebalancing where you decide how that's going to be spread a little bit more easily. Now with what we've built is we enable automatically real balancing this in real time. So this, 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. Now 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 for running this system. The reality is we've been able to offer, because of these redesigns, a 10x better SLA. So it might look like, well, 99.9%, maybe that's good enough. But in reality, that's about 45 minutes of downtime every month. And so I think going from something like 3 9s to 4 9s 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 10x better than any other Kafka offering out there. We have over 3 million hours of engineering that we've 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 worked 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. And this has resulted in us building a system that's 10x more elastic, 10x more resilient, and it allows you to store 10x more data than anything else. And as we talked about, there's a demo booth that we're going to 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. And 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. And 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. And so 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 KSQL, which is our declarative SQL layer for working with and defining how you want to get that processing done. And we also have the security governance tools 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'd 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. So 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 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 want to make this transformation to that data, and I want to 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. So 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. And 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. KSQL is distributed. It's full tolerant. It also separates that compute and storage, and it allows you to build these queries in that fully elastic way. So 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 a 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 [indiscernible] so that if you're not as technical you can build these pipelines and get them running. And 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. And 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 control so that you can view and edit any of the people that you think should have access to these parts. You might want to leave some people to view it so that if they're debugging or they want to understand how things are working, they can see it. But you might also want to 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, but quite often, people will make a mistake. And 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. So 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. So for example, imagine that you're working with the data warehouse and you see a table that has that same problem, your first thing you're going to need to do is figure out where are the files that got inserted to create that table. And that information isn't natively around in the system. And so 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. So 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 that you can use the optimal data sets whenever they're available. The other thing that I want to 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 could even be on-premise. And 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. So what we've built is something called Cluster Linking. And it exists everywhere your data is because it's natively built into the brokers that you have that are just a part of Kafka. And so 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. So what Cluster Linking does is it enables these bite for bite replay of Kafka data between any of these systems. And so you can use these things for disaster recovery, migrating your data or just if you want to 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 a Apache Kafka yourself, it might be very difficult to set up and maintain it too. So with that, I'd like to walk you through a demo of the product. So in this demo, what I'm going to 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. So what we're going to 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 around the city. What we're going to 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. And we're also going to show just a little bit of how these things are connected. This data can be shared through connectors. It can be shared through a map to -- for another application so that everybody can see the positions of these bikes. And we're also just going to show how we can use that Cluster Linking to share this data with another group, say, in Europe. So 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. And 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. And so we know that if we're going to be sharing this data, we're probably going to need to remove that sensitive data. So 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. And 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. So if we're going to share that data, we're going to want to create a brand-new pipeline to filter out those sensitive fields. So we started by creating a new topic. And this topic is going to hold the routing of that bike information that we're going to work with to analyze those fields. The first thing is we're just going to create our new instance of our pipeline, which is the source of this bike data. And you can see here that we're just indicating in that topic which are the schema of events that we want to collect. So now that we have the data that's really the source and our new pipeline that we're creating, we can take a quick look at the different messages that are coming through. So inside here, you can see that every message is from a particular bike. There's the idea of the bike. You can see the latitude and the longitude that's giving that very specific information about the location that's sensitive. So the first thing we're going to want to 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. So 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 want to do is we want to project this data because we're going to grab that subset of information that we want to share. So what we've done here is we're just going to name that projection. And then we're going to go, and we're going to look at all of the fields that are important. Of course, the first one is going to be the identity of that bike so that we have something that we're talking about. The next one is those sensitive fields. So 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. So we did that for the latitude. We'll simply do that again for the longitude. What we're going to do is round it to those 2 decimal places. So we save that. We're going to give a name to this, and this is really defining something that's going to run as one of those KSQL queries. And this is an example of where you could write it in SQL or you could use this visual editor to define those pieces. And then the final thing is we're going to host this data. The results of that data that we're going to share with somebody else, the output of this pipeline, we're just going to call it the clean bike data. And we're going to name those events in there. And 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 want to 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. And you can see very quickly, we've already got our results, the truncated latitude and longitude and the bike identifier. So what I want to do next is just really walk us through how simple it is to share this data with the folks in Europe. So the first thing that we're going to do is indicate that we're taking the data from our U.S.A. source. It's in New York City, and then we're going to configure where it's going. So we're going to send it to Europe. We're going to 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 going to do is just hear that one topic. We're going to name this so that it's easy for anybody else to discover it and see how it works if they need to. And 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 clean bike data and sharing it. And with that, we're done. So what I'd like to give you is these 4 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 want to show you that Confluent is not just 10x better than Kafka, but we're also the de facto standard for all of data streaming. And 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. And then 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. So with that, I'd like to hand it over to Erica. Thank you.

Thank you, Chad. Good afternoon. I'm Erica Schultz. I'm the President of Field Operations here at Confluent. Thank you for spending your afternoon with us. It's great to have you here. So I'm going to 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. So let's get into it. So 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 organizations, many individuals are already using Kafka and are already familiar with data in motion. So 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. And our bottoms-up view supports the top down view that sizes our TAM at an estimated $60 billion. We arrived 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. So for -- 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. And 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. So we believe that our product today can support this $60 billion in TAM. And it's also true that we're in very early innings of capturing this. We -- many companies are still in early stages of adopting their own data -- in their own data and 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 re-highlight that we have a really diverse set of industries represented across our installed base. And it's really exciting for us because this is where we see kind of the endless plethora of use cases that customers come up to put data in motion to work. It also gives us a really diversified portfolio, which is great. And it gives us a number of growth vectors. And so we're just seeing real-time data streaming becoming more and more relevant across so many industries with so many use cases. I want to 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 just -- we're really honored to work with so many incredible companies and see them put data in motion to work to transform their business. So we do count 172 Fortune 500 companies as customers today. And growing our large customer accounts is something that we're very focused on. We want to make sure that we get into these really high propensity accounts in a very intentional way and then work -- 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. So 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. And then 157 companies spending more than $100,000 in ARR with us. And 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 more than $10 million in ARR. So 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 opportunities 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. So 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 a safe passage from a mission-critical app built on open source over to Confluent. And oftentimes, those initial lands are bigger, like the one that you see in the Fortune 50 bank. But what's true across all of them is that once we get in, we tend to expand pretty significantly and consistently ranging from this -- the online travel provider here who's grown 29x over the last 6 years and 8x, 31x, 9x in these different companies. But we're very focused on -- 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 upfront just to get customers going with Confluent Cloud and then worry about driving consumption through incremental use cases to help them expand. So 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 3 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. And 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 passed. And this is very aligned to our customers' journey, which I'll show you on the next slide. But let me just give a little bit of detail behind each of these 3 pillars. So 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 want to get them into our products. So we have a pay-as-you-go offering that they can get into self-service. Sometimes our sales teams, we'll invite them in, give them an account, to get them going on Confluent Cloud as early as possible to start experimenting, tinkering, building in its early stages of the journey as possible. And oftentimes, this might even replace a demo or maybe it comes together with a more robust technical proof of concept. But we want to 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. So 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. And this is really important. And as 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. So it's really good for customers. And then 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. And we want to 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. And this ultimately -- the combination of all of these ultimately not only allows us to go to market in a really opinionated way and 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. So this go-to-market model is rooted in the customer adoption journey and what we call the data in motion journey. And 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. And 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 we anchor to, and we think about how can we optimize engagement at every step of the way. The journey often starts with developers in an experimentation phase. And again, we want this to be really low friction. We want to build developer love. We have lots of ways to engage developers, of course, in the product -- with a great product experience and documentation. And we also have our devex team, our developer relations team and community and lots of resources for them. So earning developer love is really key to success in these early stages. And then the product needs to be available for instant usage with all the needed features in the least amount of hassle. So again, we want to 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 want to ask customers to do that too early in the cycle before their application's even in production. So 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 syncs that we can connect to, operability, compliance and predictable pricing that scales. So those are often the conversations we're having in those stages. And then, 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 Flow Networks. One of our customers, Flow Networks enables leading banks and financial institutions to grow cardholder usage through engagement throughout the customer life cycle. And 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. And I love this last clause here because we hear this a lot as 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, and 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. So we often see customers engaged with one specific need in use case, and then they'll add additional use cases once they see the power of data in motion. And I'll add that as we think about our usage expansion and consumption of Confluent and specifically Confluent Cloud, consumption is really driven by -- or increases in consumption is really driven by incremental use cases. And 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 is we're generating events. And so 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. So 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, and 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. And they're leveraging Confluent for all digital interactions with their customers through web, mobile or any digital channel. And then data from these streams are used from -- used for prototyping marketing programs. So they're able to, in real time, capture data from those customer interactions and then generate real-time marketing offers back out to customers. And 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 and building really a unified data layer. And 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. And now as they've expanded across these lines of business as they look ahead to the next project in the next line of business, Confluent and the data streaming platform are a standard. And so the next thing that they build will be built on Confluent as a standard across the bank. And I'll point out that as you can see here, this is one of the customers that I mentioned that is spending $10 million -- more than $10 million a year with us today. And 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 be -- to leverage real-time data. So that's one example. And what's happening underneath these use cases, Jay shared this earlier, but I want to 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. And so as 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. And so 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. So 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? And for us at Confluent, they're definitely an and. 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. So 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. So 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 want to make sure that we're bringing in the right support and enterprise account team to support customers. So 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, it really drives focus for us, and it ensures that we deploy the right resources to the right accounts based on propensity and stage. So for example, we have, 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. And within those different organizations, we resource our account teams differently. So in our enterprise segment and particularly in our strategic account segment, you might think of 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. And so 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 start-up type companies. And we want to see a high volume of land 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. So just a little bit about how we align our resources. And then finally, I'd like to spend a couple of 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. And we're fortunate to have really strong relationships with a number of different partners in the cloud and data ecosystem. And we divide them into categories in our cloud service provider partners. We partner with the big 3 here. global system integrators and regional system integrators and then ISVs. And I'll talk a little bit more about the cloud service providers on the next slide. So 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 organizations skilled up on Kafka. And that is part of a number of their transformation practices. And so 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 accounts 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. And 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. And then 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, 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 do all these different technologies and the modern stack fit together? So 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. So 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 co-opetition? Are they friend or foe, the cloud service providers? And 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 3 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. So first and foremost, they see a ready market and they know that Kafka enjoys very broad adoption in the market. In fact, one of the solution engineering leaders at AWS recently told me that the #1 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. So 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. So for example, we've gone to market together with things like data warehouse modernization where we can construct -- 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 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. And so 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. And then Confluent wins because it gives us a route to market. And 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 CSPs 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. And so being -- thinking about that data-led migration has been a really great opportunity for us. And then finally, and I've talked about this, but we really do increase data consumption for the CSPs. And I think we're sending a lot of data to a lot of different services. And so it's both the advantages upfront around burning down the commits, but then it's the advantages on the back end of Confluent moving data into all those services. So to pull it all together, I again want to reiterate that we are in the building stages, the early stages of this unique customer growth go-to-market model. And we're building out a number of components. 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. And we're early in this journey. 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 in our pay-as-you-go offering in 2020. And we just recently around that time frame got into the cloud provider marketplaces. So you add those up, and we're still pretty early in the journey of bringing each of these capabilities to market. But 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. And just 2 examples of 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. And that's through -- over the work we've done over the last year or 2 to make that happen. But as we really optimize that, that improves the efficiency of our land motion in this segment where we land most of our logos. So that's one example. I also talked about our strategic enterprise segment and landing very intentionally and deliberately in these high propensity accounts. And 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 and their language that really adds effectiveness and efficiency to that motion. So we're building out all of these capabilities and stitching them together. And are early in the journey, but excited about the progress. These 3 pillars of the customer growth go to market are very connected -- directly connected to our business performance from a product-led perspective or tracking metrics like total sign-ups and total customer count. From a consumption-oriented perspective, we're tracking metrics like our Confluent Cloud revenue. And from the -- for purpose-built in data and motion, important metrics here, our 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. And so 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. And if you recall, 2021 was very much not the case. It was a big investment year. We hired a lot of sales capacity. And so now as folks have come into that ramp, the mix of sellers between tenured and nontenured is changing. We're seeing a faster ramp for our customers. So we've put a lot of work into optimizing our consumption model to get our customer ramp time down. And we're currently in about 6 months for customers who make 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. And then we have put up 130% or more NRR in the quarter 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. So 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. So 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 and we're -- 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. And 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. And put all of these things together, as my team knows, I use the phrase a lot that we're just getting started, but 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. So thank you very much for your time. I think we're moving to a 10-minute break. And then when we come back, we will do Q&A with the executive team. Thank you. [Break]

All right. So we're back for Q&A. You know everyone up on stage here. So I'd like to turn it over to just the audience and you guys raise your hands. Feel free to ask questions and Shane and Fahim have microphones, and we'll hand you the microphone, so you can ask the question. Okay.

Michael Turrin, Wells Fargo Securities. I think the big question for a lot of us in the room is just where we are in 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?

Yes, that's a great question. Yes, it's really worth understanding this in detail. If you look at some of the older models for commercializing open source, it was selling kind of a proprietary piece of software in your on-premise data center. Effectively, in that world, the productized version of the open source functions as a kind of premium product. right? And so 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? And so 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. The value proposition of a cloud offering, it's not a premium thing. So 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 not just a better product, not just a better outcome, but actually cheaper to get a cloud service. And that's a very different way of thinking and building. So for a lot of these tech companies may not be the way they started, right? So I was at LinkedIn previously where we created Kafka, they had big internal teams. They built lots of infrastructure, heavy investment in that. But if you look at a lot of the companies now what they're doing book 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 effectively internal platforms that are the same everywhere. They want their people working on the things that are their competitive differentiation. And so yes, what do we need to do to go capture all that open source? Well, part of it about that mindset shift, part of it for us has also been having a cloud service, right? So we had to have a cloud service it had to be -- 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. And so 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, so New Relic or Square. These were early users of the open source who are doing exactly that 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. And so yes, I think that, that's a trend which is going to both continue and accelerate. 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. But 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. And 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. And a lot of that is going to come by focusing on the stuff that's unique to their business. and that is going to drive adoption of cloud. And if you look at what's happening in the cloud products, they're getting better and better at an incredibly rapid rate. And so it's not just a matter of getting open source of 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 any other way. And so all of that, I think, drives that increasing commercialization rate that I kind of referred to. Long answer to a short question.

It's Tyler Radke from Citi. I wanted to ask you about the -- I guess it's kind of a go-to-market and product question. So 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? And then secondly, I noticed on the industry side, it seemed like health care was a little bit underpenetrated in terms of the commercial Confluent adoption. So 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. I don't know if you want to take the health care area. Yes. Yes. I would say, over time, those will start to address different personas. We always start with the model of, hey, starting with the customer you have, serving them and then branching out. And so when we thought about governance, 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. And then 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, where the chief data officer is going around telling you, you better do it through Confluent because that's the thing that we have all the controls and safety around. And so that was how we thought about that. Very similar with Stream designer. We said, hey, we want to make it just dead easy to build streaming pipelines. It shouldn't be hard in real time or easy and batch, like that's not right. You should get to kind of have your cake and eat it too. But 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, so that -- it's not like you have this trade-off between kind of no-code tool where you can kind of do simple stuff, but you fall off some cliff and then you're stuck, really has a direct translation to the underlying KSQL and Kafka topics and very much is an active participant in that ecosystem. You don't have to know that. You can use it just as a no-code tool, but 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 trying to do all this stuff and want to have it be easier. And then you can push out from there. So first, make your existing customers happy, then go get all the customers you could get before with the new capability. That's very much the philosophy. And do you want to speak a little bit to the health care area?

Sure. I'll -- are we on? Yes. On the question around health care. Yes, there's interesting opportunities there. And we have a few good customer use cases that we've already seen in action. We're -- and I would say, both in the payer and provider side of health care. Probably more traction on the payer side, we're in a lot of the blues across 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 because I think it carries over to a lot of others in the payer space. But they're kind of leading the market in adopting what they're calling this interoperability standard and really looking for or how can they stream data, both 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. So for example, they're streaming data to their home care -- home health care providers. And so when they walk into 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 do they need a ramp? Is there a railing? So they can get around. So that's a pretty cool application that's built on Confluent. They're also taking in pharmacy data and claims data. So 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 kind of deployed the vaccination -- this massive vaccination effort when vaccines first came out and how they had to take in data from external sources. So -- and then we do have a number of hospital systems. I'm not sure who's referenceable, but a number who are leveraging Confluent as well. So I wouldn't say that today, the kind of payers and providers, maybe insurance more broadly is a top 5 or 6 industry for us, but a lot of opportunity in health care as they continue to transform.

Derrick Wood at Cowen. Great presentation today. Jay, you mentioned additional growth opportunities as you productize use cases up stack. And I'm just wondering what that looks like? Are those kind of 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, there was a demo I saw that was like a knowledge bot that basically sent alerts to account executives when customer in the cloud turned on a new connector, had a new use case and alerted account executives via Slack. And I just maybe wonder, as customers who are in the cloud, do you see increased productivity out of sales reps? Does that accelerate that road map to kind -- I don't know, cross enterprise connectivity, the central nervous system. Just curious how cloud is helping shape productivity and cycles.

Yes. So there's a ton of use cases, 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. And the reason for that is, first of all, that's where we have the focus and knowledge. And secondly, we can kind of take it out and sell it as part of our normal sales motion. And so 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, IoT, real-time analytics, use cases around logistics, use cases around the 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 dig about to all the customers. When we think about kind of verticalizing more for industries, we don't start with new products. 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, kind of show them some of the patterns that are in place and sell more effectively. I think that's little bit more of it. Erica or Stephanie could probably address it in more detail as well as the other question.

So -- can you hear me? Great. So 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. There's more technical use cases first. What we're doing on the vertical use cases, I don't -- 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 you need to focus the sales team and the marketing motion on key use cases. So 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 at 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. And right now, we have a couple of 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. So 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.

And 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. So that is something that's in use. It's kind of in early stages, but you're exactly right that with the managed service cloud offering, we should be able to be really intelligent about how our customers are using our service then be able to kind of recommend the next best action for value or identify opportunities to optimize performance or streamline their environment. And so I'd say that we're -- that's definitely been a big focus area of ours as we've moved to -- 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. So very much so, it should enable us to be more opinionated, more efficient and deliver customers a lot of value because we can see what they're doing.

Brad Sills over here. Can you hear me okay?

Yes.

Brad Sills from BofA Securities. I 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 too 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 that you've got to over time. But really, what write in those accounts from a go-to-market standpoint to really drive of adoption within some of these larger accounts?

Yes, I'm happy to take that. It really is a mix of the bottoms up and the tops down. They're product-led and then the kind of the enterprise motion. The reason being is we want to be running these parallel streams of -- with the bottoms-up motion kind of building out the capabilities within the account of developers and architects who know how to build application, leveraging Confluent and 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 -- 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 want to be doing both at the same time. And 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 a lot of our technical folks to run big workshops and really skill up people. And then meanwhile, we're taking those use cases to the different economic buyers. And then, of course, working with our partners and those accounts as well. So maybe we'll go to market with one of the cloud service providers who's working on the next kind of workload migration to the cloud and partner with them to be a part of that solution.

Phil Winslow, Credit Suisse. A 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 of size. When I think about one of the announcements this week with Stream Designer, that seems like a potential accelerant of that looking for new personas. And I guess the idea I had sort of the more streams, the better, the greater the network effect, more personas, et cetera. But how do you see potentially that being accelerated? Is this the right way to think about it? And then just maybe one follow-up to that.

Yes, I think that's exactly right. So when we think about our efforts, there's kind of a key paradigm shift towards streaming in real time. Early on as Confluent was getting started, only like the biggest tech companies could really take advantage to that because they would have to 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 put a lot of software engineering and baking this into each of their applications. And so when we think about Confluent's efforts, it's really to make it easy, right? Same value, same paradigm shifts, but without all the investment. And so on the operational side, that's cloud, right? Just take that problem away, do it for them. On 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. So I think really in terms of kind of 3 layers to the cake, 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'll 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, SQL, things developers already know to take advantage of this. And then the third layer of that cake is the kind of higher-level interfaces, right? So 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, then that can make you go even faster. And 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. So 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. They'll build all of that once the data is there and starts to pull in those use cases. So how can we see 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. If you're just dipping your toes in the water in this area. And so yes, 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. And then my follow-on to that is about governance. Sort of, okay, you go fast, we'll stay in the guardrails. When you think about governments, how much does governments in the enhanced capability there play into what you did was just...

Yes. Yes. It is directly connected. So like, I guess, back in the day at Facebook, it was move fast and break things. But like for most companies with data now, it's move fast and don't break anything, right? And those things are in conflict. So it's not enough for us to just be an infrastructure provider and say, hey, we're going to allow you to stream data really quickly. We're going to allow you to process it really quickly. We're going to allow you to connect across the organization. If we don't provide you the tools to do that in a way that's safe and 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 going to be able to do it. You're not really going to be able to unlock it. That central nervous system vision that won't really be possible for you. And so, yes, we -- that is probably the most demanded set of features from our customers is 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. And 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, but 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. 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. So these capabilities are actually quite important in motivating usage and making that something that's the easiest, most obvious way to plug into the data flow of the company.

And just one follow-on to that. It really goes back to the nature of the that we are doing. These are core operations that companies are using to run their business. So 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 has just said, they need security that we bring to the platform, and it's because it's the core operations that are being run to run the business.

Raimo Lenschow from Barclays. I want to get Chad involved and actually follow on from these questions 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 where you're going to spend your time in terms of driving the product further? Because I can see the compliance angle. I can see the scalability in the presentation today. So where are you going to focus your time?

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. So part of it is making sure that, that keeps going forward. But I think ultimately, when you deal with large amounts of data, it's really about making sure that those connections are easy to use. So we're going to 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 problem -- location of that data that I should use? Because oftentimes, companies might have 5 copies of this data in a table. The first one is the raw piece, the second one that's cleaned it up. The third one is the one that we very validated and tested. So if you're searching for the right one to use, how do you know which one it is? And that's why, again, as Jay was saying, the 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. So some of that is infrastructure that we are, of course, going to build. But as you can see here, there's a partnership part where we're going to 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. And I think that's a piece that I want to 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, the Snowflakes of the world, they're using M&A to build more win over the hearts and minds of developers with new application tools. And 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 to 10 years, what's the case for data streaming remaining a sort of stand-alone capability or product market versus something that gets subsumed within a larger data/application platform?

Yes. Maybe I can take a stab at that, and you may have a view as well. So I think if you look at the -- what's happening with streaming, that's a paradigm shift that I think is affecting almost everything that touches data, right? So the operational databases are developing capabilities to produce out a stream of what's happening in them. The SaaS world is building connectivity really both for ingest and kind of egress into this area. And then a lot of the analytics platforms are getting the ability to kind of take streams faster into them. And so all of that I think, is very positive for us. 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? And I think there's a very big difference between being an operational database, being a kind of data science or analytics or reporting kind of warehouse platform being some SaaS application. And then what we're going after, which is the central nervous system and that ecosystem of applications is around that and kind of in that real-time reaction area. What's different about it? The workloads are different, the people doing the work are different, their personas are different. The kind of needs from the product are quite different? Like how does it perform? How does it do well? And if we look at what's happening in that whole ecosystem, I would say there's obviously interest in broadening capabilities. But if anything, what you're witnessing is probably additional diversification. The rise of cloud means a lot of the burden of adopting new capabilities has gone down. You no longer have to operate a net new database if you get a new thing. And so I think if anything, the world's is getting more diverse across more clouds with more systems. And so 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. And so 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 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. But 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. And I think the reality is today, we're seeing more specialization in 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 the Salesforces of the world, but it's not like you see some collapse where everything is just Sales -- a future in Salesforce, you actually see a diversification of more use cases. And I think it's very hard to be the connective tissue between all of that, if you're also one of the kind of destination systems because it just isn't really your nature or your real focus to help enable all the other things. And so I think that's kind of what will help set these dividing lines. And it's true that, that whole ecosystem is unfolding. So it's a wild world that will look different 5 years from now but I feel very secure in kind of the position we're building into in that. And Chad, of course, worked on a data warehouse and can probably give a good answer as well.

Yes. I think there's a fundamental engineering reason of why that we are in a better position over Snowflake and Databricks for example. And 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? And it's because when you want to make these paradigm kind of shifts when you want to move from on-premise to the cloud, what we learned is, is that all of those companies optimize 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, data bricks, et cetera, moved along, they said, hey, we can do that better. But it's still batch, it's still batch processing. So they end up bolting on these streaming pieces to get that data there in real time. But fundamentally, when they're working with data, the literally millions of lines of code that they have are treating it in batch. And the real question is, do you think Snowflake and Databricks are going to 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? And I think that's the fundamental issue. They're going to have to keep investing in this batch part because it's core of their business. they're going to 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. So 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. So Rudy, go ahead.

Rudy Kessinger, D.A. Davidson. I appreciate the presentations today. I wanted to ask, you gave the bottoms-up TAM analysis, which I appreciate. I'm curious on the Fortune 500 customers. You said an average, you think they represent a $10 million-plus ARR opportunity. Where do you drive that figure from? Is it based on your visibility into what they're spending in open source Kafka and analysis of what they're spending currently versus where they're at in the customer adoption journey? So 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 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. Yes. Yes. So when we looked at that, we're obviously looking at, hey, what -- we have some view of what the maturity curve of one of those customers looks like, right? And it takes some years to kind of 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. So 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, that would kind of start to cap out? Where do we feel like, okay, you're getting to good penetration in the customer? And that's how we came up with a view of what's possible, really in each of those segments in terms of average customer size. And I'm sorry, there was a second part to your question.

Yes. Just -- I don't know, Steffan, if there's any other 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 500, only $107 million ARR customers. But I'm curious if there's any other details you could share as to what they represent currently?

Yes. We don't break out the percentage of revenue coming from -- directly from the Fortune 500. But 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 and Fortune 500 would be a subset of that. And I think that one of the biggest takeaways 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. And so the opportunity that is in front of us is much larger than what we've already booked today for nearly all of those accounts. Okay, all right. So that concludes our Q&A session. We're going to now turn the mic over to Stephanie who is our Chief Marketing Officer, and she's going to conduct a customer panel.

Awesome. Thank you. All right. Thank you all for hanging in there. It's great to be here, as I said. As Steffan said, I'm Stephanie Buscemi, Chief Marketing Officer here at Confluent and I'm excited. I've got 2 wonderful customers here to have a little fireside chat, no fire, but the chat. And I'm going to introduce them, and then we're just going to dive in. We're going to go through -- I'll lead with a couple of questions just to kind of soften the ground and then we'll open it up for all of you to ask your questions as well. So 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?

I am. My pleasure.