 Welcome back to SuperCloud 3. I'm John Furrier, Dave Vellante, live in Palo Alto Studios, second day of two great days of security plus AI. That's the theme for SuperCloud 3. SuperCloud 4 is coming up in October. Mark your calendar. That's gonna be all about AI. This session actually is a lot about AI and security. We're gonna find the truth in the data. Joel Inman, who's the CEO of compute.ai. Check it out, I love the domain name. Joel, great to see you. Keep alumni in a while. How's things? Thanks for having me. Things are great. I just got started coming back into the space after a time away and I was able to be reintroduced to Vikram Yoshi, who's the founder of the company and really excited to partner with him. He's supposed to be here today. Couldn't make it, had something going on. Really appreciate you guys coming on. We've been unpacking SuperCloud 3 episodically every quarter. This one's about security and AI. Obviously the data has been a big conversation. If you look at the forcing function of this next wave that's coming, the AI certainly over the top is powering a lot of activity in the developer community as well as companies. So security is an operational thing. So data now is continuing to inject a forcing function in how people are organizing how they do cloud and how they do on-premise hybrids and certainly with the Edge as well. What's your take on SuperCloud as this evolves into the next layer of IT coming? It's the same game, new variables. What's your view of SuperCloud? Yeah, I think it's really driven by people needing to get more out of their data, to get those deep meaningful insights out of their data. And the demand for analytics is about three, four orders of magnitude what it whatever has been before today. And it's just growing. I mean, AI ML is kind of the accelerator on top of that. But if you look at what's happening right now with just cloud infrastructure and the need to scale out and support those massive complex workloads, that's where we are today. And we're at an inflection point where that demand is only going to get stronger. So there may be a security angle here, but we were talking off camera about the semantic layer. And we talk all the time about the single version of the truth. It's been like the holy grail and tech forever. Data warehouses didn't do it, MDM didn't do it. Lake houses haven't done it. So what is your story around the semantic layer? That's a great question. And kind of that goes to the heart of the founding of Compute AI. Data warehouses and data lake houses have been a great step forward in kind of building these repositories where we're trying to analyze the data, right? But you need to connect that data. You need to have that tissue across your entire organization in order to go a level deeper and understand what to do with your business. Compute.ai and what we're doing, our vision for the future is really separating Compute from data management. The reason why we've had Compute as part of these relational database architectures has been it was convenient, okay? But now the demand for that Compute is skyrocketing and having that Compute trapped in data silos is no better than having data trapped in data silos because it starts to break down. There's not concurrency and the costs kind of get out of control as you start to try to feed the super cloud with that kind of infrastructure. So contextualize this for us because we've been talking about this the last couple of months and the last couple of decades really. But so you take Snowflake, what it did. So it separates Compute from storage, but it doesn't do what you're saying because you still put it all inside of Snowflake. I think I'm inferring. Look at what Databricks did at its recent show and it's basically building out a data mesh with its lake house, being able to connect even any data, Snowflake or whatever. Now of course, Snowflake is also connecting different data types. What's different about your vision? So the difference of separating Compute and our product is called pure Compute, right? Because you really want to get that Compute set aside. It's building Compute into the fabric of your server infrastructure. So we envision a Compute engine on every server and interacting the data in a very open and scalable fashion, SQL directly on files, taking that relational component and then plugging in a Compute infrastructure that is inherently reliable, that is highly memory efficient and that is able to scale from a tiny server from one node up to hundreds of nodes, thousands of users. You can hit it with different workloads. You can hit it with ad hoc queries. You can hit it with batch processing. It doesn't go down. It doesn't fail and the costs are linear as they scale. You're just simply benefiting from the elasticity of the cloud that you're on. And then I'm going to have data and different data types. I'm going to have different query mechanisms and you're saying you basically, I think I'm inferring translating it all back into SQL to make it simple, but I'm going to have vector database. I'm going to have graph database. I'm going to have relational. I'm going to have structured. I'm going to have unstructured. All those different data elements of today are incoherent. Now I can maybe bring in a DBT to KPI the metrics in a data warehouse. I can maybe do something with that scale, but it's still a real heavy lift. Are you, is your vision to change that so that all those data elements are coherent and can be joined at scale? Yeah, that's exactly what we're seeing and what we're saying. I mean, you said the keyword there DBT, right? And people are using that authoring tool to create their workloads and their pipelines and try to knit this data together. So when you're doing that, when you're creating the semantic layer, what you're doing is you're actually executing thousands and hundreds of thousands of joints, right? You're taking tables and formats and rows and columns from all the disparate areas of your business and you're putting them together into one semantic layer that is referenceable. And you said unstructured, it needs to have structure. It needs to have that kind of basic structure of a SQL engine. Just to not interrupt the cadence here, but real quick, define the semantic layer for the folks watching. Good question. We've heard of semantic web and we see chat GPD. Semantic layer, you guys are referring to a different concept within a data plane. Can you just explain what is the different layers? Our view of the semantic layer is simply metadata that connects the different data silos so that you can put it all together. As a use case for that would be, the benefits would be what? The use case to that would be reaching into all the different aspects of your business and really being able to analyze the ephemeral data that you don't have time to put it into a data warehouse. You don't have time to run the analytics and the statistics on that because if you take the time to actually put it into that data warehouse, it's gone. This is the key point. It's real time and this is why we use Uber. As an example, people places things, riders, drivers, ETAs, destinations, prices, transaction data, all different types of data, but to Uber, they're coherent and it's done in real time. They're not shoving it into a data warehouse, analyzing it and pushing it back out. Because the lag to value is but the data's worth anything. You never get the ride. It's gone, the moment has passed and you can't ever get it again. Okay, so this is the problem that you're solving. What's interesting here is if the snowflakes and the data bricks of the world don't own that semantic layer, what's going to happen potentially is like what happened to Oracle with BEA. They basically extracted that and the rest of the application world took advantage of it. So this semantic layer in terms of, in the context of real time, digital representation of your business is a next wave when now you start to bring in AI and there is a security angle here to be able to do this for security in real time. There's a narrow application and security but the applications are endless. Well, and there's also an open standards implication here too, right? We're seeing a lot of people move to the Iceberg Parquet format and that's what we support and that kind of needs to be there for the community at large to be able to utilize these times. When you saw that at data bricks, they said, oh yeah, we're going to take whether it's an Iceberg table or Hootie or Delta, whatever it is, we're going to translate it into Parquet at the back end and we'll take care of everything. So the Iceberg standard is emerging, everybody's leaning into it. Can you mention Snowflake and data bricks, Dave? I'd love to get your perspective guys on this. It sounds like this is disruptive to people who have an incumbent position. Yeah, I think it is. I mean, again, I think Snowflake is they have a database mindset that database guys came out of Oracle. And I think they're bringing in people with an application mindset because they want to be the iPhone, the app store for enterprise data apps. But in order to do that, if they want to serve those real-time applications, they've got to have at least some kind of relationship with the semantic layer. And personally, I think they need to own it to justify their evaluation. I don't know, do you have a thought on this? Yeah, no, I do. Our vision of compute, we believe compute is a new category. People have never really separated out before. In terms of being disruptive, that's not our goal. We're very collaborative and we want to partner with all of these companies, right? So we think we can fit. We love everybody. Yeah, we love everybody and we can fit right in there. As they lose their share. Okay. So I think that we're seeing the early days, we're seeing the need, we're seeing people have data warehouses and data lake houses both in their environment. I think actually you publish a stat, 42% of all customers have both. And so that speaks to the need here, which is data is everywhere. It's spilling out, right? And how do we make use of it? We need to make use of it with a relational structure, a semantic layer, and then the infrastructure to support that and the infrastructure to support that is going to be the super cloud. So in concept, how could you partner with the snowflake? I don't know if you are thinking about it, but how in theory could you partner with a, what is essentially a closed proprietary system like snowflake? Well, I want to dodge that question and talk about Spark, Presto, and Trino, right? Because those are the landscapes, the areas that we play in. Same question for Databricks. I mean, with the exception of, well, there's some propriety. Yeah, I mean, so us, we're a small piece of the system. We're kind of think of us as a coprocessor or a compute engine, right? So we go into that system and maybe it is a snowflake and you point dbt directly at our engine. So you have, you offload the compute and you say, computer's going to the compute engine. dbt is pointed at our product and then you load it back into your data warehouse. Or I could containerize your stack inside of snowflake. If you wanted to develop on top of snowflake, you could do that with what they've just announced. Yeah, I mean, the beautiful thing is about the vision is that we believe compute needs to be everywhere. Almost like the fabric, like VMware kind of came out in the early days. And so it needs to run almost like an operating system, unattended, you don't think about it, it's just there. And it's going to be at the edge. This is, I have no doubt that the likes of snowflake and Amazon and all the cloud guys are thinking about this, no question in my mind. It's just unclear to me how they play where the data is, which is everywhere. And you're saying compute has to be everywhere. And I also think the compute is going to be an ARM based processor that's low power, low cost and incredibly powerful. No? Well, my question on you guys is I love the name by the way compute.ai, great URL mentioned that at the top. What's the AI aspect of compute? Because we've had a lot of conversations in the CUBE over the past this session and before, how move the compute to the data because data egress is kind of expensive and moving around data, but also being smart. So having an AI component, where's the AI in the compute side of your play? That's a great question and prepare yourself for a long winded answer. So I'll try to be concise. It's okay, take your time. So the first part is we use AI ML in our product, right? And we use it to page to disk elegantly. So within our code, we use these algorithms in order to garner memory efficiency that has never been seen before. So bypassing the memory bus throttle that prevents CPUs from being 100% utilized. So if that makes sense to you, we can run CPUs at 100% utilization, even over commit CPUs, over commit memory and have a spill to disk that is very elegant. And so that's where we have the cost efficient piece of our product, right? Where you're not ever getting umkiled by memory overloads and you don't need to over provision memory anymore. So that's number one is we use AI, it's integral to the product that we built. The second piece of our name has to do with providing infrastructure for the next, the AI generation, right? And so we've had a decade of data scientists building these AI models and they're ready to go into production. The rubber is gonna hit the road. And when they do that, they need SQL as the empowering relational engine to put that into practice. And we're right there with them to support that because otherwise if you put an AI workload on top of the current infrastructure where compute is trapped in database silos, you're gonna get costs that go through the roof. I mean, there was a study that I read recently from CSET that showed the biggest LLM model is gonna cost $25 trillion in compute by 2026. I don't know if that's still relevant or not. You know, but 25 trillion, right? So McKinsey came out with a study that said, you know, we're gonna benefit three to four trillion dollars per year in economic value as our global economy. Well, if you're spending 25 trillion and you're benefiting three to four trillion, that math doesn't end up. So something has to be done about the compute and the infrastructure to support AI ML and that's where we play. So to John's point, you're bringing the compute, not only bringing the compute to the data, you're bringing the compute along with the AI and the ML to the data. Well, you know, the fact that we're using AI ML within our product itself is a small piece of it. Secondary to, so there's a third piece, which is somebody else's AI ML. Somebody else's AI, look, you have, I was talking to a customer yesterday who said, we have these models that we've been building and they're proprietary to us and we need to be able to run them within our platform and they were using BigQuery from Google. Perfect example of generating and building these models and then putting them on our infrastructure and they had a serverless infrastructure and it just works. And so that's the type of example. People are going to have to figure out how do we put our AI ML into production? Yeah, and then apps are coming. What's your vision of how you see the application market developing because super computing, super compute, smart compute, AI compute, would you guys have the super cloud layer and then you got super applications having to have data native built in, natively managing the data and a lot of this ephemeral data will be in the app. He mentions Uber. We'll see more of those apps being coded. So a whole developer tsunami is coming as well. So we're seeing a Cambrian explosion of developers getting their hands on these open source. So yeah, rubber's hitting the road for the Gen 1 data sciences with their LLMs and foundation models. Now you're going to have coders coding on top of data natively. Yeah, I mean, I think there's two parts to your question. One, how are applications evolving and developing? I mean, I think they need to be developed with a semantic layer in mind. We're really moving towards more of a data-centric ecosystem where applications, they need to stop being so grabby and they need to share data with everybody and the architecture needs to change a little bit to reference that semantic layer. That also corresponds with AIML because what greater way to feed your production workload AIML than with the semantic layer that reaches into every piece of your business, right? So we're setting the stage. SuperCloud is setting the stage to not only be able to meet the demands of increasingly complex workloads from BI tools per se, but also to build the data center that's going to provide support for AIML. This is why SuperCloud is not just hybrid, non-prem to cloud and across cloud. It has to stretch out everywhere and that's why it is a metaphor for the future of what we call cloud. But the way we think about cloud as a remote set of services is changing. Joe, thank you so much for coming in for SuperCloud 3. So Cloud 4 is going to be all about AI which is right up your wheelhouse, compute and AI. I don't think that those two things are going away anytime soon. I'm glad you flew in. Yeah, thank you. Well, I appreciate you guys having me and hopefully next time Vikram can make an appearance. Yeah, be great. Compute.ai, I mean again, love the name, love the domain name. Those are two things that are going to be more and more abundant and important. And of course SuperCloud 4 is coming with all about AI. I'm John Furrier, Dave Vellante. We'll be right back with SuperCloud 3 with Matt Garmin from AWS's exclusive video where he shares the master plan for how they will be competing in generative AI. We'll be right back.