Transcript.

Peter: Barzan, welcome to the IoT Spotlight Podcast. We're excited to have you here and learn more about your work at Keebo.ai. Please, would you mind briefly introducing yourself and your history in academia and business and give us an introduction to Keebo? Thank you.

Barzan: Sure. Thank you so much for having me. I'm excited to be here. I think you summed it up pretty accurately. So I'm a co-founder of Keebo, also CEO. Prior to that, I'm also an associate professor in Computer Science at the University of Michigan (Ann Arbor). Prior to that, I was at MIT, UC Berkeley, and UCLA. Before that, I also worked for a number of companies along the way, both startups as well as large companies. But I would say the last two decades of my career has been an intersection of machine learning/AI and database systems, essentially pursuing this idea of how we can actually leverage AI to build smarter data systems. The word smarter would mean faster, more scalable, easier to use, easier to deploy, et cetera. We've done some of that work in the context of transactional databases. Some of the algorithms we've put out there are now default scheduling algorithms on millions of MySQL servers and other variants of it in the open-source community. But some of the work we did on analytical databases, approximate great processing of what now was commercialized and acquired by software companies.

The context of this conversation is the latest spin-off from my research. It's a company called Keebo.ai As you pointed out, it's based on a new concept called data learning that one of my former PhD students and I came up with in our research. We named the company Keebo, which apparently in Japanese means "hope". So the idea was when all other hope is lost, you can leverage AI as your last resort. And that's how Keebo came about.

Peter: Excellent, excellent. Thank you very much. I think, yeah, that makes absolute sense, right? We are duplicating data, I think, every year. We are running smaller data centers, usually as four systems. But that is really a challenge, so maybe we should talk about how we can work on that here as well. It would be interesting.

Barzan: Absolutely.

Peter: Could you explain how Keebo's data learning technology differs from those traditional data warehouse optimization solutions?

Barzan: Absolutely. So traditional query optimization—whether you go back all the way to system or all the way to modern cloud data warehouses like Snowflake, BigQuery, Redshift, and others—the whole idea of query optimization is how do we get, by giving a query, how do you pick a query plan that gets you a relevant data as efficiently as possible while avoiding irrelevant data as much as possible? That sums up 40 plus years of research on traditional query optimization, right?

If you think about indexing, what does indexing trying to do? Indexing is saying, "Hey, here are the tuples that you need." Skip, instead of scanning the whole thing, right? What does Columnstore doing? Columnstore is saying, "Hey, just read these columns. Their query is accessing. Compress them, so you can access them more efficiently, and skip the columns you're not reading," right? That's exactly what caching is doing. Parallel is doing the same thing. How do we process those relevant tuples? So that's the whole idea. You look at one query at a time, and that's how you decide. Whereas data learning is a whole layer above that. So we're not replacing traditional query optimization. What we're saying is that whatever database system you're using, whatever query optimization you're using, with data learning, it's going to be orders of magnitude faster and cheaper than query optimization without data learning.

So what is data learning? So from a high level, the goal of data learning is to learn from how users and applications interact with their data and then leverage that, build models from that, that can allow us to automate and accelerate the tedious aspects of the interactions between the two. And why is that important? Because if we automate and accelerate those tedious interactions, you can actually significantly reduce the burden on your data team. You can significantly reduce the cost of your infrastructure, and you can significantly boost performance, right?

Peter: Yeah.

Barzan: I'll give you one example of how this would work. So let's say you're spinning up a medium-sized Snowflake warehouse. Right? You have millions of queries running on it. Are you actually sure that you're using 100% the resources of that medium warehouse 24/7? We've never seen that. It's probably that, hey, there are times where you could actually leverage a large warehouse to process it faster and cheaper. And there are times where that warehouse is underutilized and you reduce it from a medium to a small. So you can do those things manually. You cannot have even the most experienced into the ASIC DBA to stare at millions of queries throughout the day and then wake up at 2 AM and say, "You know what? I'm so excited to reduce the size of this database from this warehouse, from a medium to small," and then, seven minutes later, restore it to its default size because the load increased, and then go back to sleep. That's exactly where AI comes in. It's what I call an infinitely patient, infinitely knowledgeable, and infinitely competent DBA. It can come in and come in and throughout the day make sure that all the settings are optimal and, by adjusting it in real time, significantly reduce the cost of your infrastructure.

Peter: Okay. Then how do you show value in 24 hours? I went on your website, and I see you can show value within 24 hours. So there will be measurable results within the day? How does that work?

