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

As investors look at now in the Confluent Platform and the Confluent Cloud, would you say it's at parity? Are you -- we used to hear a rule-based access is one thing that's not in Cloud. I think you have added that already. But is it at parity now?

Yes. The early part of the company, it was really about kind of achieving parity for Cloud. At this point, the cloud product actually has substantially more functionality. And there's a set of things you can do in a Cloud service that are just very hard or too difficult to do on-premise. And we're actually okay with that. We want to have something that all works together as one platform. But customers do understand that a software thing is going to be different from a cloud service. And so the interfaces for some of our data governance tools that work with streaming data are purely cloud-based, the next-generation stream processing technology that we're releasing is cloud-based. And so yes, it's actually more than parity in that respect.

Got it. And is there any difference? This question I get a lot, is there any difference between the workloads that are using Confluent Cloud versus Confluent Platform? Or is it kind of the similar workloads?

Yes, it's broadly similar. There are some differences in the kind of customers but if you look -- one misunderstanding that I see as common is people often assume that our cloud offering is just kind of people -- the little guys, like the little use cases, and then the serious people are kind of doing it themselves. That's actually totally untrue. At this point we have customers, if you look at our kind of total customer count, $100,000 plus, $1 million customer base, good representation in each of those cohorts. Some of our very largest customers are Cloud customers. The kind of TCO of our offering is positive at every scale now, which is actually a really significant thing. When you offer some product to customers and there's alternatives, it's great if you can have something that has better features, but it's actually better if it's like better features for less money. That's actually a really good combination to have. And that kind of TCO story versus doing it yourself, at this point, is just extremely strong, like the savings on hardware and people and just what you would put in to trying to do this in-house. It's just much better. It's much better when you're getting started, and it's much better when you're already at large scale. And so yes, all of that kind of adds up, too.

Yes. I thought you did a fabulous job in the earnings call when you kind of lined out the -- all the TCO differences between...

Yes. Yes. Our last earnings, we did a deep dive on this. And the reason was just it was such a common question from investors, and they kept saying, "Well, in tighter economic times, which we're in, isn't it going to be the case that all your customers are going to leave you for the open-source? And I kept saying, "No, like that would actually be a bad deal for them because it would cost them more." And I felt like, okay, I was saying it, but it didn't really sink in as to why. And so we did a much deeper dive on like, "Hey, what is it that a Cloud service replaces?" It's obviously a bunch of servers in the Cloud and networking and observability costs and people costs. That's kind of the pool of things that they would otherwise spend. And so when you run a Cloud service, you have a bunch of knobs that build efficiency on that. One is about multi-tenancy and being able to pool and drive high utilization. The other is about just kind of deeply building for Cloud systems so that you can build something that's just like hyper-efficient at large scale. And there's a lot of work that goes into doing that well. Really kind of closing some of the feedback loops of the actual usage, what that we see happening out in production to be able to optimize the placement of data in customers. There's a whole set of things that you do to kind of drive that. And then all of that adds up to this kind of TCO advantage where you can take something to customers that is a better deal for them and a better resulting product.

Is there a way to quantify that TCO advantage? Because you talked a lot of qualitative you laid out. But is there a way to kind of understand, again, if you like-for-like workload?

Yes, absolutely. Absolutely. So I went into this in some detail, and it does differ at different scales. It will be slightly different at small scale. A lot of the savings is typically people because you're going to have to hire some people even for your first use case just to run it. At large scale, it's going to be about infrastructure because you're going to be using just a lot of servers. Some of the tidbits that we gave on the operational side, we believe that we have more than a 1,000x cost advantage versus our customers' cost structure. So we run tens of thousands of these clusters in the cloud. We don't have tens of thousands of employees babysitting them. These kind of big distributed systems, typically, you would have like a team of people whose job is to like babysit this system and make sure it's up and operational and deal with upgrades and monitoring and observability and on-call rotation. We do that with a very small on-call team for the system that we run. How do we do that? Well, we don't do it by just like typing faster. We've actually built a substantially different piece of software that runs our cloud service that's built to run thousands of clusters that's run by software, not by humans that deals with every single thing that can go wrong from slow discs on a server that don't fail but don't perform the way you want to how new changes get rolled out. How can you do that in a way that's safe and that's automated and that's efficient. So that's where that advantage comes from. And then when you look at how this plays out for individual customers, we do this analysis based on their cost structure and their usage. A good example of this would be Michelin. This is a customer that was running Kafka themselves. Michelin is a -- they do tires, and they do restaurant reviews and then a bunch of things in between those 2, which are both very different. They're really trying to bring data to bear in their business in how they interact with customers all the way from the manufacturing side to the customer interaction and kind of e-commerce side of things, really spanning the business. They were very serious about just like, "Hey, what's the cost advantage of us doing it ourselves versus not?" I think they said that it was more than 35% savings in that analysis. We've seen similar things even for very technically sophisticated companies. So we sell in tech, and some of the earliest Kafka users where these tech companies that are at a very large scale. And they're good at this stuff, but it turns out those high-end Silicon Valley engineers are not cheap. And when you're talking about large pools of hardware, the efficiency advantages add up quite significantly in that area just how you use networking, et cetera. And so all of that adds up to a pretty significant savings as people move to our platform.

