Keynote: What AI agents need from databases

So, this [clears throat] First some disclaimers. I've never written an agent in my life. This perspective is not from somebody who has written an agent and learned some lessons. No. This talk is from the perspective of somebody who's built databases, works on databases, and what agents what kind of pressure what kind of demands are agents putting on existing database architectures? And what are some of the solutions that are out there and what IDB has built. I would also like to add that IDB did not start out building AI uh some of the things I'm going to talk about. It did not start out building that kind of AI sort of uh friendly infrastructure so to speak. It was more of serendipity. So, Atlassian, that's they've got a booth out there. So, Atlassian several years ago they were running very large number of PG clusters to manage some internal system. And they posed a challenge to us that okay, if you can solve this one problem and uh consolidate our clusters because we can't create uh more than 50,000 or 100,000 tables in Postgres and we need to create millions of tables. So, we accepted that challenge and we solved that problem and now Atlassian is a happy customer. But this also helped us in handling use cases that came from more from the agentic world. We also have a unified OLTP OLAP uh thing called HTAP or that also wasn't written for agents per se. It was written because TiDB originally was a pure OLTP system. But some of our customers about 8-9 years ago were adding Spark and all kinds of other systems directly to it and doing these sort of things. So, initially TiDB had some spark thing and it was eventually consistent, but after we realized how important it was, it was fully integrated written from scratch and [clears throat] it became a strongly consistent eight-step system. And this also helps the whole AI agent story extremely it it fits very well with the AI story. For this [clears throat] talk I beg your pardon, I'm not feeling too good. So, this talk is more about how agents are what you've observed about how agents are being used. Some of this could be bread and butter stuff for people who write agents. And then some of it is how the architecture should change. I I won't cover all dimensions, I'll cover one or two dimensions just to keep the talk brief. And and also how and why we think that the existing way many people are doing things is sub-optimal. Okay. So, this was a study done by MIT last year and the success rate of agent systems is actually quite low. But, I am more of a half-full kind of guy. I actually am surprised that 12% is actually quite good. This is my take on it. That there are agents I don't know what the absolute number is. I haven't read the study in depth, but I'm actually quite impressed that there are 12% agents that have made it to production. So, most of these are running on the kind of what we call like a Franken stack, which I'll get to in a minute. So, this is not a very optimal way that people seem to be doing it because it's a memory and state problem. It is not a like a the computational problem as such. And I'll get to why that's the case. So, we need to rethink our We need a unified database that can do transactional analytics, semantic and full text search with strong consistency. And a point that most people miss and that we are slowly finding out, you need a scalable data dictionary. Agents have a habit of creating thousands of tables, dropping tables quickly. And you also need collect statistics on those tables for the optimizers to work for the joints. These are hard problems. When the number of tables and scale is small, these are things that people don't think about. But when you have millions of tables, collecting statistics for queries that don't take hours to run because they don't have the correct statistics is a huge problem. Another huge thing for us is for example, we have a customer like a famous customer of Manas. It's not only about scaling one database. You also need elasticity in your in the way you deploy these things. They They're running a They're running 2 million clusters on our service. These are not small numbers. These are huge numbers. So, I'll get to uh the rest of the talk. So, the FrankenStack is really a brittle multi-system where you cobble together one thing from one vendor and another thing from another vendor and then you glued them all together using Kafka or some other pipeline mechanism. So, what's the core thesis here? Traditional database design is optimized for a few large-scale centralized workloads. So, all of you must have, you know, we're all software guys. You have a committee of DBs, they decide on which index to create, what the table definition would look like, what the types should be. Changing the schema is a mini conference. With agents, that is not true anymore. You can constrain them and put guardrails, but the whole point of agents is that you need to let them be creative. So, this puts all kinds of strange demands on your system. It is not the way you manage databases in the past. The requirements and the pressure on the database is very different. They could have very bursty loads. They could be like, we have millions of independent database instances. These are real problems. These are not imaginary problems anymore. So, you want to shift in one particular case like from a single DB to handling millions of DBs. Get rid of the FrankenStack. And so, as I said, the challenge is that current system, you can take any system. There's nothing. They're all the same. The The cannot handle these bursty and high concurrency life cycle of agent specific schema. They just can't. It's a big deal. So, we want to move beyond vector search plugins to truly agent native architecture on a unified tech stack. And I'll explain and show you how TiDB solve that problem a little bit later. So, this is mostly how people are I think this is my observation and what I read from here and there. This is mostly how people use uh agent systems. So, rag is just one small part of it. And that's what you get to read about the most. It's mainly the probabilistic retrieval of data. It It's not about the more deterministic part of how agentic systems or people want them to work. For example, you want determinism if if an agent is moving my money around, the last thing I want is a rag application doing it. I want a more deterministic, audited, uh fully you know, legal way of and guarantee that there's no problem. So, agents have memory. So, this is a big problem. Not only memory, they also have all kinds of strange data that they need to store. Audio, images, all kinds of files. They can respond to events, they can respond to user uh input. You need safety around all this. So, what do the agents do? They observe, retrieve context, that's a database operation, query facts, database operation, events, probably some events streaming service. They reason about it, they interpret the data, choose whatever next step has to be taken, select the source with which to interact, then they act upon it, they call the tools, they update the state, they trigger some kind of workflow. And then comes one of the more important parts. Then you need to verify, is it all correct? So, one is very simple very verification, you know, you write something, you check yeah, it's all done. The other is more of a semantic, which is domain specific, those are the hard things. So, you check the outcome, is it correct? This is you need some kind of deterministic way of doing it, these are difficult problems. I'll skip over those cuz this is not an agent talk. And then it needs to remember. When it runs again, it shouldn't be like that guy in that movie Memento, who has to disremember everything every time there's some event. It has to remember things. It has to store its state somewhere. So, they don't simply query a database, they cycle through all these things, observation, decision, action, verification, and their memory, they need to carry the state forward. And this is where the database basically comes and it tries to help in solving a lot of these problems. So, there are four basic roles for the that the agents have. I mean, for the database. So, as I said, rag is a retrieval role. Production agents usually need all four of these. Rag is mainly for toy applications or you want to do logs or any kind of X search where you you want a rough answer and then you go and look up the rest. Rag Rag is very good for that. You want some ranking of the important things. Structured access is the hard one. Memory and coordination is this you know, you you you want to have workflows. How do you remember state? How do you have long running any agent like agents can have long running workflows. How you how do you keep that state? All that is should be managed in the database. So, why am I always stressing on databases? Thing is that as we are all we've used databases for a long time, all of us. The key thing is you need S acid properties of a database. You need strong consistency. Why is that important? So, let's say you have uh an external service like Pinecone to do your vector thing and you've got Postgres or MySQL for some data and you're using a file system for something else. The state in They're all let's say you've got some pipeline with some eventual consistency. Each anyone who looks at any of these different systems will have a different view of reality. As humans, we do have the judgment. It's not that eventual eventually consistent systems don't work. They're everywhere. But, they're dealt with by humans. Humans have judgment. They can make sense and repair things. An agent doesn't have that or at least the current ones don't and I don't for see that happening for at least my lifetime. So, the agents need stronger consistency. So, whether they're looking at a vector index or they're looking at some file that's stored somewhere or some whatever audio data or some state or whatever else they've got, they need a strong consistency across that. It makes their life makes the person writing the agent's life very easy. Currently, that is not how they're architected. So, this is usually what the high-level architecture looks like for most agent deployments. You have some user input, you have some events, you have an agent runtime, there's a plan, it chooses some tool, interprets some data, it does some retrieval, does some structured the hard part, takes some action, and then people usually put some guardrails around it because it can't do whatever the hell it feels. So, that they're usually domain specific. So, then it must have security is a big deal. The tenant tenant policy and what what is it allowed to do, not allowed to do. You have to put limits on it. Like any database administrator will put limits on anyone writing an app in any sort of organization. It has to be auditable. It has to have all these nice things. And they all have to be tracked. And they have to be tracked in a very strongly deterministic database-y kind of way. That's the core argument. And so, a database can have any of those things. Database, operational data, analytics, workflow state. So, in general in production, people will separate the read retrieval privileges from the action and write privileges. The action and write are the more dangerous ones. I won't go into it because it's about agents and things that are not important in this talk. So, what what do these agent workloads demand? They demand serverless elasticity. They should be able to handle bursty loads. They should be able to handle multiple like millions of instances. Agents can They could be a swarm of agents. You can take any that's larger than let's say 20,000 or 10,000 employees. And if everyone's given like full freedom to create agents, and everyone creates 100 agents, that's 100,000 agents running around on your database. So, they if you need to do any useful work with it, well, you need the infrastructure to handle it. So, for that, if this is where the TiDB kind of architecture comes in. If you have a de- you have disaggregated compute and storage, offer scale to zero, use HTTP-style connection models. I'll go to disaggregated compute storage. So, that's a bit like MySQL Aurora, uh Postgres Aurora, I think. So, your compute is separate, your storage is separate, so you you can have M compute and N storage, so you can scale them independently. If you have bursty connections, you can trivially start up stateless compute nodes, and it can handle 100,000, 200,000, 500,000 connections. And you want to scale your storage, you can the modern TiDB uses S3 as a back end. So, essentially, it's shared storage, so it can scale as as much as you want. I won't go into the details. You can ask me questions outside. I can answer any detailed question. So, enforcing determinism. LLMs are probabilistic. Databases will not solve that problem. They will not make it deterministic in that sense. But, the control plane, the database can help in making that part of your application deterministic. It can enforce strict state transitions and validation at asset boundaries. That is the key point. Because agents can mutate state and they can do it very fast. So, essentially, if an agent writes an app, it'll work as fast as a human writes an app. That's, you know, like a no-brainer. But, the agents can make changes on the fly. That is the key point. Your app is not a static thing when it So, some people let's say just let's take a naive example. Let's say I say I want to constrain my agent and say I use placeholders for my SQL query so that it the ranges are constrained. What if the agent puts the first key and last key in a billion table? It's a table scan. You know, it's you can't control these things. You need to have some limits that are built into some functionality in the database that can put guardrails or some rules or whatever it is to Databases don't do this at the moment because but these are challenges. Like I mean, it doesn't do that sort of stuff. It should. Or other databases should. So, unified each step and vector. So, this is the over thing that TiDB provides. So, you want strong consistency and you want everything in the the kitchen sink in one database. So, you don't have to have 50 processes running, coordinate all of them, have five different experts handling all your five different systems. So, essentially, this is the workflow. This is how people mostly write the loops around the whole agent thing. You load context, you do hybrid search, you do have some compute, and hopefully if you have an asset commit, it is more deterministic in the way that your workflow is externalized. So, this is what people are actually doing with all those previous workflows that I mentioned. If this is what we call the FrankenStack. So, you could have a separate vector DB, you could have a different graph DB, a different relational database, a document store, and they're all connected through some kind of Kafka type type of thing. They're all eventually consistent. And that leads to many failure modes. You could have Redis for sessions, Pinecone for vectors, Postgres, Snow Snowflake for whatever pattern matching. You get eventual consistency. It could be out of date by 10 minutes, 1 hour, 2 hours. So, it's it's a You could miss data. Your agent can't make sense of data that has like out of date from two different sources that it has to tap into. It could miss I mean, misdiagnosis basically means it could whatever task it's working on, it could it just gives you the wrong results. So, basically they act on an out of sync reality. You need it to be cohesive and consistent. Then there is a coordination overhead. So, let's say you in your application you say, "Okay, I'll add some I don't know, throw some timestamp around my work in the data flow." Now, you have to stitch it all together. It's not easy. It's in theory all this stuff works, in reality none of this works. Hey, what happened here? Okay. So, once you move all this complexity or at least into the control plane in the database. Essentially, SQL is your language that you talk to your database. And SQL already gives you all the tools to retrieve all these different types of indexes and different sources of data from within your database. It has an optimizer, consistent, gives you all the latest data. It's Consistency is basically the core point. Whereas in the FrankenStack, essentially, you're doing manual and imperative, you're doing all that stuff yourself on outdated data. That's the key point. You have to write write it all yourself. It's complex. The orchestration is very complex. And the stitching the results together, it's I mean, it's really difficult. All right. I think it works on small projects. I can't see how if somebody has some big project that's doing it like that, I would be glad to change my mind on this. Okay, this is my most important slide. So, this is the TiDB architecture. So, let's say you have an agent. And an agent does transactional OLTP, analytic, and semantic queries. Right? TiDB is a MySQL compatible database. It has like a single MySQL port that it listens to. You can throw in a semantic search, you can throw in an analytic, transactional, you can throw like basically OLTP. Transactional is OLTP. And so with analytics or semantic. So, you can throw any kind of query. The TiDB SQL layer, the optimizer, is aware of the different storages, the row storage and the column store, which are strongly consistent because it uses Raft to move data from the TiKV store to the column store. The OLAP and the vector live in TiFlash, which is the column store. So, when a query comes in, the optimizer parses it. It could even be a subquery of a larger query. It can do the hash index whatever point look up here. And it can do the aggregation or whatever the subquery is on TiFlash if that makes more sense to the cost-based optimizer. So, this system will handle most of what I talked about earlier. You don't need separate vector indexes running on another system, separate uh OLTP data. You It I'm aware of two projects that are also using TiKV and TiDB. One is called DB9, which works on top of TiKV. So, it's a Postgres compatible protocol, which has a file interface like Plan 9 if people are aware of the operating system Plan 9. That's how it works. And you can query it using Postgres syntax. It's built on top of TiKV. That's called DB9, and there's Mem9, which works on TiDB. So, it allows people to write agents using the Mem9 API for for storing state and other things, but that's different. So, this system will give you everything you need in one database. It can handle millions of tables. It can scale this horizontally to petabytes. TiFlash itself can be scaled separately. It uses an MPP engine for scaling across TiFlash. And it does what you want from with full asset guarantees. It's an architectural necessity. That's the assertion that trying to make here. It delivers in a single horizontally scalable at agent swarm concurrency like lots of agents rather than the bolted on vertically scaled core. So, state then becomes an SQL problem. Why? Cuz now you have to access your state through SQL. This is a much easier way of dealing with things. So, essentially it stops becoming a distributed systems problem. You're not talking to different sources. You're just talking to one source. You use standard SQL, write a query, all your data is gathered from wherever and it just works. That's what it means by it becomes an SQL problem. There's also an explosion of states. From one database per application, now you have thousands of ephemeral states per task if like We've seen thousands of states. So, these are all the interim states when some agent is doing some work. Basically our observation. So, as I mentioned earlier, this traditional databases are really designed by you know, like a select you. You have a few databases in in a company and you have an application talking to a database, but now that whole game turns on on its head. Agent workloads as I've mentioned like several times are bursty, parallel, and also they can explore. For that you need, I forgot to mention TiDB, you can also do branching. Let's say you have a production system. You you see some problem anomaly. You can branch it in seconds. And then get your agents to start running on the branch. And then once you've explored it on whatever your production anomaly was. Okay. The anomaly was it will you can throw it away after you found out. It can do all those things too for you too. And then agent can automatically branch it, work on it, figure out some what whatever it to figure out and then destroy it. >> I I was only curious um cuz I'm more from the enterprise background. >> Yeah. >> I don't see the agent swarm as a problem yet. So, what kind of use cases are you seeing for agent swarm? Is this more for e-commerce type of applications or >> No, this is No, we we we don't see it from enterprise users. We see it from SaaS companies that have that are providing services for agents. That's where this comes from. We have not seen it from any enterprise. >> What kind of SaaS you talking >> So, Manas Manas has some very large customers where which can launch thousands of agents. And so, it's like a like a tail. So, they are very large and then they have like many like 2 million clusters are more mostly small. It's this new thing that people have loops and agents and constantly hitting the system. That's where it comes from. But not enterprise. So, if you don't save state, essentially you need to go over your whole token cycle and get back to that state if you if you remember your prompts or your events or whatever it is. So, Cortex and media state decay. So, why state decay? So, you need We don't do this, but we have a project called Cortex that is working in that direction. It was presented, I think, like 2 3 months ago at ICD in Montreal. Your data also decays. For example, your vector index. You could have contradicting facts coming in. So, you need some kind of automatic maintenance of these things. So we don't support it at the moment but we are working towards it. We don't have it. That would be state decay. The database should be able to do it. It's not a big deal. If it's given some criteria to merge or merge some vectors or delete some vectors or age them out it's it's a trivial thing to do provided there's some predicate that can select it. It's not that difficult. And it can do it automatically. So most people use some kind of caching scheme if you don't use databases for retrieving state. If you don't do it it becomes an O(n^2) problem. And then as I said you know the the quality of the data can also go down. So if it's in the database it's essentially your entire state is there and it's consistent and you can read it and you can start from where you stopped or you can go one step back and start from there and branch out from there. You can do all these things. So then maintaining the state becomes a first class job for a database. So you need So when a database writes states you want it's like typical transaction. You go from doing some intermediate steps and then you write your final state. You don't want to keep any of those ephemeral data to keep your data compact. So you can get rid of that using like normal transactions. There's nothing special you have to do. You're guaranteed consistency. Deduplication. This is what I was talking about. A database should be able to do this quite easily. None of them do it but it's not that difficult once everything moves into the single database. The compaction is the part that Tirex is we're working on with Tirex. Yeah, supersede old data. I mean, these are all things that a database can quite easily do given some kind of predicate for selection selecting whatever some criteria for just going through your data and doing the mechanical work. These are huge benefits, especially if you have very large amount of these vector and matrix. So, you need database grade properties in order to write robust agents. That's basically it. So, one important point, so agents, what we found is they resist simple partitioning. So, the classic way of scaling anything in the like for the past 15 16 years or 20 years is the classic divide and conquer. You find some partition key, you shard your data horizontally, some user ID or something that is stable, and that's how you partition your data. With agents, it's actually a little bit difficult. What do you partition on? So, what most that this this is why many companies or at least I can speak for one, they have millions of clusters to do it. But there's no easy way to partition it. Like a there's no universal key. It's a you know, there may be some in some context you could come up with something, but there's you can't generalize this. So, you need a system where you don't need one of these partitioning keys to shard your data. It should automatically shard it. So, you can throw as much data as you want at it. The database should be able to shard the data automatically up to whatever petabytes or hundreds of terabytes. TiDB does that for you automatically. So, that is one huge strength of TiDB. You don't need any special keys to partition your data. You just throw data at it and it'll work. Elasticity. So, you want to leverage the cloud. A database should be able to absorb any amount of load that you throw at it. Not by default. You give it like in practice, people have to give us like a 24-hour notice usually and we can scale it up. Or we will have the it's easy for us to scale it. See, a database gives you that. So, you can throw whatever load you want at it and it'll work. The strong consistency without ETL. Gone over that. Authentication. So, the database now takes over the whole authentication business. People already have existing systems authenticating your regular users and whoever connects to the database. You want to leverage that. You don't want to have a connection authentication against like five systems that you connect to. It's one It's centralized in one place. And this is a huge deal in most companies. It's not a small thing. There's a whole multi-billion dollar businesses around IAM. You want full file system storage uh integration for storing all different kinds of data. There are all kinds of other security issues. If you're writing to raw file systems, workflow orchestration, the database can help you. You can store interim state in your your agent can store interim can store incremental states and figure out what to do with long-running uh workflows. So, this is why most databases are currently failing. Massive multi-tenancy issues. So, these are problems that are not solved yet. And um we've looked at them. We haven't got answers for all of them. We've got answers for at least one of them. Like for example, let me the schema duplication is an interesting one. Let's say your agents are creating tables that are quite similar. You have it it's creating 10,000 uh different like schemas or databases as they call them in MySQL. But, the table definitions are similar. So, your metadata your data dictionary becomes huge. And so, is there a way that you can decouple the identity of the table metadata from the metadata itself? Which means I only use the metadata for deserializing and serializing the rows. Otherwise, it could be called whatever. The identity is not attached to it. So, my metadata, if I have billions of tables or hundreds of millions of tables, my metadata still stays small. And becomes almost like a copy-on-write. So, if one of the other agents or what in one of the other schemas, somebody changes that table, then it depends on new entry and essentially it becomes a copy-on-write. Cuz now, it cannot be serialized and deserialized from the other tables. So, these are kind of things that you can do when you're dealing with these kind of unpredictable kind of loads. So, when you have very large number of tables, you want to solve This is a problem that we mostly solve. You simplify the schema by making it a simple MBCC over the metadata table. Rather than if you're familiar with Postgres or MySQL, having a catalog and data dictionary, then you have this data dictionary metadata logs. So, try creating 50,000 tables in PostgreSQL or MySQL and see how long it takes. It is mostly around the metadata logs. It is not the file creation actually. Like in MySQL a table space is one file that's already created. So, if it's a shared table space, creating a table physically is not a big deal. But the metadata is a big deal. If you're doing these bursty loads and you're creating lots of tables, dropping them constantly, it's a challenging problem at that kind of scale. So, we you need to rethink these kind of things for databases. These are our current problems. These are not future problems for us. And to a we've solved it to about 30 million tables. But our target is now like a billion tables. Can we do it? So, one way is like classic, you make it immutable so that it's versioned and append-only. Okay, so this is what I was talking about branching. So, you have a copy-on-write branching. So, you want to test some hypotheses, you want to test some production anomaly, just create a branch, work on it, do whatever you have to, and throw it away. The database gives this out of the box. The key takeaways. The workloads are changing. They're or at least they're changing for this particular aspect. There is the traditional and then there is this new thing that's come around. It's the third thing, I don't know. So, it must support bursty loads, it must support lots of tables, lots of instances, elasticity. Identity becomes a huge problem with agents. They can spawn other agents. Do they inherit that same identity or some sub identities? So, all that sort of stuff are real problems that are I have not seen any big good solution for those. The scalability is now redefined. Do you think that SQL should be the language of choice for everything? A unified database architecture, a single source of truth, strong consistency. These are things that people should take for granted writing an application like for any application but agents it becomes even more critical. Writing agents deterministically is in my eyes impossible. But at least mitigate some of the complexity. Get rid of many of the challenges that you will face if you didn't have any like strong consistency in particular. So, where is where are we and where are we So, intent engineering. So, these are it is shifting more from how to define the whole environment within which the agent has to be written to more orchestration and database architecture becoming the core surface in which it is more controlled, contained. That is essentially what that is meant to signify. And then again, autonomous agents and then the sub agents they can create untraceable state changes. You need different kinds of authentication models. I haven't seen anything but these are problems that we see. The And the biggest problem is proving the deterministic outcomes from non-deterministic long-running agent workflows. This is an open problem. Uh enterprise scale I've just put it there but it's an open problem. It's got nothing to do with enterprise. But there is good news. So, 40% of enterprises according to Gartner will embed task-specific AI agents by the end of 2026. so it's a growing industry. How effective and how much it grows, I don't know. But we see a lot of interest mainly from SAS uh users, also from like Kimi. Kimi's become very popular. Kimi runs on TiDB. Uh Deep Seek runs on TiDB. Uh who else? There are plenty of companies like this that run on TiDB. So we see a lot of these kind of things that I talked about from these kind of SAS AI uh agent type of companies. Any questions? Oh, thank you. Anyone? Yeah, please. >> Hello. Um do you also are you also considering making it like multi-modal? >> Who's speaking here? >> Here. Here. >> Okay. >> Yeah, I I'm just wondering you got like both columnar or level like way of accessing the data. I'm I'm just wondering do you see the future also as something like multi-modal as in different type of data, files, text, uh images, all these? >> Yes, that is >> part of it. >> So DB9 does all that out of the box. That's built on top We don't do it. DB9 does it on top of TiDB. It has a Postgres-like interface. TiDB at the moment doesn't do it. >> Okay. >> It only supports a standard MySQL interface. >> Okay. Thanks. Thank you. So uh since you mentioned that uh I think SAS is the primary you know customer for TiDB. >> They're not the primary customer. They are >> one of the main use cases, right? Yeah, so I I was just curious in from that regard whether you know TiDB has anything out of the box for multi-tenant fairness as well as like I think the other question I had was like you mentioned that you have some of these open source models running inside TiDB >> No, no, no, no, on top of TiDB. >> Can you maybe expand on that like what that means and like what is the benefit of doing that? >> Okay, there are two three questions there. So, the first one is Are there some ways of handling multi-tenancy? Yes, so TiDB has a thing called resource control. So with resource control what you works at the user level connection level and statement level. So, you essentially have a budget. So, when you're you're familiar with Amazon, they have some kind of resource unit. So, you can budget for so many resource units and so read will have let's say right will have one resource unit, read will have 64 CPU consumption will have based on whatever 10 you spend cycles or whatever it is. You'll have certain number of RUs. So, you can say this query should and then you have a bursty mode that if the system is free, you can just go for it. Rather than because you're stalled because you don't have resources. And so, TiDB has a fairly sophisticated infrastructure around it. So, you can say okay, I'm going to run my test load compute the total number of RUs used and then budget using that. It has fairly sophisticated multi-tenancy resource control. So, that's not an issue. The second part >> including with an auto scaler that can scale up compute based on demand. Is that something that's >> because the problem with auto scale you can it's semi like that. You can set a budget. But if if if you get a huge bill at the end of the month, you're not going to like the auto scaling too much. So, but if you have a budget yes, it can do do for you because that is the that is the more operational side of TiDB. So it essentially keeps a pool of hotspot nodes. And then if you budget it for X number of compute nodes and this is in our TiDB X so it uses S3. So that's a shared storage. So firing up a TiKV is essentially raft and memtable. Whereas firing up an SQL node for connection or whatever it is is just like instant. So yeah it has all the goodies like that. That's not the and that is why all these other models that you that's why they use it. They use TiDB X. Sorry, somebody else? >> Yeah, you talked about branching and I don't have much context on Manos. Um after the branching and exploration is done, is the app deployed onto the same database? >> Yeah yeah it's the same. Think of it like point in time recovery with a clone from there that is spun up. Uh it's like a think of it as copy on write. >> Got it. So in that case right, so how do we manage the resource constraints? For example you talked about >> instance that's created from that point and it's managed just like an independent instance that is just started up. >> I see the fork is on the storage side. >> Yes yes yes. >> Got it. Thanks.