Barzan: Yes, exactly. In my previous startup, we were selling database systems. I think your audience might need the context of why we actually built something that delivers value 24 hours, right, and then we can talk about the how. Most of the enterprise world is plagued with, like, "Hey, here's a new value proposition for you. Let's bring your team on. We need to do a POC for month, two months, three months, six months. We're going to learn this new API. We're going to install this new software. We're going to train your team. We're going to rewrite your code, and then we're going to hit the success criteria." That was too slow for my taste. Right?

So, from day one, before we wrote the first line of codes, we came up with four guiding principles that we said, whatever we do, have to actually respect those four things. The first thing was that we shouldn't need any of that nonsense. It should take no more than 30 minutes of one engineer's time to set up with Keebo. So that means no data migration, no data copying, no rewriting of code. Nothing like that. So we used to joke that if we ask a customer, if we require a customer to spend more than 30 minutes onboarding with Keebo, we should send them an iPad for free. To this day that we're talking, we've never had to actually give away an iPad. The second reason was, the time to value should be insanely short. So instead of like — you know, because talk is cheap. Telling customers, "We're going to save you money on your Snowflake. Wait until your renewal," Keebo customers see actually reduction in their Snowflake bill within 24 hours. We have customers who are saving 80%. They've slashed their Snowflake bill within 24 hours by 80%, 20%. It doesn't take a lot to spend millions of dollars on Snowflake or hundreds of thousands.

How does it do that? That's the whole idea, right? Because it's not manual. Because AI can immediately pull data from the last 90 days of history on that warehouse, immediately changes models, figures out how to pull those knobs, and then customers immediately see very viable savings within 24 hours. You just look at your bill. Without any impact on your performance, you notice that, hey, compared to yesterday, you see a very significant, noticeable drop in your spend.

Peter: Cool. Okay. How did you come to the solution? Is that based on your background in academic research? Has it influenced a lot, the approach you're taking now?

Barzan: No, for sure. I think a lot of how it came about, how we do it and where it came from, I think it's, usually, people only see the success. They're impressed by it, but they forget like behind every success, there's other talent that we tried in academia and the data world. So yeah, it was years of academic research. I sometimes joke with people and tell them that the reason Keebo is successful is not because we have very charming salespeople. It's because of the technology itself.

If you think about it, the entire cloud data warehousing is a perfect match for leveraging AI, in particular reinforcement learning, which is these days even more important because of LLMs and GenAI. So you train an agent. You tell this agent, basically, you create a reward function for it to say, "Hey, every time you pull a knob, if you can't slow down, you get penalized. Every time you don't cause slow down and you save money, you get rewarded." Then you start actually training on that metadata in real time, and you monitor the performance. Then you can act really quickly. Whereas like a human, if you escalate the performance problem to a data team, you have to Slack them. You have to contact them. You have to do the investigation. You're looking in the middle of an hour, best case scenario, before they can figure out what happened, how to fix it. With our models, we can act instantly. We see those things. We analyze it. The models analyze the situation, all of that stuff.

You're right. There's years of academic research behind it. We actually have patents in the space. We've published some of our algorithms and peer-reviewed conferences like Sigma and elsewhere. So a lot of it is based on research. We're not just doing the same thing. I usually joke with people that working for Keebo is very rewarding but also pretty intimidating. Because what we do is, to give you an example—with all due respect for key value stores; I use it as an example—if you decide to join a company that's building a key value store database, it's perfect because there's hundreds of other tools out there, open source. And if you ever get stuck, you can go and look at how others have solved it, right?

But with Keebo, we're definitely the first. Typically, when we run into a problem, we're the first people to run to that problem. And it's not like, "Hey, I can tell you go and open that textbook. Page 205 explains how to solve that problem." It's usually a new problem. You need a new solution. It requires research. That's why we have a lot of team members who have PhDs in machine learning and database systems, who can actually take on these open-ended difficult problems and come up with creative solutions that have never been experienced before.

Peter: Okay. Is there any specific — you don't have to drop any names. That's probably not really, really possible. But is there a use case, a specific case study, you could talk about?

Barzan: Absolutely. There's plenty actually. I can share the ones that are also publicly available on our website. For example, we've had this case study with one of our customers, Costco. Basically, their spend dropped by 50%. We literally slashed their cost by 50%. I think the manager there, he was saying, like, after a few months, they wanted to verify that it's actually Keebo that's saving them so much money. So they decided, "You know what? We're going to disable Keebo for a week or two to see what happens." I think after the first 24 hours, they're like, "No, that's enough proof. Let's just turn it back on. We can't afford this exercise."