Yes. Let's talk about macro for a second. When you're talking about cloud consumption trends, I think you talked about a dip in March and a bounce back in April, right? Has that trend kind of continued into May? Or if you can comment on that?

Yes. Yes. Yes. We feel pretty good about what we gave in the earnings call. So we were saying we were expecting kind of a sequential add of cloud revenue that would be between $7.5 million and $8 million. And I think that's about what we expect.

And what's kind of the broad -- when you're talking to customers, what's kind of the broad sense of the macro environment at this point, just the business...

Yes. It's been similar for us over the last few quarters. We've definitely seen just more scrutiny on spend overall. There's fewer net new software projects happening. And for us then that means we lean a little bit more heavily into the open-source Kafka conversion, which is kind of the other lever for growth that doesn't require a new project. And so that's happening that scrutiny. It's not -- I wouldn't say it's geography or industry specific, though there's definitely some industries that have their own particular dynamics at the moment. And we've actually seen ourselves be quite successful through it, but it does tend to elongate sales cycles. We saw a little bit of a shortening of contract duration in the last quarter. We don't worry too much about the kind of duration for this kind of production data system. If you're using it, you're probably going to keep using it. And so whether you're committing for 3 years or 2 years, it's kind of very similar. So -- and we saw good growth on kind of cRPO, but you would see some impact in total RPO.

Yes. I wanted to ask a couple of questions on stream processing since you kind of expanded your TAM with Immerock going into Flink as your main kind of stream processing engine, I guess, underneath. I want to ask you in terms of the value a customer gets from stream processing versus using the real-time streaming platform itself, right? How does it -- how do you delineate between that?

Yes. So the purpose of these streams of data is partially to get data from point to point and then partially to be able to act on it. The applications that do smart stuff in reaction to it. There's capabilities within Kafka that will allow them to do some smart stuff in their application. But what we're doing at Confluent is kind of pooling more of that application logic into our platform and making it easier and easier to build that kind of application. And so we have a couple of pass with that. But one of the biggest ways is a technology called Flink, which is one of the most -- it's probably the second most popular open-source thing in the streaming space after Kafka. We're adding that to our cloud offering. We made an acquisition that brought in a lot of the core people in that space. And we think that's a great opportunity to extend our reach, monetize more of the application development around streaming data and just make it easier to add more and more use cases in this area. So I think it will be an accelerant for us in a number of different dimensions, making it easier for customers to get the thing they were going to do done faster as well as allowing us to more completely monetize the application that they were building as well as creating more incentive to become a Confluent customer and use our offering.

Yes. Understood. You do have a few -- you had a few stream processing capabilities already, ksqlDB, stream -- Kafka Streams as well, right? How do you kind of think about unifying that from a sales perspective?

Yes. Yes. So Kafka Streams was the kind of capability that was there in Kafka. It's probably the best like embedded in your application solution. This is like a complete framework and now cloud offering that will allow you to kind of just run that application in a fabric, which takes over the resilience and scaling and so on. And so yes, what does Flink bring? It's a complete cloud solution for stream processing as we add it to our offering. And it's just more complete in terms of vision it covers, SQL and different programming languages, different interfaces programmers would have for streaming data. And so it's probably the most complete kind of community and technology for accessing streaming data. And it was a very natural thing for us to add because it had such a kind of high attach rate among our customer base, among the open-source Kafka users. And we felt we could do kind of a uniquely good job at adding this into the platform and creating a unified product around it.

Yes, understood. I wanted to ask you a high-level growth question on kind of sustainability of growth, right? You're in a large market, which is kind of gaining relevance. There is a low-hanging fruit of free Kafka users that you can go after. You're expanding the TAM with stream processing recently. How do you think about the organic growth of the business in the medium term, right? You're guiding to in the -- somewhere in the 30s, I think about 30% for this year. Is that kind of the zone that you think is sustainable for a few years? Would you say the business -- or would you say the business is in a state of maturity at this point that sustainable growth might be a little bit lower. How do you answer that question?

Yes. I think that there's a set of tailwinds. You hinted at some of them, right, which are pretty powerful for us, right? Even if you just look at the conversion of open-source Kafka users to Confluent customers, we're still in the very early days of that. That pool of open-source Kafka users is growing rapidly. If you just look at our NRR last quarter, even in a tighter macro, 130%. And so that obviously gives you kind of a base that makes sustaining growth easier. And we believe that this is really emerging. This area of data streaming is emerging as one of the major data platforms in the company. And so both the number of companies that you're going to have it and the importance and prevalence of it within each of those companies is going to continue to grow. And right now, we have the leading technology in that space by far. And all of those are kind of important tailwinds when you think about, okay, how long can they keep it going for. We'll get a little bit more into some of the modeling, et cetera, in our Investor Day, which is coming up in June. So those who want to kind of dive into it with our CFO, that's a great place to tune in for.

