Karthik Ranganathan<\/a>, co-founder and co-CEO of Yugabyte<\/a>, tells The New Stack, \u201cThe dimension of scale is shifting. It\u2019s not just large databases; it\u2019s also a proliferation of databases.\u201d<\/p>\n \u201cThe dimension of scale is shifting. It\u2019s not just large databases; it\u2019s also a proliferation of databases.\u201d<\/p>\n YugabyteDB AMP<\/a> extends Yugabyte\u2019s reach to the smaller end of that spectrum, while maintaining the distributed architecture the company has traditionally built for large, mission-critical workloads. It uses serverless multitenancy and what Yugabyte calls Enhanced Colocation to pack hundreds of workloads onto shared infrastructure, while giving each agent an isolated PostgreSQL database.<\/p>\n The economics make sense for fleets of databases, including those that underpin AI agents. An experimental agent might hammer its database for a few minutes, and then the database might sit untouched for days or even be destroyed after the task was completed. YugabyteDB AMP scales to zero when that workload is idle and charges by CPU minute when it is running.<\/p>\n Yugabyte is also seeing another problem will appear alongside all those databases: the need for someone (or something) to manage them.<\/p>\n Four agents walk into a database<\/p>\n YugabyteDB AMP ships with four custom built-in agents: Architect, Voyager, Perf Advisor, and Nexus.<\/p>\n Yes, Yugabyte\u2019s answer to the infrastructure needed by AI agents is, in part, more AI agents.<\/p>\n YugabyteDB Architect handles database creation and provisioning. A company might have rules about where development and staging databases live, how much compute they receive, or whether a particular workload needs to span multiple regions. Architect retains that organizational context and applies it when an agent asks for infrastructure.<\/p>\n \u201cThere\u2019s a lot of context that we build up as humans that needs to get harnessed by this agent.\u201d<\/p>\n \u201cIt needs to have context about your organization, about your specific group, about the details of your application,\u201d Ranganathan says. \u201cThere\u2019s a lot of context that we build up as humans that needs to get harnessed by this agent.\u201d<\/p>\n YugabyteDB Voyager handles migration and modernization. It\u2019s designed to bring existing databases into the fold. Voyager works out sizing and scaling requirements, as well as any changes needed to move workloads from other databases onto PostgreSQL.<\/p>\n Then there\u2019s YugabyteDB Perf Advisor, which looks after databases once they are running. It can investigate an outage or performance problem, search information about the database and its environment, and attempt to determine the root cause. Yugabyte also wants it to catch problems earlier, including warning developers when a query is likely to cause trouble before it reaches production.<\/p>\n Finally, YugabyteDB Nexus handles the ecosystem around the database: connecting it to warehouses, data streams, key management systems, and other external infrastructure.<\/p>\n Ranganathan says those four agents are just the starting point: \u201cThese were the four that it ships with today, with the substrate to be able to do more.\u201d<\/p>\n The more interesting part is what sits between them. The agents share context about the organization and maintain a record of why they made particular decisions. If somebody later asks, as Ranganathan puts it, \u201cWhat the hell was that?\u201d Yugabyte wants you to be able to reconstruct what happened.<\/p>\n \u201cThis is what the person said. This is what your context said. This is what I inferred. This is what I ended up doing.\u201d<\/p>\n \u201cThis is what the person said. This is what your context said. This is what I inferred. This is what I ended up doing,\u201d he says, describing the decision traces Meko<\/a> maintains around agent actions for YugabyteDB AMP.<\/p>\n Giving agents the keys, with conditions<\/p>\n There is an obvious catch to letting AI agents provision, tune, and otherwise fiddle with databases: sometimes they do stupid things.<\/p>\n Ranganathan describes the autonomy YugabyteDB AMP gives its agents as a \u201cguarded amount of freedom,\u201d with the level of control depending on the environment.<\/p>\n A disposable development database might be configured so the agent can get on with the job without repeatedly asking permission. A production system holding financial information would be treated very differently.<\/p>\n \u201cThere would be a dry run mode. It\u2019ll tell you what it wants to do,\u201d he says. \u201cSo you can always say, \u2018Ask me permission before you do something, and ask me permission, especially if the operations fall in this category.\u2019\u201d<\/p>\n He doesn\u2019t pretend those controls make mistakes impossible. \u201cIt\u2019s how you configure and use the thing that matters.\u201d<\/p>\n What happens if the prototype actually works?<\/p>\n There is another problem YugabyteDB is trying to support: successful experiments.<\/p>\n Teams can start an AI project on a small serverless database because it\u2019s cheap and convenient. Auto-scaling down to fractional vCPUs keeps those early-stage deployments inexpensive, while database branching lets developers spin up isolated copies to test new ideas, agents, or features without affecting production.<\/p>\n If the application becomes heavily used or business-critical, however, the infrastructure it started with may no longer be enough. YugabyteDB AMP is designed so that developers don\u2019t have to switch databases at that point.<\/p>\n As the workload grows, YugabyteDB can move to YSQL, its distributed PostgreSQL layer, adding horizontal write scaling, multi-master replication and geo-distribution. Yugabyte says this doesn\u2019t require an application rewrite or a conventional database migration, and that the agent continues to connect in the same way.<\/p>\n It will also give companies some choice about where all this runs. YugabyteDB AMP can operate inside a customer\u2019s own cloud, connected back to YugabyteDB\u2019s control plane. Yugabyte calls the latter BYOC, or bring your own cloud. Future deployment options will include an unsharded PostgreSQL managed service.<\/p>\n The idea is that metering, management, and learnings can still flow through the control plane while the customer\u2019s data remains in its own environment. \u201cWe still want it to be secure enough and for customers to feel secure enough to run it wherever their data is,\u201d Ranganathan says.<\/p>\n How Yugabyte manages its own database sprawl\u00a0<\/p>\n YugabyteDB AMP is still in its early stages and isn\u2019t broadly available yet. Yugabyte is using it internally and has opened it up to a small number of selected partners, with wider availability expected soon.<\/p>\n The company is already running agents internally for coding, support, and go-to-market work. Its support agent is called Hagen, while Growth Vector handles go-to-market tasks. YugabyteDB AMP is also being used for development, and Ranganathan says Yugabyte is starting to move other internal databases onto it.<\/p>\n \u201cWe\u2019re trying to consolidate all our databases as well,\u201d he says. \u201cSame problem, right?\u201d<\/p>\n Whether most enterprises end up with enormous fleets of agents with enormous fleets of databases<\/a> remains an open question. The agent market is still moving quickly enough that today\u2019s indispensable architecture can become tomorrow\u2019s abandoned experiment.<\/p>\n Yugabyte doesn\u2019t need every agent to survive for YugabyteDB AMP\u2019s premise to make sense, though. Quite the opposite. Its bet is that companies will create lots of them; most will spend time doing nothing; some will disappear; and a small number will unexpectedly become important.<\/p>\n If that happens, the database problem becomes less about finding somewhere to put one enormous workload and more about keeping track of many little ones.<\/p>\n And if humans can\u2019t reasonably manage them all, Yugabyte already has four agents volunteering for the job.<\/p>\n
![](\"https:\/\/www.europesays.com\/ai\/wp-content\/uploads\/2026\/05\/1cf43e50-cropped-bc46c9c3-headshot-disrupt-600x600.png\"\/)
<\/p>\n