Peter: Seriously? Okay.

Barzan: Yeah, it's actually out there in the public list. You can look at it. We've had situations where people won — what's it called? I think I forgot the person who implemented Keebo. Their CFO gave them a CFO's strategic initiative award because they were able to save the company overnight $500,000 in Snowflake spend.

Peter: Wow.

Barzan: We have Hyperscience, a company that leverages AI for document processing. I think they're saving about 70%, 80% on their Snowflake bill. So if you think about it, it's like you are spending — for every $5 you used to spend on Snowflake, now you're spending only about $1 or $2.

Peter: That is really impressive. Okay.

Barzan: I thought of one we did, to sort of put things in a bit of a context for your audience. One of the other decisions we made, I mentioned too often, is that it should be a 30-minute onboarding. Time to value should be 24 hours. Another decision we did make was that it should be a no brainer from a pricing perspective. So by default, Keebo's pricing model is that, we don't ask you to take our words for it. We just charge you a percentage of whatever we save you. So no savings, no payment. So if we save you, for example, $3 million, you pay us let's say $1 million, just to make an example. If we save you $300,000 — for every $3 that we save you, you give us $1. You keep $2. That means you don't even need to have a budget for Keebo. Keebo comes up with its own budget. You don't have to lift a finger. It's fully automatically for every $3 you produce out of thin air, we give you $2, and we only keep $1. That really helps with the adoption as well.

Peter: That's how you sell energy-saving solutions as well, indeed.

Barzan: Exactly.

Peter: It's good. It's a good business.

Barzan: Because if you think about it, when that aligns our incentives with the customer, it means that — meaning that we're not successful until and unless the customer is successful. And the more successful they are, the more money we make. So I think that's created a lot of harmony between Keebo and its customers.

Peter: Cool, cool. Very, very impressive actually. Then there was always a privacy concern when we talk about AI now. From my perspective, I don't really see a concern here, but I guess maybe the audience wants to know are there any, how do you address those security and privacy concerns that are now often in discussion when AI comes into hand?

Barzan: It's very real. The second the word AI comes out of your mouth, people ask about compliance, privacy, security. So that was actually the other thing we decided to address heads up. From day one, we decided that for you to be able to stay with Keebo, you shouldn't have to share any data with us. Actually, our AI doesn't even need to see any of your data, not even your query text. Actually, we hashed the query text as well. So our models, we decided from day one that we're going to train models exclusively and only on your metadata—so information that actually is not sensitive at all. Things like, hey, how many queries arrived, what time they arrived, how long they spent on the queue, how many bytes they scanned, how long they took to execute, how many credits they cost the customer, what was the cost of it, what was the size of the warehouse when they arrived. That's all metadata, telemetry. Performance telemetry—that's all we actually train our models on.

So when users are onboard Keebo, they create a Keebo user, but they create a view that only gives the user, the Keebo user, access to that non-sensitive metadata information. So even if we wanted, we couldn't actually see the customer data. That's an extra layer of protection and peace of mind on top of all the other best practices we do. Like always, even the telemetry use encryption address in transit, SOC2 compliant, Type II compliant, SOC 2 Type II compliant. Sometimes we get in front of security review teams, especially with public companies. We've had situations where, within the first five minutes, they're like, "You're wasting our time." I don't see any risk here. Just continue. Because you're not seeing our data. So that's why we have a lot of public companies that leverage Keebo. Some have actually Snowflakes, largest customers. We serve customers of all sizes, from companies with as little as like $100,000 a year spend on Snowflake, all the way close to $20 million a year spend on Snowflake at the same point. But that's because we decided to address the security concerns from its root.

Peter: Yeah, it's a key topic indeed. Great. Yeah, good to hear that.

Peter: And you, you are a big promoter of IT solutions, of AI adoption. So how do you think the whole adoption of AI could accelerate? What do you think are the main barriers here? Is it also related to security and privacy concerns? Are there other barriers? How do you see that could be accelerated, and how do you address that in Keebo?