Sounds good. Let me see if there are questions in the audience. Can we get a mic?

Jay, one big picture question for you. Just the value prop that you're articulating seems really compelling. But just looking at history, there have been very few big open-source companies created, right, maybe Red Hat and arguably Mongo are the only two. And by the same token, there have been, I think, few, if any, big data integration companies created. You look at MuleSoft, Alteryx, whoever you want to choose. And so just looking forward for your path to scale as an open-source data integration company, what has changed that would produce a different outcome from what we've seen over the last 20, 30 years?

Yes, that's a really good question. I think there's actually 2 questions there. So the first is around open-source. The second is around integration. I think the answers are actually different between the two. So on the open-source side, there's many ways of grouping companies, but the big thing that's changed is the cloud, and it's actually a very substantial change in business model. And so if you look at some of the earlier open-source companies, they're effectively trying to create an offering around software that was freely available. And if you think about, well, hey, how can you build a kind of sustainable moat and competitive advantage that allows you to capture a lot of value that others can't if they can have your software? I would say that's actually very hard to do, right? It's not impossible. Red Hat somehow did it, but effectively, nobody else did it. And if you look at some of the companies that tried like maybe a Cloudera, you saw kind of exactly what you would expect from like an ECON 101 point of view, which is competitors develop that have more or less exactly the same offering, the price has kind of competed down to the cost of offering it, it basically doesn't work. And so what's different now in the cloud is actually a cloud service is totally different. It's totally different from like single server software download thing. What runs our cloud offering is a massive chunk of extremely differentiated software. You can read about it. We did like a blog post that dives into this. That back-end engine Quora, it's a phenomenal piece of technology, and it's significantly better. And so we have a lot of the advantages of open-source, which is like, hey, we're doing something quite different. This category is new. If we were kind of going door to door, trying to convince people to think about data in a new way, that would be a very difficult proposition to make successful. The open-source really helps us attach to use cases that are real, that are out there in the world that are happening, and then the cloud service allows us to monetize that. And if you look at this next generation of companies that are coming, I think MongoDB has done a great job. I think there's a number of others that are kind of maybe that late-stage private and earlier, they're actually doing quite well. And it is actually just a completely different business model than Red Hat, even though they both involve some element of open-source. We're just -- we're not selling an offering that's based around support. We're selling an offering that's based around software. So that's the answer on the open-source side. On the integration side, this is another good point. So like there's been a bunch of technologies that move data in some way. And you can look at the kind of TIBCOs that we're maybe doing real-time data at small scale, low latency between custom applications. And so then you would have maybe your Informaticas, which are doing relational data at large scale, very high latency like once a day between databases. And then you would have maybe a MuleSoft, which are integrating API-driven stuff in real time, not a very large scale, not handling transactional data. So it's like each one of these data movement things had a lot of asterixis. It could do parts of the problem, but it couldn't do the general problem. And if you think about this particular space, that's actually terrible, right? The whole point is, let's say, you're a retailer and you have the stream of what's selling. Is that going to go into analytic systems like an ETL product would solve? Yes. Is it going to impact your production applications and need to go into some of those? Yes. Is it going to feed into operational databases? Yes. Is it going to go impact SaaS applications? Yes. You need to reuse that data across all of this. And so having whatever it is, a dozen point-wise technologies that do part of that problem is not good. And so what's happened in this space is the revolution in distributed computing has allowed a much more powerful approach to this. It actually is real time, is scalable, can handle integration with batch stuff and is a platform for very rich processing of data and application development in a way that none of the previous stuff was at all. And so that's the answer of how you go from a bunch of little segments that all have a couple of billion in revenue to something that's much more significant. And you can see that in both the adoption statistics and the usage patterns, how it's used, the role in the companies that have adopted this at scale? And then just Confluent's growth as well. I think all of those are data points that would support that.

Jay, you talked about architecture of the future. Just thinking about that. I get how Flink moves you up into the application stack. How do you think about moving down into the database layer?

Yes. Yes. In many ways, you can look at this kind of area of data in motion as parallel to like data in rest where it was like kind of file systems, databases, et cetera, and I think the stack is very similar to that. It's solving a set of application development needs, kind of the flow of data. And yes, I do think a chunk of what it ends up taking spend from is these kind of integration technologies, but a chunk is also databases, which are used either for batch processing, used for kind of application development, some of those are now moving into this kind of real-time streaming world, and that's a chunk. If you look at our TAM, there's a chunk of it that's absolutely attributable to that. And if you look at our customers and you say, "Hey, where did this money come from?" That's the budget it comes from.

All right. I think we are out of time. Thank you so much, Jay, for all the insights.

Yes. My pleasure. Thank you, everyone.