#368 AI Agents Are Now Your Database's Main User | Reynold Xin, Co-Founder at Databricks

Generative AI is transforming industries at an unprecedented pace, but as AI changes how you or your team work, one thing is clear. Your skills also need to evolve. At DataCamp, we offer everything you or your team need to adapt and thrive with AI. Whether it's business users looking to get the most out of chat GPT and co-pilot or developers and data scientists looking to find two models, you can learn the entire AI skill spectrum on DataCamp. Power your AI transformation today start learning at DataCamp.com. The future is already here is it's not evenly distributed. Agents have becoming the actual primary person, 99% of the value engineers this day is don't write co-manuality and don't provision the database manually. Now that AI agents for data analysis actually work, we've made a huge step closer to self-service analytics being possible. On top of this, having agents as direct users of databases means that we need to completely rethink how databases and data warehouses are built. Once you give it access, you can do anything and that's super scary. This day is I'm most just open genie and I ask him what's going on 99% of the time. He can tell me what is happening. Working at the forefront of both these issues is Reynolds Zinn, a co-founder at Databricks. Reynolds is driving Databricks's agent cloud push. His current projects include L-Tap, the Lake Transaction and Analytics platform designed to unify transactional and analytics data. He also works on the omni-gent Metaharness designed to give a common interface across the different types of agents. Let's find out about agentic analytics and the future of databases. Hi Reynolds, welcome to the show. Hey Richie, thanks for having. Yeah, great to have you here. I'm looking forward to the discussion. To begin with, I want to talk about self-service analytics because this has been something that's been promised for many years now. It's not quite become a reality, but it looks like it's getting closer. So why are we up to? Yeah, I think we're actually getting closer than we'll ever have and maybe already here, depending on how sort of so widely adopted some of the things are. I'm as a matter of fact, with like at Databricks right now, it's just not just me. Like me personally have completely changed the way I run analytics. It used to be the case that whenever I have a question, like for example, Hey, why did a product, so production metrics study spike up is spike down? I would ask somebody who record to me and they talked to somebody on the data team and then that person talks to somebody who report to them and then before you know it, it would be like two weeks past and then some answers come back. This day is I mostly just open genie and they ask hey what's going on and I would say like 95% maybe even like 99% of the time we can tell me what is happening. But I think in order to get through that point, there was a lot of groundwork. They were laid down, both symptoms of product development as well as from the adoption of building up the proper data model, the ontology and all that. And it's not just me that's been doing it. I think even the physical security team or sort of the real estate team of Databricks are doing the same thing. Like they are not technical people at all. So like I think to some extent the future is already here. It's just not evenly distributed. Yeah, absolutely. And you're making a point that like this cross team communication is so hard. So when you ask someone to do something that like I think it's one of the data team and then yeah, this is huge like between I've asked a question and I've got a response about data. So I love that's being things up. You mentioned genie there. So this is the Databricks data agent. Do you want to just give a bit more background context on what this is? Yeah, you so we did a recent branding to kind of consolidate a bunch of different things to kind of under the genie umbrella. But I think the easiest way to think about it is I'm genie is an agent that really helps you with a lot of enterprise work. And how it differs from I would say a lot of other agents out there are a lot of other agents last year recite. They kind of tried to memorize what exists. But genie actually computes. Because I think vast majority of enterprise questions are to age some decision making and it's actually somewhat quantitative in nature. It needs to be grounded on data. So genie is designed specifically to address that. We can do a lot of what general agent do also but that's where it really excels is asking questions like, hey, build me a revenue model that can forecast how my revenue will grow or hey, how are my sales going across the different geo distributions? Are there any special things I have to be paying attention to? And this kind of change how we work internally also have changed. I would say a lot of how our customers work. And think of it kind of as I think it's basically what what BI really should be. And instead of just going to dashboards asking team of armies building dashboards, genie is the way to actually assert business intelligence. Absolutely. I mean, certainly if you're building a revenue model, you really don't want the answer to be built in on your own company's numbers, not just fabricated like a lot of chatbots would do. Yeah, I love that. So tell me through what's the new work for them? Like, where do you want the AI to do things? Where do I want humans to do things? Like, what's the the best flow for analytics now? Yeah, I think there are many pieces that to get to as I was saying, there's actually a lot of like works of required today down the foundation and get to this point of cell analytics. And the I think humans are extremely critical aspect of that. So we're not advocating, hey, all the data engineers, data scientists, analysts, you're out of a job. As a matter of fact, we think they are essential in creating the foundation. And this foundation includes about a very important part of why genie can work as this thing called technology, the geneontology. So what he does is try to actually index every computation ever happened in the past. So for example, if your company cares a lot about revenue, like every company does, but revenue is a very difficult metric to actually compute. And it's certainly something you don't want to get wrong in. At the same time, there's probably cans of cells with different metrics, the different teams of different departments care about in a company. You don't want the manually, so create all of them. But largely, I would say anything that really matter, you've had a lot of historic workloads. You probably have a lot of SQL queries, a lot of dashboards that kind of reference revenue one way or another. So the genieont college, it kind of goes and indexes all of the past workloads. And then trying to define, hey, here's how you compute the different metrics. And here's what you mean by, for example, AR, because every company might define annual return revenue slightly differently. And it so that puts all that together and creates a graph. I mean, it also also allows humans to actually augment the graph. And by combining this sort of curation-based augmentation as auto discovery of what exists out there, we can actually really power the AI to do this best work. Because AI models now have very good reasoning capabilities. What they don't actually have is the context where everything. So genieontology provides a context to all the AI. And with the context, now, one, you can actually do it faster, because it doesn't have to just go, hey, let me cross something and then see if there's a definition here. Oh, this links now to somewhere else. Let me go cross the next thing. It's kind of like one of my co-founders Ali and CEO Databricks has this analogy of imagine you go back to 2000 and then the way search engines work is it opens one website first and searches the website to see if there's anything on there. And if there's something that matches the link, it opens the link next and goes to visit that link and just keep recurs. And then after two hours, it shows the 10 links on google.com search visa. That's kind of how in a way, say, there aren't how many agents work. The ontology breaks that kind of in a way give you these search index, the knowledge index, knowledge graph of your entire enterprise. So it substantially improve the velocity and substantially improve the accuracy, because you don't have to like go figure out what exactly is that revenue. So with all of this, I think humans has a very important part. One is data modeling, the AI agent, if you feed a junk, junk will come out. If you actually feed a really great data with ontology, you can get amazing results. The second one is there is this a little bit of a manual curation component. And we have found actually, many organizations are kind of religious about whether they should do any manual curation. Some are on the camp of absolutely no manual curation ever. Some are, hey, manual curation would be the most important thing to get us to the, so whatever, from 95% accuracy to 99% accuracy. We're not trying to force our customers one way or another. We kind of feel, hey, it's a very useful tool. You'll probably use it. You should use it, and internal a database we do. So obviously, humans have a very important part in that manual curation, maybe for tier 0, some metrics and assets. And the other thing is, I think once you have your data set, actually get to what we call a go layer. So ready for business metrics. All the system work pretty well. But there's a massive, typically massive amount of data engineering is required to go from your raw data, which might be collected from tens of thousands of different systems into the gold metric. And any of this middle layer could break any given point. We are actually working on many things to improve and self-remediate if, for example, pipeline could break. But in practice, I think you still need humans to actually babysit and think about, hey, what happens if something breaks? What's the implication of that? How do I actually fix it? How do I make it more reliable in the future? So we don't think humans would go away. We actually think humans who So more and more focus on the more important tasks and kind of be relieved from Hey, can you help me answer this question by writing a specific query or can you help me answer this question because I don't know where the data is I think the humor is to spend the time to build the ontology and infrastructure through the point that it becomes largely self-service for any business questions Well, I love that and yet certainly a very common business problem that Every single team's defined revenue or something that our AR are like slightly differently and you really don't want that to happen because you got to have that consistency Like across teams. So I love the pipe. You got this ontology layer underneath So I guess this is closely related to the idea of a semantic layer where you've got this canonical business definitions So the semantic layers are actually now part of on top, but it's part of ontology ontology actually builds on that It's one of the signals that the ontology post-run. Okay That's brilliant. And so it seems like a lot of the work now to be done is just creating that data foundation layer And then once you've got that the analytic spot is almost easy because at that point the I can take over a year guarantee that it sort of grounded in Good data. There has been a persistent sort of problem though with the gender behind that sometimes it makes mistakes Sometimes it hallucinates. Do you want to expand on like how you deal with that and like what do you do when it gets things wrong? Yeah, so the why I should talk a little bit about it right now, which is ontology, but the it is true The air makes mistakes about it so those humans right how many times do you just trust one the this person is going to come back with a right On several turned out on source wrong It that happens all the time to so I think it's not there see the case that hey I have to be completely perfect wearing humans like maybe sticks all the time But certainly I think if you just were to ask a coding age you just give the coding agent or a gender Agent so access to all of your maybe distinct by plumbing through API's there are too much contacts that it will confuse the agent a lot and Then it's start hallucinating fairly frequently The so what we have found we actually have a whole A.R. Researching whose focus is a non hey How do I conquer and build model square AGI there are far smarter than human beings the whole focus is on How do we actually create the system and the product that can give the best answers on kind of enterprise-like questions and we even created a Sort of a standard benchmark of office QA which is now used by many of the frontier models also they actually run e-dow Against that specific benchmark when they announce their new models and those are basically grounded on actual questions We see the enterprise work like knowledge workers would be asking so the ontology One is it finds all the contacts, but more importantly than having all the contacts is actually it finds the right contacts for any specific question and with the right contacts That are hopefully actually small you can actually substantially improve accuracy of the model and substantially reduce the possibility of hallucination Now nothing is perfect. Just like humans. I don't think whoever behave you have 100% So correctness rate, and it would never be wrong. So we're not saying you should be so ask a genius question and put it into your I made you quality failings and submit it to that cc But what our experience is for vast majority of the questions this days and you don't need to ask like another So a person the data team to help you ask it's it's largely self-analytic Okay, that's pretty cool. I love that you are sort of making analytics available to everyone that sort of makes a question I guess Traditionally, I mean data breaks it was originally targeted to machine learning scientists machine learning engineers and you've got broader Do you need like a different user interface or a different product for a technical data people versus Everyone else the way we think about this problem is that definitely you need a different interface For people that are not very technical Now that specific interface could actually be used by very technical people too But the more technical people often they have a different jobs to be done I for example there they they want to see code They want to be writing code whereas if you show like massive amount of code upfront to Maybe somebody who have never written a single line of code doesn't it never even heard of the word sequel There would be too daunting right so what we ended up doing is we actually created a whole new interface in Databrisc or genie 1 And when you open genie 1 There's nothing else all it does just hey here's like a box for you to type in it kind of like Google search Type in your question and then genie 1 will actually go help you generating a report or answer or do whatever you want to do And that interfaces use heavily by everybody including technical users and non-technical users But we also leverage the same underlying technology like genie on polygene office and we have a separate product called genie code And what that does is genie toe is the so the AI in the system in The traditional Databrisc interfaces for far more technical users and the understands for example Here's a notebook and here's like some Smith with code and that users trying to do for example build a linear model To predict some revenue and he understands hey here's like spark traces and there's a failure in The pipeline how do I remediate? So the kind of and give you far more technical detail. So we kind of built two different products Where the more simplified one is usable by everybody is more for a simple analytics and the Which is genie one and the genie code is the one is facing more technical users And so heavily integrated with existing pre-existing Databrisc interface. Okay, all right So this is like everyone can use a chatbot But then if you want more than you want to use you want to see them go to you you want the other interface and so You mentioned notebooks. I mean, this has been like the staple of of data people for a more than a decade now What do you think the future of notebooks is no books are gonna become even more important and you if you think about it Every chat interface like chatbot interface is kind of a notebook. They don't position. There's a notebook But it's really a notebook, right? It's still like a question is a Command you rely more or less and then it comes back with some results The results could be semi structure that weave in with charts and Tabular data structure is not very different from notebooks as a matter of fact We're seeing many same kind of feature requests that our customers were asking for On the notebook product from like 10 years back now they're asking for exactly the same set of features sets For the chatbot product Like for example, they want to be able to share a report or so the answer generated by the chatbot Makes sense and they want to be able to reorder Sometimes the questions again, that's like one of the big thing we added very early on on the notebook site And they want to be able to actually turn maybe a So the answer into a recurring thing So kind of turning into a production job Because this is something they want to see maybe every day or want to send it out to a mailing list every day That's something we actually added 10 years ago In our notebook product so we we think there's a lot of similarities now maybe it's not going to be the identical user interface because notebooks target That's like a more more technical persona like notebooks a little bit more co-heavy, but we think so the form of the notebook Is going to be very what's going to become even more popular and maybe we won't call it a notebook But it's effectively sort of a notebook farm I'm under the that's kind of hilarious that people wanted to turn like just chat conversations Into a notebook in some sense that there's something I've not really considered before but that yeah first nice and stuff I mean, it's kind of makes sense right if if you sort of in every enterprise works some sort of collaborative work notebooks are great for collaboration and notebooks great for interactivity as of looking at Inspecting results as you're writing code There's not very different ones the programming language becomes English Yeah, okay, that's cool. I guess copy and paste features from the notebook product to the channel Well, it's not quite asy, but yeah seem useful. Okay, so the other big sort of pain point with self-service analytics seems to be around permissions for things like in general Not everyone should have access to like the HR data things like that How do you deal with that data books like yeah, because that seems to be a blocker I think this is actually one of the most overlooked points when people think about AI Is they could hey if I just have access to all the data everything would be great But then often you don't want to give the AI access to all the data because you don't know exactly what's gonna happen Who's gonna be using it one of the thing kind of a very early decision we made in data breaks is there as there's only going to be a single governance later Which what we call unity catalog every permissions define the unique catalog layer So if for example, I've given Richie access to this, but not the other thing There's no way for you to actually circumvent that regardless of what interface you come in for And this is very different from I think a lot of the past bi-tools, which is hey because of extract process That bi-tools often do in order to speed up performance They carry separate permission model So you ends up being hey, maybe Richie should not have access in the actual underlying platform But then in this specific bi-tools suddenly now he can actually get in and then before you know it Somebody forget to actually update the permission policy and maybe that was intentional in the beginning But later something changed and it forget to update the permission policy. So and data breaks there's only one single layer for So governance, which is unity and in unity you set the policies and that is enforce everywhere joy i agents basically app on your behalf and that's a result. It can only see what you can see if you You can see the HR data, you can see, or maybe more likely you can maybe see the company employees or work chart, but you can't actually see, for example, in more sense, the PII stuff. That's a sense and salary information and all of that. Everything will be respected and you just can't get around it. Okay. That's the same sensible that you got all the permissions in one place and is kind of a separate and foundational tool that all the agents know of all the other kind of stuff built on top of. It's like making use of agents, the things you have to take the money, you have to like, I guess, test with different user permissions and all this kind of stuff. If you're building with this or if you're doing analysis on top of this, how do you go about making sure it works for all these different scenarios when you do have permissions or you don't? Well, the way we did it is actually the agentic layer always acts as data through the data foundation there. So the agentic layer never opens up on its own. You go through this in our ways as a result, the narrow ways, enforces everything. I think that's how security system needs to be built. By the way, in general, I think because agents are a pretty new concept, there's a lot of innovation happening. I think the industry has to hold, have overlooked how important governance is and how important security is. And I mean, especially on the personal side, right? If you look at OpenClaw and Hermit's agents, it's effectively, once you give it access, you can do anything. And this is super scary. And I think a lot of best practices, maybe enterprises have burned in the last 30, 40 years of building data systems. Our largely were relearning a lot of those in the industry. And like, having schema is a good concept because it can help you identify what columns are PII and enforce access control on those. Just having a single markdown file for everything is not a great idea. Nothing wrong with markdown files, but it's probably sure that you should ensure that you mount our files at the database. I think rest of industry will have to relearn a lot of this, unfortunately. But the way we've been doing it, we spent a lot of time basically building data governance in the last few years, and we just thought, hey, there's such a critical aspect of making agents actually work and deployable. So it would build it in the way that you just can't circumvent. There's no separate path to go in. You always go through a govern data foundation there. Okay. This seems absolutely essential for an enterprise to offer a business context. Since you mentioned OpenClaw and all these other AI personal assistance, do you think there is a way to solve security for these tools then, or they're just fundamentally like, okay, also, and you don't have to get security there. I think we will have to figure out a way. And I think a lot of it has to do with also introducing maybe different governance there. You cannot have the Asian itself, police itself, because it could actually, it could decide to do things. Like, it's very difficult to explain exactly what happens. Like, it's the same way we don't trust a single human being to enforce themself. 100%. There's always some sort of other car rails or access control. I think the same thing you have to have with agents. So in the way, basically, the governance layers can be in the agent layer. It needs to be below the agent layer or has to some other agent enforcing it. But one of the things that we actually announced was this thing called Omagen, which is actually Mattay's like, he's personally driving all of this. And what Omagen does is actually allows you, it's less about data access control, but allows you to declare policies or agentate governance. Like, for example, you're allowed to do this, but not the other thing. And it has a separate supervised agent that's trying to enforce and look at, hey, is this agent now going outside of a car rail that I've already set up? I think that's like one approach. And it's a little pretty promising so far, but we'll see so how I'm sure there will be more approaches that come up. But it just can't be the case that five years from now or three years from now, everybody just decides to give sort of their personal agent or enterprise agent permission to everything and their hope for the best. Yeah. So I agree with you. Something we have to solve eventually, but yeah, I suspect it may be like quite a while before we get to the point where we're like, yeah, we're really happy with all these things. And yeah, I mean, I guess the societal equipment you mentioned, like you shouldn't be policing yourself in real life. We have police forces to police the population and there's other groups to police the police and so forth. Okay. All right. The other thing I want to talk about is databases. And I know like about as long as I've been alive, page one of every textbook on databases is like, oh, there are two kinds of databases. You've got transactional databases and you've got analytical databases. These are different. I know you've been working to try and blur this boundary a bit. Talk me through what you've been doing here. Yeah. So it didn't. It's something last week. We talked about this thing called LTAM. Make transactional analytical processing and maybe take one step back. As you said, the last 40 years, effectively database, there are split into two different categories. There's transactional databases, which is hyper optimized for point low cups and point updates. For example, hey, Reynolds depositing some money into a bank, I need to find the role that talks about his balance and very quickly update that one role. And then the other size analytic databases, which are, hey, I want to reason on my data. I want to understand, for example, how, what's the behavior or if my aggregate customer base, how much are they buying across different stores, how much has they spending? And those require kind of scanning across large amount of data and running some analytical queries on those. And they, so if historically be an avoids two different databases, because the workloads are just so different, but what happens is usually you would start with, for any application, you would start with having OLTP, a transactional database. And this, for example, is like Postgres, MySQL, Oracle, and your build application. And when it becomes like successful enough, you want to start reason on that data and analyze that data. So you start moving the data from the transactional database into an analytical system. An analytical one could be like modern days would be like data breaks, snowflake, reship, BigQuery, back in the days could be percare data or do that process is like very, very painful because it relies on this thing called CDC, change data capture. It effectively takes little deltas out of the transactional database and ships the delta into the analytics side and then reconstructs the state of the transactional database. It's a very brittle thing and that the keynote I actually asked the audience, hey, how many of you really love receiving CPI blind? I think seldom thought I asked, how many of you, hey, you're a CDC pipeline? There's a few. But mostly, so people, nobody loves CDC pipelines. By the many data engineers who woke up at like 2 a.m. 3 a.m. because the CDC pipeline break. We even make this joke at Databricks internally that CDC change data capture does not stand for change data capture. It stands for continuous data corruption because of how brittle and how fragile it is. L-tap effectively, whether it's a play on the name, H-tap, I don't know if I should get into that here. But it effectively solves this problem by making sure every single table in your transactional database appears actually in the lake in the iceberg format. And once it appears in the lake in iceberg format, you can run all your analytics compute against that data. And the data will be up to date, it will be fresh. And as a result, you don't have to worry about, hey, do I have a pipeline to ship my data like all the data would just be automatically available. And that's the, I think, a very, very big innovation because now you don't have to worry about building CDC pipelines. And more importantly, you don't have to worry about pre-designing you need a pipeline. Because sometimes your business change, you don't actually know exactly what you need in the future. This just makes sure everything is always available for analytics. And the key there is, like, so why hadn't it just been done before? And one of the biggest reason is performance. The two systems just have such big different requirements and workloads that it's very, very difficult to engineer, kind of a shared storage system that work for both. Like, OLTP database is one of our oriented storage, because you need to update individual rows very quickly. Analytical ones, ones column their storage because scans a lot of columns at the same time. And we kind of figured out how to do it in the last year or so. And that's largely built on the general link-based architecture. So the link-based architecture enabled this innovation. But from a user's bisection, really a big thing is now you can run analytics on your OLTP data as if they're just native to the analytics system. And you don't have to have any pipelines connected. Okay. So this is really shortening the time from we've got new transactions coming into. We can now stop querying against those transactions. Yeah. Okay. And then you don't have to sort of figure out, oh, do I even need that? But you can just, at some point you realize you need it, you can just start running queries. You don't have to spend any time doing data engineering, designing how do you transport the data. Okay. So yeah, no data engineering work in order to set this up, it just magically happens. Do you want to talk us through some examples of when this might be really useful, if you are some examples of queries? I think one of those simplest one would be, hey, what if I want to understand what's my sales per store or so the more products are trending, the, the, you can now just start running. So analytics queries directly against that. data. You don't have to worry about anything. Like I think in historically, this is probably a many months, like multi-months project for most data engine kings, because they have to figure out how to actually get a CVC out, how to get it in and then set up a separate system. There's often still lags. All of this would just be like, it strengths that whole multi-months effort into now, just run a query. Okay, I looked at yeah, I mean, I guess anything trending, so I mean, you talk about like product trending, you've got like yeah, looking like social media data, looking at news data, I guess financial stock data, all this kind of, I guess we're getting into real-time analytics here. Do you want to talk us through? Is real-time analytics becoming more important than is that related to your database efforts? I think it's going to become more important. There's actually many, many things about it. The term real-time is a little bit confusing, like everybody kind of defines in their own way. But I think Roddy's speaking we're talking about how do we get to really fast analytical queries on very fresh data. So surfing L-Tab is a very big enabling factor here, which is now you can analyze your latest data without even setting up anything and all your eggs data. But the other effort we kind of announced that data on Isomet is this thing called Lake House RT, where RT stands for real-time. And what it does is if you think about L-Tab as the, hey, how do I make the OLKP or transactional data be available in media for analytics? Lake House RT is the analytical engine to now query all those data and more, all the Lake House data in shuper low latency. Historically, if you want to build, for example, a custom app that runs some analytics, for example, some dashboard of the fully tracing. And you want that it's because customer facing you want it to be super responsive on this. So if the freshness data, like for example, one, tens of milliseconds, query time, you kind of have to build a separate serving system in order to do that. Lake House RT is built on a new engine. And this engine, when this product is actually capable, answering many, many queries in tens of milliseconds. And you can actually answer a lot of them. I think the demo we show was we went 1000 dashboards on the screen, each of them loading about eight queries. And I just click start and basically simulates all the 10,000 dashboards loading all those queries immediately finishes in less than two seconds. For all this hitting the Lake House RT at the same time. So this is kind of a game changer because they enables for the first time, the Lake House is where moves and the prices have almost all their data enables a first time for them to actually serve those data in very, very low latency and very high throughput, throughput here, meaning crazy per second. And we think this is basically it reduces further data silos. You don't have to copy your data elsewhere into a separate serving system. Now you have separate governance, you have separate, so again, and not a data pipeline in my fail and cost latency. So increase. And so once you combine, I think L tap and Lake House RT, it really consolidates this. Hey, you just need a single copy of the data in the accounts. Whether it's your transactional data, or whether it's your, the observability data, this is just one copy and one copy together. And you have different systems that can actually handle different workloads, all sitting on top of this one copy. But often, more often, it's not a single person looking at thousands of dashboards. It's after a thousand different people, or at your 10,000, 100,000 different people opening different dashboards at the same time. All right. Yeah. So it's that we got sales service analytics, your whole company's looking at dashboards. So yeah, you can need to serve for them. And by the agents, I mean, we've done more than dashboards, more visually easier to understand. But honestly, what we're being seeing is agents are generating farmer, right, because of agents and our customers collected the are issuing far more queries. So this whole thing about concurrency and latency is because it's mattering even more. OK. Yeah. So it's nice to do some dashboards, example, curious. How do you see agents like hitting databases then like to change what you need in a database? And yeah, what's going on there? There's some things common across post like again, maybe I'll go back, even though I have a single copy of data, I think the workloads do look very different between transactional databases and analytical databases. I think for both, we're seeing far more activities, because agents are issuing more queries, it's not just token costs that's going up across the board. It's also what we are seeing is the infrastructure cost because of the consumption of the tokens generating more queries actually incurring higher infrastructure costs. So I think the future systems that would be building also just in the last couple of years is to help customers reduce that spend by having system that can scale better by having a system that can run faster on the same set of hardware. And this part of what the cows are T is. But the other aspect is, I think when it comes to transactional databases, agents have becoming the actual primary persona. And so it's, it's I would say vast majority of us like a multi-engineer probably like 99 percent of the value engineers this days don't write co-manuality and don't provision the database manually. They actually use some sort of agent to do it. And that reflects in the numbers we see in production. And agents one, because it used to be humans and the humans writing co and the cost of writing codes actually pretty high. But the cost of writing code have dramatically gone down. I mean, it's not going to go to zero because the tokens cost something. But have gone down dramatically. And this actually opened up a lot of the opportunity for experimentation innovation. But one of the big thing with infrastructure and databases in particular is that databases that view as it's like clunky, expensive, heavyweight thing. I mean, the term infrastructure reminds your PGE and utility companies, right? They're not nimble. And as a result, they in the past actually inhibit innovation because maybe you can write code very quickly, but if you can't actually provision the database very quickly, and you can run the database very cheaply, you might decide not to run the experiment at all. So we want to enable sort of experimentation that scale that are very, very low cost. For example, maybe if it's something that doesn't, if you don't know if something that's going to take off or not, you better not cost you a fortune. It should cost you maybe a dollar or two, in order to run the experiment, maybe even less. But once it takes off, you should not require to rearchitect everything, because you wouldn't have time to do that. We think infrastructure in general and databases in particular, if there is one of the most important piece of infrastructure needs to enable experiment, rapid experimentation at scale cheaply, but at the same time, for any of it, if any of the experiments actually takes off, and you should be able to scale to mission critical, on exactly the same set of infrastructure without having to do any rearchitecture. And so that what we're doing with the leg base, and there's many things that go into it and many benefits that come out of it. For example, you can provision a database in less than a second. And so now your ages don't have to wait. Everything is auto scale can scale down to zero automatically if there's no load. So if your experiment fails, you don't really pay anything. And because of all you can out the scale, if your experiment actually becomes successful, you can actually provision it to be much larger resource pool. So you don't you now can actually support, for example, millions of transactions per second. As a matter of fact, we even talked about we will support multi-cloud disaster recovery, which is probably the industry first managed multi-cloud disaster recovery. So you can really go to mission critical, even if the whole cloud was down. And that we think it's going to be incredibly important to enable that agentate so that development and innovation. OK, so yeah, from an infrastructure point of view, you got all these kind of scaling capabilities. You got the resilience. You mentioned the cost of things. I think that's a hot topic at the moment. I think a lot of CEOs have been giving the talk. There's changed from like, we must use AI as much as we can to actually this is quite expensive. Tommy, do you like how you think about cost control from the database side of things? Yeah, from a database side of things, it's one of the thing is we think so databases are sort of a fleet-wide problem. You should not think about database as a single instance of database. You should always think about databases as, hey, you have a collection of databases and fleets and how do you actually manage them. Each of them, we think all those scaling is going to be extremely important here. Because I think most databases in the past, or you probably even now, are done in a way that, hey, you provision one, you just, it's up and running 24/7. It never shifts that. And that's where a lot of the costs will come from. Because you have the provision for the peak, then more often than not, for some things not sure if it's successful, you provisioned it, but then you forget to shut it down. And before you know it, it racks up sort of hundreds of dollars to months and you have like a thousand of them. The all the scaling takes away that issue. Because if there's no traffic, it's not up, it doesn't cost you anything. And if there's actually spike in traffic, it all those scales to have more resources. So we can handle that load. Perfect. That's like a very critical part of it. The other thing is in a lot of the, for like the infrastructure spend, proof of the other by agents is largely because of experimentation and CI/CB cost. Lakebase also solved the problem with this branching. Basically, the lakebase has the same called branching. It's actually really, really unique to lakebase. What it does is it takes a complete clone of your database. Logical. So it doesn't actually really copy. It doesn't really clone the database. It just marks a, does a copy on right clone of the underlying storage layer. And it's basically have a pointer saying, hey, this is like the state of the database. And if you go updates, it would now start recording the updates. But with this copy on right branching, you could actually clone a production database or test database in less than a second without paying for extra storage. So this becomes a great way to run CI/CD by combining all the scaling and the branching. Because every time you create a new pour request to, for example, your application code, this is actually very common in our modern hour customers now. They will create a branch of their database. And they run the entire CI/CD on that pour request and that branch. And when CI/CD is done, it's just down. You all the scales down, so there's zero. They often de-least database. It incurs maybe like one stand of storage cost, because is that pour request tried to insert another row or two. And then it incurs very little compute because it just runs for a duration of that little CI/CD pipeline. And then it's gone. This is not something you could, but it has perfect isolation because it's the actual new postgres instance that's running just for this. So this is something that's like impossible to do outside of like base right now. Because if you actually want to do a clone of the database, you have to clone the data outside of the base. And as a result, it becomes very expensive. It takes a long time. But a cloning of your production database could take down a production database itself. Like that's like another horror story that happens all the time. So like base just solves all these problems and really makes it much easier to control the costs and have much lower TCO while enabling all of this possible experimentation relation. Does it really wild? I think the traditional way of doing things, you have like you have one production copy of all your data, you have one staging copy of your data. And that's kind of it. So the idea of like just setting up an ephemeral copy of like, hey, this is the variation on your dataset, which is now the database to exist until until the PR's merge and then get rid of it. That seems like a fundamental is a new way of working. The most important part is it's not an actual physical copy, right? Just appears a logical copy, a logical independent copy is isolated. So you can run all your experiments on it. It has no impact on rest of the other PR. So your production system. All right. So you're not just copying hundreds of gigabytes of data all of the places. Okay. Yeah. Yeah. That'd be a bit slow and a bit expensive. All right. So I'd also like to talk about sparks. This is of course where database started. Yeah. What's happening with spark these days? Yes. Sparks actually growing like crazy. I think there's many billions to download every month right now. Maybe three billion. So it's growing. It's a super healthy community. There's a lot of poor requests. So new releases come and we're actually increase the release velocity. And we also just recently added a couple of other major innovation features. One is spark decorative pipeline, which we think it's a better way to be building data pipelines. It's another API layer sitting on top of the data frame API that give you a more declarative data pipelines. There's also the real time mill in streaming, which for now for the first time, you can actually run again, real times very overloaded here, but you can actually run streaming jobs and stream processing on records in milliseconds. Those are some pretty major innovations that's been happening to spark. So in the last few months. Okay, so the decorative pipeline seems interesting because it's like you're not having to specify everything, like I guess at a lower level, it's like it's side what you want and then all the details get figured out for you. Okay, nice. It's nice that the community there's still pretty healthy. Just well on the subject. I mean, spark is probably a predictive AI and machine learning tool. It seems like journey to AI, a gentle AI, I've stolen a bit of the limelight here. So do you think there are still innovations going on in predictive AI? One, we have about it is true that everybody's talking about LMS and Jenny, right now. But what we have found with the actual production telemetry is because of the talk on Jenny, I and the attention on Jenny, I they actually far more classic machine learning, which assume what you meant by predictive AI is the more basic machine learning and the more deterministic, more statistical approach. The consumption and usage on those have actually taken off also quite a bit. I think the reason is now there's more budget in every enterprise on AI. And so at 20,000 feet level, there's no difference between what this classic machine learning was versus with Jenny AI. You all got lumped in together, it's like giant AI bucket. And no, there's a very good question, which is hey, but what does classic machine learning is is still needed? I actually think Jenny is great for a lot of use cases. But for many of the use cases, the classic machine learning we're designed to do in the past, classic machine learning is still the way to actually do them. Like for example, you want to go a predictive model on how revenue might tread in the future. It's actually fundamentally a statistical problem. Based on hey, what, how have you been doing? What's the seasonal variability? What's maybe the country variability? And are there any new products that I'm becoming in? How would that influence your future? All of those are classic machine learning features and signals. And I think basically classic methods, like linear methods, the decision trees, all of this, I think are more important than ever. And a big mistake would be, hey, everything is just Jenny AI, by the way, Jenny has a terrible math. Jenny AI can be really good at writing a program that used classic machine learning to solve a statistical problem. But Jenny itself is a terrible solution to statistical problems. So I really think of Jenny as the way to reason. But then often many of the solution is actually a classic machine learning approach. And by that's one of the things where she pushed on this product. The and part of Genie is now you can actually ask Genie to do a lot of the forecast, do a lot of explanation of what had happened, and all of this actually calling back into classic methods. And what we're trying to do is to alleviate the users from having to spend a lot of time thinking, hey, should I be using this decision tree here? Should I be using a logistic regression model here? And how do I do hyper-parameter? The tuning, many of those can be automated now with Genie. But out to me is actually running the classic like classic machine learning methods. Yeah, I'm right there with you. The machine learning is still incredibly important. But I do love that tip that if you just call AI, then I guess you see FO doesn't know the difference. And there's no fun anywhere. So yeah, good trip to let's keep in mind. Many, many AI systems are honestly sometimes just a bunch of if statements. Yeah, you could argue a complicated static if statements are not very different from a single layer and neural network. They are more different. Yeah, kind of the same. Nice. All right. So just finally, I always want more people to learn from. So who's working you most excited about right now? I think one of the thing, the, I mean, maybe very self-serving here, but Omnigen is actually, it's the latest thing I'm with he's doing. And I think we briefly talked about it in the, so when we talk about governance, but one of the things with Omnigen is that it's, it's sort of a meta harness. And he solves a very concrete problem, which is, hey, you have all this harnesses in AI right now, but they're all independent. They're all different. They all come with different UIs. There are all kinds of challenges. And but honestly, ultimately you want, you don't want to only use one harness. You want to use actually, you want different hundreds of collaborate, but there's the same thing as humans, right? You don't want to just replicate Renault 100 times and only work with this one person. And which thinks in a very specific way, you actually want different people coming from different backgrounds to collaborate to arrive the best solution. And I think that's not very different from AI. And Omnigen is kind of like a what we call, or what we take calls the meta harness that sits on top of a lot of little harnesses, which so you would be, you can use Omnigen to orchestrate clock code, use Omnigen to orchestrate Pi, you could use Omnigen to orchestrate code to X or open code, and actually have them work with each other. What we have found is actually for a lot of different tasks, you can actually get to better result by having the different coding harnesses collaborate with each other. And I think that's a very, so it's somewhat of a new idea. Omnigen is not even the only thing that's trying to do that. I think just in the last few months, there are few that's emerging now. Omnigen is probably having the largest traction. And I think this is going to be a new layer that's created in the whole AI landscape. And it would be exciting to see how that layer would evolve. And my guess is over time, more and more. or people will be programming against the meta harnesses, instead of directly against the harnesses. - Oh man, so we're going from like prompt engineering to context engineering to hardest engineering, now better hardest engineering. Okay. - And let me kind of give you some sort of step function change in terms of capabilities. - Nice, okay. That seems to be the next thing to watch out for then. Wonderful. Thank you so much for your time, Reynolds. - Yeah, so nice to hear you, Bridget. (upbeat music)