Barzan: 100%, that's actually a very good question. I think a lot about this, and I've been thinking a lot about it. I think there are four major barriers in front of AI that doesn't stop AI's adoption but has slowed down AI's adoption compared to what it should have been in practice, right? I put them under four different categories. The first one is obviously the implementation barrier. A lot of times, if you look at the AI solutions out there, they require a lot of upfront investment. So they go, and you have to take it on faith that there will be ROI. You go there, and you have to have a whole team of engineers, ML experts, ML engineers, various solutions, implement them, a POC, several months implementation effort. And that's definitely a barrier. So that I would call the implementation risk or barrier. That's why at Keebo, we decided that whatever we do, it shouldn't take more than 30 minutes of one engineer's time to onboard and implement. After that, it should be certain — forget it, like it shouldn't be something that requires constant oversight.

Then the other thing is the ROI or time to value. Like if you basically have an AI solution where you tell people, "Hey, why don't we implement this thing? Let's train the model. Let's clean the data. Let's fine tune it together. Let's spend a whole year before we can actually see any value out of it," it's going to be too late, right? By the time people see the value, it might be too late. So we've also addressed that by making sure that people see the time to value being really short most customers seeing savings, actual savings, within the first 24 hours.

The third category of adoption risk is what we talked about earlier, which is the security/privacy part. And that's because, obviously, people keep their most valuable digital assets in their cloud data warehouse. Right? So for us to be able to do that, I think I really encourage entrepreneurs and innovators to think about how they can actually ensure privacy and security or give those assurances to their customers and users. In our case with Keebo, the way we did it was like, "Hey, you don't need to actually give us any access to your data. You could just start leveraging Keebo by letting it train on your telemetry metadata, which is not even close to confidential. We even skip out like user names and quetext and all of that stuff.

Then the final category of adoption barrier, I would say, is the pricing. A lot of CIOs have been burnt out by people promising to deliver value. But then at the end of the day, they fall on their face. I think if you come up with a pricing, aligns your incentives with your customers, that significantly eases you into the adoption path. So in the case of Keebo, as I mentioned earlier, our default pricing is you just pay us, let's say, one third of whatever we save you. If we don't save you anything, you don't have to pay us. And if we save you, we've come up with our own budget. You don't even need to come up with a new budget. So I think those are the four main categories that significantly help with the adoption of AI across the board.

Peter: Thanks. I got another question. So Keebo focuses on the high-value problems. Can you elaborate on the concept? Why do you believe that's crucial for AI implementations?

Barzan: That's a really good question. If you think about it, like, in this economy, a lot of companies are struggling with their cost of goods sold, with their operating costs and whatnot, right? So if you think about what cloud data warehousing has done, it's that the likes of Snowflake, BigQuery, and other cloud data warehouses, they have significantly reduced the adoption barrier. It's so much easier now for any organization, any data team of any size, to start tapping into data without having to do what people used to do. A decade or two ago, you had to go and buy a bunch of Oracle licenses, buy a bunch of hardware, hire DBAs, spend six months provisioning and installing and tuning. You can actually start querying your data, upload to your desktop, querying it in less than an hour now, right?

But that lowered adoption barrier has had some side effects. As a result, now more people are querying more data and doing more complicated things with it. So, as a result, these data pipelines that people having with cloud data warehousing is way more complex than what they used to be two decades ago, for example, or a decade ago even. So these complicated pipelines are very, very difficult to optimize, to hand-optimize, and they're very costly to maintain and to operate. So the cost of cloud infrastructure is going through the roof for customers. The interesting part is that—a lot of your audience who are working for mid-sized companies as well, then they know this—you don't have to be a massive company to incur massive cloud wealth. You can't just say, "Hey, because you're costful, you're spending millions of dollars, or you're Logitech, or you're this large company, you're spending all millions of dollars. But here's a mid-sized company or a small company, therefore the bill is small." That's not the case anymore. So cost is a real issue.

Essentially, what cloud data warehousing has done is that they've reduced the adoption barrier, but they've increased the operating barrier. So the cost of using these tools is going through the roof. You can't keep hiding more data engineers and DBAs and software teams and data teams to keep optimizing the system. The idea is these systems should empower these teams. So that's why we think reducing the cost of your infrastructure and freeing up your data team's time, and giving that visibility and observability to your decision makers about where the cost is going, how you can reduce it, et cetera, et cetera, I think that is the high-value problem, as opposed to like, "Hey, we think this single query over here, if you did x, y, z, it could run 20% faster." We don't think that's actually what the high-value problem is.

Peter: Yeah, I agree. Yeah, it makes totally sense, actually. In line with the whole solution, looking at those traditional data engineers, how do you see their role? And in the future, if everybody is implementing a solution like Keebo, where do they end up? Do they have to reeducate, or do we still need the traditional data engineers?

