All right, I think that's our cue. Hey, hello everyone, I'm Pinjalim Bora, SMID cap software analyst at JP Morgan. Delighted to have here with me, Jay Kreps, CEO of Confluent. Jay, welcome to the conference. Thanks for having me. Let's start with a brief description or introduction about Confluent for the people in the audience that might not know about the story. Yeah, I'm happy to do that. So you know, when people think about the data space, most of it has really been built around storage and querying of data at rest. You know, the big databases, you know, whether it's Oracle or Snowflake, you know, it's very much how can we kinda get a bunch of data, sit it somewhere, look up the bits that we want, you know, process it in batch. The Confluent is, in some sense, kind of the other side of the coin. It's about data in motion, so data as it flows, as it moves between things. How can you move it, process it, build around it, in real time? You know, that has turned into increasingly an important problem as all the different software investments in a company become connected, and as companies become smarter about reacting and responding to what's happening across an organization. So, you know, the original technology that spurred this movement was an open-source system called Apache Kafka. You know, it's something that's out there in production in hundreds of thousands of organizations, like very broad adoption, and really started a whole movement around real-time streaming data. So the idea is, instead of thinking of data as, you know, some big pile that's stored in a place, you know, think about what a business does as, you know, a continuous stream. So maybe in a real retailer, you would have the real-time stream of what's selling and the stream of what's shipping and arriving in terms of products. You could imagine something like inventory or promotions as being in response to that. You know, the inventory you have on hand is taking the stream of what's selling and the stream of what's shipping and putting it together to calculate the stock that's on the shelf in a given location. You can imagine a lot of the activity of a business is, you know, like that. It's in response to what's happening out in the world, and that's really driven the rise of, you know, the, you know, a whole movement and ecosystem around streaming. Confluent offers a software product around that and a, you know, fully managed cloud service across the three major cloud providers that help customers adopt this, you know, help them put it in practice, take advantage of it. That's, that's a little bit of a sketch of the area, you know, hopefully 30 seconds for those who haven't seen us before. So digging into that change in underlying data architectures, maybe talk about the secular trends that are driving that change from static to in-motion data or data streams. And how does AI kind of come into that? Yeah. Yeah, so, you know, I would think about this in two directions. You know, one is the technological shift of how do we build, you know, systems that use data in real time continuously? You know, it's actually not a new need to be able to do this. Businesses have always been continuous things that happen 24 hours a day, that, you know, as long as we've had computers, there's been the generation of data around business. So this isn't something that suddenly came around in the last two years. It's actually a problem that's been there for a long time. You know, but, but it was actually very hard to do. So you would see this kind of real-time system maybe in, you know, financial services, some kind of trading system or whatever, but it would be really hard to build a big investment of, you know, a bunch of C++ programmers to build some real-time trading system. It wasn't a mainstream approach. You know, the mainstream approach was about batch data movement, storage, and lookup. That, that was how people solved problems. What happened, you know, over the last 10 years was really a revolution in the computer science of how you handle real-time streams of data to make that practical, and that that combined with, I think, even more pressure on the need for it. You know, maybe it was good enough to have this kind of batch data movement and processing when software systems were mostly, you know, little islands, that sat on their own. But increasingly, the systems in a business all have to come together. And so, you know, I think a good example of this in real life is one of our customers, BMW, where, you know, if you think about the things a car company has traditionally done, it's mostly about building the car. But increasingly, you know, cars are generating a real-time stream of data that's about the operation of the vehicle. Car companies are going from something where they did a small number of transactions in relative terms to dealerships and had no relationship with their customer, to organizations that sell, you know, online all the time, stitching together all the internal systems they have and have an ongoing relationship with their customers. And you know, the actual production of cars is also modeled in software. All the, you know, supply chain, logistics, the operations at factories now has a very, you know, significant software side. So all of these are about taking a bunch of things out in the world and software systems that, you know, used to be isolated islands, and gluing them all together, and that's done around these real-time streams. And so that's, that's a set of great use cases for Confluent. Now, this looks different in each industry. You know, a car company is gonna be a little different from a retailer, which is gonna be a little different from a, you know, tech company, which will be different from a bank, but all of them are increasingly built around this, you know, real-time streaming paradigm. And that pressure to be able to take software and really drive it right at the heart of the business problems, how the products are made, how you interact with customers, I think that's what's driven the kind of rise and adoption of this. And the AI use cases are, you know, another tailwind where companies are really trying to draw on data across the organization, be able to bring it together to serve applications, maybe some kind of chatbot that's powering different parts of the organization. That has to combine data about that particular customer, their interactions, their products, all the things that, you know, that organization has with, you know, a general-purpose language model, and be able to do that in an intelligent way that harnesses their data. That kind of RAG application or retrieval augmented generation, where you're bringing together a bunch of data and then looking it up to, to use in real time, that's a common use case for Confluent, where we would be the kind of data supply chain that would gather, help gather and transform all this data, you know, to be able to power that type of app. So, you know, I, I would put that on the list of use cases, along with the customer experience stuff, along with these, you know, kind of inventory and logistics applications, along with the IoT stuff as a, a use case that's driving the adoption of streaming and, and making it more prevalent across customers. Digging on the GenAI stuff, which is a topic of discussion, obviously. I think people are trying to understand, is GenAI a TAM expander for Confluent, right? And I think about it in two ways. One, GenAI is probably going to accelerate the workloads that are in TIBCO, RabbitMQ, some of these traditional places into Confluent or Kafka, but those workloads would have eventually moved anyways. It just accelerates that time, timeframe, versus creating new workloads that would have never been in real time, but now needs to be real time because of GenAI. Like, how do you, which one do you think is- Yeah, I, I think both of those are true. So I would say, look, these AI applications are a net new workload in their own right, right? This is not something we had before, that now we have, and we're, you know, companies are buying things to help power that stack. At the same time, I think it is, you know, one of a number of things motivating, rethinking, and upgrading of the kind of underlying architecture across, and, you know, I think that's a tailwind as well. It's something that was happening organically, but this maybe speeds that up. So probably both angles you gave are correct, you know, to differing degrees. Is there an example that we can think about, from something that would have never become real time, but needs to be now real time because of AI? Yeah. Yeah, sure. So, you know, example of a net new workload, we've, we've used, you know, I think one of the kind of prototypical examples, you know, the travel, you know, online travel agency, that wants to provide a support chatbot for their customers. And this is a pressing problem for them because although people tend to book online, when something goes wrong, it can be really complicated to figure out what to do, right? There, there's a cascading effect across, you know, your airline booking, and do you need the hotel that night, and what is the policy for change, and so on. And so in practice, people try and do it online, they get confused, and they call, right? And so the, the cost of that is high, and it's frustrating. You wait on hold for a long time. You know, so the use case here is actually have a chatbot that can answer a lot of the questions, take care of a lot of the kind of routine things, and reserve the need to talk to somebody, you know, for more advanced use cases. So what do they need to do to power that? Well, they have to have a very crisp idea of everything you've done. You know, both what's your trip, where's your flight, is it delayed, what were you just trying to do when you started interacting with the chatbot, probably 'cause it didn't work online. They need to have all that context kind of ready to go. You know, so is this a new use case? Yeah, I would say you probably wouldn't have had something like this before. That's a net new application that they're building. Did that data need to flow anyway to power support systems? Yeah, it did. So it's not like they wouldn't have had any use case for real time. It's just that this is something net new, which is important and impactful for them, that, that kind of turbocharged it. Yep, understood. So, switching gears a bit, Confluent seems like in a, in a pretty important juncture at this point. I was looking at the numbers. I think Confluent Cloud run rate, if my math was right, eclipsed Confluent Platform for the first time, I believe, last quarter. Yeah, that was a nice milestone, you know, for those who tracked us since the IPO. You know, we were on a really good trajectory as we went public. We felt very confident, but it was still, our cloud revenue was still a smaller portion, and, you know, now is, you know, on a nice trajectory to be the majority of the business. Yeah, and you're leaning in on cloud with a major kind of go-to-market change. Maybe talk about that. Quick background on what are the changes and more importantly, you know, how far along are we in those changes? What has changed, what you have already made, and what still needs to be done? Yeah, one of the things we talked about heading into this year was that we were gonna be adjusting our go-to-market to really focus directly on consumption, you know? So as a company that started with a licensed software offering, obviously, what your sales team is goaled on, the stats you run the business, is around, you know, locking in some term license, some subscription, right? And you would goal on the bookings for that. As we started adding cloud, we added it in a similar way, where there's some commitment to cloud spend. You might commit to spend $100K or $300K or whatever it is, and the team's goal would be these commitments. Heading into this year, we're making a switch to really goal them around consumption. So what's the direct usage of the product? And yeah, that has a couple of really important things that it helps drive. First, it helps drive the expansion of new use cases. So, you know, going and finding the next new application that's gonna adopt streaming and making sure that that comes online. Second, it helps us expand to other product offerings that we have. So we've, you know, we've brought together, not just an offering of the core stream, but these other capabilities around connecting into the systems that you might have, governing streaming data, processing it in real time, and we wanna make sure that each of those is driven out to customers and drives consumption. And so this was the change that we made. It's a fairly big change. You know, it's internal to us. Our customers always paid us for the consumption of the service, but our go-to-market effort was ultimately run around bookings, not the kind of direct consumption. A nd, you know, that flows through to how we track pipeline, you know, how we pay the sales team, et cetera. So we've made that change heading into this year. That's gone really well. The, you know, our Q1 results showed a nice uptick in the net new customer lands, which is one of the things this helps motivate, you know, strong consumption in our cloud offering. And so, you know, the early parts of this transition have been quite successful, and we're really pleased with it. It also, as I said, helps us drive the adoption of the complete platform, which is a strategic goal for us, you know, beyond just the immediate results. This has a really pleasant impact, I think, for our customers, where, you know, we're very focused on their success and adoption. You know, their applications coming to production, not just driving a bigger and bigger commitment, which in the absence of that kind of joint success isn't necessarily, you know, the most meaningful thing to them. So that, that was an important change for us. If I have to dig in a little bit, from a rep's point of view, if I'm a rep at Confluent, what has changed for me? It's the quota is based on something different. Yeah. You have to think of it d ifferently. Maybe talk about that. Yeah. So, you know, different parts of the sales organization would sell, you know, our software offering and our cloud offering. Some teams would have both, some would sell just one or the other, depending on the part of the customer base they cover. The software offering, the goals remain the same. For the cloud offering, you know, it's really driven off of customer lands and incremental consumption, meaning if you have a run rate of X, how much above X did you take their consumption in the period? And so that, that's the big change. So instead of forecasting, you know, new commitments that the customer was gonna make, you're forecasting the actual increase in consumption. Instead of driving pipeline as, the next new commit, the pipeline is the use case that's gonna, you know, add consumption dollars. You know, that's the change to them. So there's a bit of a change in the goals, but there's also a change in the motion, right? Because they're now working, you know, workload by workload in a more direct way. So on a sales forecasting level, aggregate level, if you look at the company, it is more based on probabilistic measures? Is that when you think about which use case is gonna ramp, how much at a customer by customer level? Well, at the company level, it's actually interesting. So obviously, when we report our cloud revenue, that comes directly from consumption and always has since, you know, long before we went public. So in the past, what we would do is the sales team would forecast the commitments. We would forecast statistically how much of that would happen quarter by quarter, and, you know, obviously, hope we're right. In the new model, there's actually much better alignment, which is, you know, when we report revenue in a quarter, that's directly based on the cloud consumption in that quarter. That lines up very much to what the sales team is forecasting, which is how much consumption are we gonna be driving. And so, yeah, there's actually tighter alignment now between what the sales team would forecast and what the company would forecast. And it—so in a sense, at the highest level, the problem gets simpler, at my level. For an individual rep or regional sales director, this may be a very different motion since they've been used to forecasting committed bookings for the last 10 years. Now they're, now they're forecasting the consumption of the product, which is, you know, certainly a change in what they're doing. Yeah. Let's switch gear again, on macro. It seems like your consumption trends are stabilizing, from what we can tell. Maybe talk about what's your view of consumption? I think you had said that strength kind of flowed into April. Any way we can understand what's if that has flown through May so far, kind of in the consumption trend? Anything to note there? Yeah, I mean, obviously, I wouldn't, you know, extend commentary past, you know, the last earnings. But, yeah, what we said then was we've definitely seen a little bit more stability in the optimization and a pickup in, you know, the rate of new use cases. And so for us, you know, customers can drive expansion by having their existing use case get bigger, maybe because the business has more customers. That's probably the least common. You know, some companies are, of course, on a great growth trajectory, but not all. They can grow their usage by using more parts of our product, using the stream processing or connectors, or the most common way that they grow is by new adoption, new use cases that are added. So, for the reps, that's one of the biggest things for them, is going and adding new use cases. So an important variable in our growth is how many new software projects are companies doing? And, you know, this is true for a lot of the different, cloud infrastructure providers. And, you know, I would say last year, there was certainly some downward pressure on that as companies were focused more on optimization. I would say we've seen, you know, some nice green shoots, probably particularly pronounced in the digital native segment, but, you know, across the board, where there's definitely new investment happening in projects, and that's obviously a tailwind when we think about the use cases that we can go address with our solution. Yep, understood. So one of the most exciting part of the Confluent story in my mind is Flink and the stream processing part of the story. We did a survey recently, we found 35% of the market actually does not use any tool for stream processing. It's completely greenfield. Within the rest, the main commercial vendor is Confluent with ksqlDB, with about 8% share, and then you have Kafka Streams and Apache Flink basically making up something like 45% of the usage. And those are probably running on hyperscaler compute, is what I would imagine. But how would you say, what would you say kind of Confluent's Flink solution offer that would entice those people who are using open source solutions into Confluent? Yeah, it's less about the competitive dynamic, and it's more about just the rise of stream processing overall. You know, even if a company is using stream processing, they're probably using it for one or two things, whereas they may have hundreds of applications using streams in Kafka, right? And so, you know, what we've done is we've looked at the rise of Kafka, we've looked at the rise of this technology, Flink, and, you know, it's a very similar trajectory, but the Flink is a little newer, right? So it's earlier in that S-curve. If you're new to this space, it's worth just saying what these two things are. You can think of Kafka as the core stream of data. So in the example I gave, maybe that would be the stream of all the sales that are occurring. You know, you could think of Flink as doing the processing of that stream. So if you want to compute the real-time inventory, that would be done off that stream. So it's, you know, in a database, you would have storage and query processing. In this world, you have the stream and stream processing, right? So Flink is the stream processing. You know, this, this second layer is just coming into prominence now and gathering adoption. We saw, you know, Flink really getting, you know, a lot of adoption across our customer base and beyond in the streaming ecosystem and, you know, brought in the team that had built this technology through an acquisition, combined it with the team we had, and have released a product around that, that has met with really strong early adoption. So it just went GA right at the end of last quarter, but, you know, prior to that, over almost 600 people had, you know, tried it out just in the pre-production phase and built queries around it. So as that ramps, we, we see that as, you know, really strong product offering that we think will be as important as Kafka in the core stream itself. And in our last earnings, we talked a little bit about this overall platform that we're building, right? We wanna have the stream, we wanna have the processing of the stream, we wanna have the connectors that plug in and get all the streams, and we wanna have the governance of the streaming data. And each one of those is a, you know, priced portion of our offering that drives consumption. And so, as these come together, companies have this really powerful technology that allows them to operate on real-time, you know, across the organization. So one of the goals for us, over the course of this year, is really make sure our go-to-market is able to drive adoption across that full set of capabilities, and that we're really kind of going from, you know, effectively almost a single product company with just Kafka to a, you know, multi-product company, across that full suite. And that it's not just multi-product in the sense of, hey, there's many things to sell, but that, that, that portfolio actually comprises a platform that's more powerful than the sum of its parts and what it lets you do. And that's definitely true with these where, you know, the streams that are processed, of course, turn into new streams. So the processing generates more usage of Kafka. The connectors, of course, drive more streaming and more processing. The governance makes this a target that can be used across the organization and unlocks use cases. So these things feed on each other and multiply one another. That was exactly my next question. Oh, I ruined it. But yeah, yeah, we have heard it, heard this from your partners, who are basically saying that you create a query on a stream, you write it to a topic into Kafka, and so Kafka actually could grow faster because of Flink. So if you see Flink's growth not catching up to Kafka, that doesn't mean Flink is slower, but it's actually because Flink is feeding into Kafka. Yeah, that, that's exactly right. So, you know, today, as we talked about on our last earnings call, you know, that set of non-Kafka spend in our cloud offering is about 10% of revenue, and it's outgrowing the core Kafka bit. But it is, y ou know, it's work to outgrow it because, of course, it drives more Kafka as well, and so, you know, they feed on each other, and it makes sense. In a world where building on streaming requires you to code up an application from scratch in low-level application code, that's gonna happen slower. In a world where you can do that in a high-level language like SQL, which is kind of the universal language for data across other databases and technologies, suddenly that's much easier for companies to harness and take advantage of, and that's one of the things that Flink brings to the table, is making that really easy to consume. What, maybe it's too early, but what is, if you have seen any kind of an ACV uplift for like, for like customers using Flink stream processing, anything to note there? Yeah, yeah. So, you know, in steady state, we definitely think it'll be, you know, larger than Kafka for an individual customer that adopts this and adopts the two together. But it's important to understand how it builds. So it's not like a binary thing where you turn on Flink and suddenly your spend doubles. Rather, use case by use case, you're adding these permanent workloads that consume and will consume, you know, until that application goes away, right? And so for us, it's about the building of Flink workloads and kind of taking that from something that's maybe used for just a few things within each customer to something that is used broadly across all their applications. So that build is kind of what we're starting now that the Flink offering has gone GA. You know, we wanna see this get broad adoption within our customer base, and, you know, we'll start to build that stack of consumption-generating apps over time. Yeah. One more question on the products, Tableflow. I don't think investors understand completely at this point, the significance of it, so maybe talk about it, because to me it seems like you, you'll be able to break through kind of into the analytical realm from a operational realm. And so talk about that significance, and does adoption of Flink actually supercharge the use of Tableflow? Yeah, yeah. There's a set of product capabilities that all work together. And, I realize there's a lot of acronyms and open source projects and whatever here, but, you know, bear with me for a second. So, you know, the technology here this is built around is called Iceberg, and what this is, is it's a format for exposing data that's stored in S3 or other cloud object storage across many different analytic systems, and this is a big deal in the analytics world. It's traditionally been the case that your tables of data were always locked up in a single technology. So, you know, maybe you had Oracle as your data warehouse, you would have all your tables in Oracle. Things could only use that data if they were in Oracle's ecosystem, and so there was this very strong gravitational pull into that system. That's very different from the operational side of businesses, where there's many databases and many technologies, and it's kind of a very open marketplace. And so what's happening in the world of analytics is, because of cloud object storage, you can now share these tables across systems. Iceberg forms a kind of standard for sharing that data. And so what Confluent has done is, open up the internals of our cloud, streaming engine so that those streams are now shareable as Iceberg tables. And this makes it really, really easy to take any data that comes into Confluent and land it in any of the, you know, analytical engines that you like, so into Snowflake or different query layers that sit on top of that, the various cloud provider offerings. This is a really powerful thing for customers that have kind of felt like they're a little bit locked into one technology or another. Like, they made some decision at a point in time, maybe based on some workloads, but it's not the case that one technology is perfect for everything. Some of these things are very expensive, but high performance for certain workloads. Some of them are very cheap, but harder to use. You wanna be able to kinda mix and match, you know, for whatever you want, and you wanna be able to do that without, like, a really high cost of adoption. And so what this does is it, you know, kinda makes any of these streams data available, you know, to all of these analytics services. That's the value for the customer in the analytics world, is getting data into this new Iceberg format quickly. That's received phenomenal reception from our customers, a ton of excitement. So this is just going into EA with customers. You know, we'll get to GA in, in good time, but really a ton of excitement. What it does for us is it means that, hey, the streaming world isn't just limited to, you know, a brief period of time, like seven days or whatever the default would be of streaming data that we would retain. Now, the streaming platform has access to the full history of everything, right? Whatever was kind of going into the data warehouse, and that means your stream processing can go back and, you know, join on that key contextual history or reprocess that data as needed. And so there really is kind of an interesting coming together of, you know, the kind of batch world and the stream processing world that, that's enabled by these technologies. So it's a, it is a big change. You know, it's been very popular with customers 'cause I think everybody's trying to make this happen so they can open up their data, and I think it was a, you know, product idea that certainly landed at the right time. Yeah. I wanted to talk quickly on pricing and packaging. Seems like you have introduced a lower storage pricing a quarter or two, two quarters ago. You introduced free cluster, which is almost 90% reduction in DC or something like that I have read. But you have also seems like in the list prices for Confluent Cloud, there is a change i n terms of the compute prices out there. Maybe talk about that changes that you're rolling out, and the rationale behind it. Yeah, yeah. You know, probably the biggest thing for us as we've opened up. You know, our underlying engine that serves our cloud has the capability to serve multi-tenant workloads, and as we've opened up, you know, as the capabilities of that have gotten better and better, you know, we wanted to open up cluster types and solutions that really take advantage of that. It ends up being better for customers because it just expands elastically and transparently. It's better for Confluent 'cause it's a higher margin offering, and we wanna make sure we're incentivizing that. So we have had, you know, pricing across those and in some other areas. Our goal is kind of go soak up the world's Kafka. You know, whenever we do that, sometimes people worry, like, "Oh, you know, why would you change prices?" But from our point of view, there's a ton of open source Kafka that we wanna go monetize. You know, we wanna go sell to those customers, and even more importantly, there's a ton of batch processing out in the world. There's a bunch of batch systems. In order to really go after those, two things have to be true. One, it has to be really easy to do it in a streaming fashion, and two, it has to be cost effective to do it. And as you make those two things true, it's not an advantage to have a batch system. Like, nobody was ever like, "Hey, I would like my data to be, you know, slow and out of date." It's just that that was cheaper and easier as a way of accomplishing it. Back in the day, that team of high-end C++ programmers that built the real, real-time trading app, you know, they were pretty hard to get, and it was a big investment. Now, with modern infrastructure, it's actually very capable and powerful, so you can do a wide set of things in streaming, but we wanna make that easier and more capable, right? We wanna make it, you know, something that the easiest way to do it is streaming, and we wanna make it cost effective so that we can go soak up all that, and that's a really important change for us to make. And what you're seeing is, you know, kind of the world of streaming is going from something that was kind of a very small niche to something that's kind of an obvious default. It makes sense, like businesses work in real time. You know, the needs and the most, you know, obvious way to build things would be this. But to make it true, it has to be easy, it has to be cost effective. So pushing on that is a very important thing for us to continue to do, rather than just trying to get the last dollar out of the, you know, smaller set of customers we have. It's about, "Hey, soak up the rest of this," and we, we've been able to do that pretty effectively over the years without, you know, any harm to the existing business because there is, like, very good price elasticity in all of this, and you would see that in the, you know, results we just reported. It wasn't the case that there was some huge drop in cloud revenue. We actually saw a nice uptick. Yep, understood. Less than five minutes remaining. Wanna see if anybody has any questions. We need the mic here, please. Thanks for taking my question. It's kind of around the moat of your business. You have, you know, in the data world, you have the players that play more on the storage side, data lake side, there's data analytics, and then there's you guys more on the streaming and streaming processing side of things. It sounds like you guys are solving a problem that needs to be solved, as that must look attractive from players, you know, in database storage and data analytics. How do you fend them off, and where's really the moat at a high level? Yeah. Yeah, it's a great question. So, yeah, the question is ultimately, you know, I think in the cloud, kind of the landscape is still evolving, right? So everybody wants to figure out where does one country end and where does another country begin, right? And so these borders are kinda getting drawn as we speak. And, you know, I think Confluent's been lucky in that the, you know, the competition, our competition has not been that strong. You know, there's not another kinda Pepsi to our Coke, where there's a similar size company dedicated to streaming that's kinda doing exactly the same thing. So we have some overlap with the cloud providers in different, you know, parts of their offerings, but it's kinda not, you know, really apples to apples, and the focus has not really been there. You know, so then, you know, the other threat. You know, as you're trying to look for threats, it's like, well, okay, where, what, what could happen? You know, certainly one of the things you could look at is other data companies could try and come into this space. You know, I think the good news for us is the role that we play is very distinct. You know, we're not another database or key-value store, we're not a data warehouse, and the technology is quite different. And so if you think about what changes between a database, which is about, you know, storage and processing at a point in time, to streaming, kinda everything changes. The paradigm for processing data, for storing data, like, kinda every part of the stack. And so of course, anybody can do anything, right? I mean, we could go build a data warehouse, but it would be hard for us, right, to go do that. Somebody else can try and add streaming features, but to really do it well and be kind of best in the world at that is very difficult. And then we have, I, I think, particular advantages in this, right? So ultimately, Kafka is the technology of choice, and Flink is the technology of choice for streams and stream processing, and that, that's kind of a just something that has happened and is happening, and so I think it's very hard to create something that displaces that momentum. Secondly, by doing these two things together, I think we have the ability to do 'em better. You know, the power of databases was that they had both storage but query processing and transactionality and security between the two things. And finally, this role as the central nervous system that plugs, you know, across different parts of the organization is quite distinct from an individual database or data warehouse or analytics layer. And what you have to do to make that work well is ultimately build a system that spans all the parts of the company, kind of exists in each region and each cloud provider, but actually connects across, which is quite different. And so, you know, of course, there, there's always these kind of what if scenarios, right? In any company, the what ifs can happen, but it is a long hike to be able to do all that well. Anybody else? This one. Thanks for taking my question. I was curious, when you think about the work that is done in Flink, like calculating how much inventory that is left, and the work that's done in Tableflow, which is like organizing things in rows and columns, where is that work being done now? And then when you guys do it, is it like, c learly, it's faster, but is it also cheaper? Do you need fewer developers? It's simpler to manage. Thank you. Yeah. Yeah, it's a great question. Yeah, so if you think about what's the motivation for something like Flink, I would say it's twofold. One, it's easier to build against one of these layers 'cause it solves a lot of the problems of building a streaming application. So it kinda does it for you, so your development cost is lower. But the second part is what you highlight, which is it's actually cheaper to run it that way. Why is it cheaper? Because the underlying primitives that process data are much better, and then we can actually run this as an elastic multi-tenant layer. If you think about how does something like Snowflake work, that ability to scale up and scale down the compute elastically with your queries, it's even better in the streaming world 'cause these queries aren't just something that come and go and are different each time. These are, you know, persistent, that change with the shape of your data, and so you can really do a lot to optimize that. And so, yeah, you can have something that is a more convenient layer to build against and that is operationally more efficient to run your applications, and that's why we think it's very compelling as a target for building real-time applications versus kind of doing it from scratch with lower-level APIs. And so that's what it displaces. That's why this story is so strong: hey, if you look at the adoption of Kafka, there's so much of it, there's so many applications built against it, that, you know, if you were to get a meaningful percentage of those pulled into the cloud platform that we offer and built on Flink, that would obviously be a significant step up in our revenue. And the argument for that, I think, is very compelling, both on the cost and convenience side, if we execute against it well. So that's the short answer. Tableflow is a little bit newer, this Iceberg stuff. You know, if you wanted to do it to, you know, prior to this, you would've had to build a you know, kind of get some connectors and wire it together a little bit yourself, and you would still have the duplication of data, so that is a bit of a net new thing. Okay, with that, we're out of time. Thank you so much. Thanks, everyone.