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

Yes, understood. So one of the most exciting part of the Confluent's 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. And 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 hyperscale of compute is what I would imagine. But how do you say -- what did you say kind of Confluent's Flink solution offer that would entice those people who are using open source solutions into Confluent?

Yes. It's less about the competitive dynamic, and it's more about just the rise of stream processing overall. Even if a company is using stream processing, they're probably using it for 1 or 2 things, whereas they may have hundreds of applications using streams in Kafka, right? And so what we've done is we've looked at the rise of Kafka, we've looked at the rise of this technology Flink. And 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 2 things are? You can think of Kafka as the core stream of data. So in the example I give, maybe that would be the stream of all the sales that are occurring. You could think of Flink is 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 -- 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. So this second layer is just coming into prominence now in gathering adoption. We saw Flink really getting a lot of adoption across our customer base and beyond in the streaming ecosystem and brought in the team that had built this technology through an acquisition, and 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 the last quarter. But prior to that, over -- almost 600 people had tried it out just in the preproduction phase and built queries around it. So as that ramps, we see that as a really strong product offering that we think will be as important as Kafka and the core stream itself. And in our last earnings, we talked a little bit about this overall platform that we're building, right? We want to have the stream. We want to have the processing of the stream. We want to have the connectors that plug it and get all the streams, and we want to have the governance of the streaming data. And each one of those is a prized 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 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 effectively almost a single-product company with just Kafka to a multiproduct company across that full suite. And it is not just multiproduct in the sense of, hey, there's many things to sell, but that, that portfolio actually comprises of 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 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've ruined it.

But yes, we have heard it -- heard this from your partners who are basically saying that you created query on 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.

Yes, that's exactly right. So today, as we talked about on our last earnings call, that set of nonKafka spend in our cloud offering is about 10% of revenue. And it's outgrowing the core Kafka bit. But it is -- it's work to outgrow it because, of course, it drives more Kafka as well. And so 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 going to 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.

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?

Yes. Yes. So in steady state, we definitely think it will be 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 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 may be 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, we want to see this get broad adoption within our customer base. And we'll start to build that stack of consumption generating apps over time.

Yes. 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 will be able to break through kind of into the analytical realm from an operational realm. So talk about that significance. And does adoption of Flink actually supercharge the use of Tableflow?

Yes. Yes. There's a set of product capabilities that all work together. And I realize there's a lot of acronyms in open source projects and whatever here, but bear with me for a second. So 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 analytics systems. And this is a big deal in the analytics world. It has traditionally been the case that your tables of data were always locked up in a single technology. So 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's 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 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 want to be able to kind of mix and match for whatever you want, and you want to be able to do that without like a really high cost of adoption. And so what this does is it kind of makes any of these streams of data available 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 has received phenomenal reception from our customers, a ton of excitement. So this is just going into EA with customers. We'll get to GA 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 a brief period of time, like 7 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 join on that contextual history or reprocess that data as needed. And so there really is kind of an interesting coming together of the kind of batch world and the stream processing world that's enabled by these technologies. So it is a big change. It's been very popular with customers because I think everybody is trying to make this happen so they can open up their data. And I think it was a product idea that certainly landed at the right time.

Yes. I wanted to talk quickly on pricing and packaging. It seems like you have introduced a lower storage pricing a quarter or 2 quarters ago, you introduced freight cluster, which is almost 90% reduction in DC or something like that I have read. But you have also -- it seems like in the list prices for Confluent Cloud, there is a change in terms of the compute prices out there. So maybe talk about that changes that you're rolling out and the rationale behind it?

Yes, yes. Probably the biggest thing for us, as we've opened up, our underlying engine that serves our cloud has the capabilities to serve multi-tenant workloads. And as we've opened up -- as the capabilities of that have gotten better and better, 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 because it's a higher margin offering. And we want to make sure we're incentivizing that. So we have had pricing across those and in some other areas. Our goal is kind of go, soak up the world's Kafka. Whenever we do that, sometimes people worry like, "Oh, why would you change prices." But from our point of view, there's a ton of open source Kafka that we want to go monetize. We want to 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 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-time trading app, 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 want to make that easier and more capable, right? We want to make it something that the easiest way to do it is streaming. And we want to 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 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 business is working real time. The needs and the most obvious way to build these 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 smaller set of customers we have. It's about, "Hey, soak up the rest of this." And we've been able to do that pretty effectively over the years without any harm to the existing business because there is like very good price elasticity and all of this. And you would see that in the results we just reported. It wasn't the case that there was some huge drop in cloud revenue. We actually saw a nice uptick.

Yes. Understood. Less than 5 minutes remaining. I want to see if anybody has any questions. We need the mic here, please.

It's kind of around the moat of your business. You have -- 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 in database storage and data analytics, how do you fend them off? And where is really the moat at a high level?

Yes. Yes, it's a good question. So the question is ultimately, 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 kind of getting drawn as we speak. And I think Confluent has been lucky in that the competition -- our competition has not been that strong. There's not another kind of Pepsi to our Coke, where there's a similar-sized company dedicated to streaming that's kind of doing exactly the same thing. So we have some overlap with the cloud providers in different parts of their offerings, but it's kind of not really apples to apples. And the focus has not really been there. So then the other threat -- as you're trying to look for threats, let's say, well okay, what could happen? Certainly, one of the things you could look at is other data companies could try and come into this space. I think the good news for us is the role that we play is very distinct. We're not another database or a 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 storage and processing at a point in time to streaming, kind of everything changes. The paradigm for processing data, for storing data, like kind of 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 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's kind of 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 them better. 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 across different parts of the organization. It's quite distinct from an individual database or a 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 of course, there's always these kind of what-if scenarios, right, and any company that what ifs going to happen, but it is a long hike to be able to do all that well.

Anybody else? This one.

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 -- clearly, it's faster, but it is also cheaper? Do you need fewer developers? Is it simpler to manage?

Yes. Yes, it's a great question. Yes. 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 because it solves a lot of the problems of building a streaming application. So it kind of 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. So 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 because these quarries aren't just something that come and go and are different each time. These are persistent that change with the shape of your data. And so you can really do a lot to optimize that. And so -- yes, you can have something that is a more convenient layer to build against and then 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 levels APIs. And so that's what it displaces. That's why the story is so strong as hey, if you look at the adoption of Kafka, there's so much of it, there's so many applications built against it, that 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 new where this Iceberg stuff, if you wanted to do it -- prior to this, you would have to build -- 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 are out of time. Thank you so much.

Thanks, everyone.