Barzan: That's a very relevant question actually. I think what's happening with GenAI, the Copilots of the world, and all the automation and AI use cases that are coming around, I think a lot of engineers, including data engineers, not a lot of them, but a good percentage of them are worried that, "Hey, maybe it's here to take your job away." And as someone who comes from the academia, my message is that if you think that AI is coming to take your job away, it probably is. Right? So the solution is not to resist it because you cannot resist, you cannot actually fight that momentum. Like, if you're someone who's trying to protect their job by not leveraging AI, you're going to be crushed. Because you're standing on the wrong side of history. This is happening. The way to protect your job is not to run away or resist the adoption of AI, but rather to embrace it and learn how to use it more effectively.

So the way to protect your job is not to say, "We don't need AI. It's too scary. We don't know what's going to happen." But the solution is, if you did not take an AI class or a machine learning class when you were at school, go back and take an online course. If you did it, by the way, a while ago, go brush up on your stats class. I mean, these days, there's no excuse. You can find plenty of free lectures online. Go and take an online course on machine learning. Do a POC with a few different AI tools and different things. Go download Keebo. Go install Keebo. It's going to take you half an hour, and then you're going to learn how this thing works, right? Where humans, I think, in general, and data engineers in particular, are going to add a lot of value if they realize this is — Keebo's approach is, there's things that humans cannot do and don't want to do. And that's what we're leveraging AI for.

A human — like I've spent the last 20 years of my life working on the database system, building up, selling them, teaching them. Right? Like, if you show me a two-page long SQL query, I'm going to be draining it. I don't like to spend half a day staring at your query and figuring out why it's slow. That's one query. What if you have a million queries? It's just not humanly possible for me to manually optimize it, number one. And number two, even if I could, it's just not a fun thing for me to do. So we are leveraging AI. Keebo is leveraging AI to do the things that humans cannot or don't want to do more effectively. But then you need the domain experts. You need those data engineers to come in. And like Keebo, for example, the way it works is that it has guardrails. Someone has to go in there—the data engineer who understands the application, the needs, the SLAs, the performance requirements—can go in there and say, "You know what? I want the AI to only operate in this region. I don't want you to ever go beyond an x-large. I don't want you to ever spend more than this many dollars on this application. I want to make sure that the 99% latency stays within this, within that." Right? So then domain expertise and that guideline and those guardrails should come from a human who understands the business needs and logic.

We're very far from being able to understand business logic and business requirements. That comes from years of experience talking to stakeholders, et cetera. That's where the data engineers can focus on, right? So, much in the same way where if you're driving an autonomous car, you're in the car, and you put in the address you want to go, and you bring your preference. I want you to stop at a coffee shop on the way. Like, that's what your real role is: to make sure you give the right directions and then basically let the AI take care of it. It takes away the fear. It keeps your job and actually puts you in a much higher position on a payday. Because now you're someone who knows how to leverage AI and be a force multiplier for their organization. I think that's probably the first thing that people can do.

Peter: Yeah, it makes totally sense. I hope a lot of our tech friends here hear what you say. It's very relevant, I think. We've got to use it in the right way.

Barzan: Yeah, absolutely.

Peter: So, looking five years ahead, where do you think the whole data warehouse in another two spaces is heading and coming five, two, three, five years, whatever you believe is relevant. Five years is a long time, actually.

Barzan: It is. It is in some ways. But things in life, you know, time flies, right, as well. So just based on the trends we're seeing, I sometimes joke that predicting future is very easy. Because no one is going to remember and come back and tell you, "This is what you said five years ago," right? But in some places, it's also very hard because a lot of things can happen, like you said, over the next five years. But I think what we can tell, with a reasonable degree of certainty, is just looking at the whole landscape, we've gone from on-prem installations and one-off solutions and a bunch of silos to this cloud data warehousing turnkey adoption of data across the organizations.

But I think the next milestone that we're going to witness in this kind of evolution of cloud data warehousing is that, when we look at the landscape today, there's a lot of people building things they should not be building. So engineers. And I can say that as I know you're also in the technical background. But as someone who comes from an engineering background myself, we engineers have a natural tendency to always want to build things.

Peter: Yeah.

Barzan: It doesn't always make sense to build. Sometimes it's significantly cheaper, way faster, and definitely wiser to buy instead of to build. Like for instance, my favorite example is there's this company. I can't mention their name. They're an online marketing firm, right? That's what they do. That's their business. They were also leveraging Snowflake and they're spending millions of dollars on it. We crossed paths with them. We did a POC. Keebo was able to save them—I don't remember the exact number—like 25%, something like that, a significant amount of money. There was no effort on their part. They could just sign an agreement and then keep it in there and then they just take the 25% of their bill home every month. There were two engineers on that call, I'll never forget. I sometimes still jump on these sales calls just to hear customer feedback. And I don't think I'll ever forget their comment. They were like, "This is pretty cool. But we're thinking maybe we should just build this in-house." And I was just staring at them and I was like, "You guys are going to build this in-house?" They said, "Yeah." And I said, "Okay. How long do you think it's going to take you to build something like Keebo's house?" They're like, "Yeah, well, probably three to six months." I said, "It's going to take you three to six months?" And they're, "Yeah, because we're not going to work on it full-time. We're thinking maybe like on the weekends, we'll look at this and then go out with this."

So here I'm sitting, thinking to myself, I have an army of database and machine-learning PhDs. We've spent years building this thing, and it's taken us years to get to where we are. Here, you're seeing two engineers. Just two. At a company that has no business building their own cloud optimization tool. They're in an online marketing business. These guys should be spending every minute they have trying to grow their own business, instead of building something that they could just download online or buy for a fraction of the cost. Because then they also have to maintain it. There's no way they're going to come up with what we have built after all this investment. And not only that. They think they can do it in three months. And not only that, they think they can do it just in three to six months, just working on the weekends.

And this is, believe it or not, this might be an extreme example, but it's more common than you might think. A lot of data teams make the mistake of wanting to build everything in-house. A lot of managers and directors and executives are not technical enough to be able to step in and say, "No, no, no. We're not doing this. We have no business." If I'm a bank, I have no business building my own database. I need to be focused on how to provide better banking service to our customers. That's not core to my main mission." I think that trend is going to change. I think execs are going to get smarter about buying, right? This used to be people's mindset. It used to be every big tech company building their own database system, building their own logging infrastructure. But people have realized like, "No, I'm not Google. It doesn't make sense for me to build everything in-house." There is opportunity cost. There's a maintenance cost.

I think the biggest thing that's going to change over the next five years is that a lot of those teams are paying that price. The managers learned the hard way. The execs get more sophisticated. They're going to step in, understand that 9 out of 10 times, it's better and cheaper to buy versus build because of all those reasons.

Peter: Makes sense, yeah. And now we are already coming to the end. You also have to head for another meeting. So one last question, maybe. You know, AI is developing fast. We all know it. How does Keebo stay ahead? How do you stay ahead of the curve and continue to innovate, maybe as a last comment?

Barzan: That's a great question. I think there's two parts to it. Like, if we stop innovating, we become irrelevant. Again, back to what I was sharing at the beginning, the reason we've been successful is not because we have charming sales reps. We have charming sales reps, but that's not right. The reason is because the product itself is outsmarting everything else that's out there. So the second that we feel satisfied and content with what we have and stop investing in R&D and stop investing and improving our product and stop listening to our customers, their feedback, and trying to improve the product every single morning that we wake up, I think we're not going to stay ahead. So we're going to do exactly the opposite. Every single day, we're listening to our customers. We're iterating. We're investing and improving our algorithms. That's how we're going to stay ahead of that curve. That's how we're going to maintain our leadership in the space. Keebo is a market leader in Snowflake optimization, cloud data warehousing optimization. By the way, those of your audience who are using Databricks, we also have upcoming support for Databricks. So reach out if you're interested.

If you have other priorities aside from saving cost, that's a perfect time to reach out to Keebo. Because when you don't have time to spend on saving money, that's exactly when you need to be using Keebo. Because Keebo can continue to save you money in the background automatically while you focus on your other priorities. All you need is one engineer's time, for 30 minutes, to onboard. And it's set and then forget it. So we're going to keep doing that. And I think for as long as people are growing the data values, which I think is going to continue, we're going to be able to deliver value to those customers.

Peter: Awesome. Thank you, Barzan Mozafari. Really, really interesting to talk with you. I hope everybody enjoyed it. I'm sure everybody enjoyed it. I hope we will maybe see us in person at some point in time. It would be nice to welcome you to China.

Barzan: Thank you so much. I know we both share a passion for tea. So, hopefully, in my next trip to Shanghai, we'll meet up in person. But thank you so much for having me and thanks to your audience for tuning in.

Peter: Awesome. Thank you. Thank you.

Barzan: Thank you so much.

Peter: Take care.