ACID-Compliant Distributed SQL Enters the Agentic AI Era
Virtually every application has a datastore, whether for user data, capturing events, or customer transactions and interactions. If it’s a cloud-based application, then one of the containers will probably be a database. Beyond developing and deploying your new application, your database must be ready for growth and potential outages.
Generative AI (GenAI) applications must go through the same application lifecycle while handling unstructured data and integrating with large language models (LLMs).
What happens if the application needs to grow? Buy a bigger server, more compute, more storage? This is what developers did as the cloud started out. These approaches may handle defined use cases after a startup’s initial launch, but rapid growth may cause infrastructure to fail unless it’s designed for seamless scaling and resilience from the very start.
Such scaling and resilience require distributed data nodes, mainly for replication or sharding.
Database sharding is the process of breaking up large database tables into smaller chunks called shards. A shard is a horizontal data partition that contains a subset of the total dataset. It is responsible for serving a portion of the overall workload. (Source: Yugabyte)
The most common sharding is horizontal; for example, if your customer base is growing rapidly, you could put all the customers with names A–M on one node, and all the ones starting with N–Z on another, then route queries to the nodes as needed. This might seem sensible initially, but it’s highly unlikely you will grow customers equally across the alphabet. So again, this doesn’t scale.
Enter distributed SQL. This presents the user with a single logical SQL database, then communicates queries across the nodes under the hood. While the user targets one system, the actual distribution of nodes can grow, replicate, have geographic representation, sit near the edge, and so on.
Distributed SQL keeps the ACID transactions: Atomic transactions either happen completely or don’t happen; consistency requires that transactions always obey the constraints defined by the database; a transaction appears to be isolated from any other until complete; and the state is stored durably after it is committed — not just in transitory memory. It intelligently routes any query through the best nodes.
(Source: Yugabyte)
The Yugabyte strategy is simple: If you know PostgreSQL, then you already know YugabyteDB. If you’re using a Postgres-compliant open source relational database, you don’t have to trust a completely different system.
But it might turn out that smart distributed query execution is YugabyteDB’s strongest suit in the AI revolution, because it means it’s already offering intelligent decision routing along with scalability, resilience and geodistribution within its product.
YugabyteDB recently launched support for advanced vector indexing, along with its own first agentic AI app, Performance Advisor for YugabyteDB Aeon. The vector indexing support augments the capabilities offered by the Postgres extension pgvector for creating modern GenAI applications.
To get an idea of what all of this means for developers, I talked to Karthik Ranganathan, founder and co-CEO at Yugabyte.
The More Intelligent the Tech, the More the Database Matters
One aspect of “vibe coding” — the hype term for prototyping — is that the common model of storage is still a single database. Will the global brain that is an LLM sucking the web use distributed SQL?
Ranganathan indicated the direction things might go: “Modern applications have multiple interwoven aspects of search, transactions, natural language processing (NLP) and media. I think agentic systems, with the introduction of Model Context Protocol (MCP) and A2A, will help connect and coordinate capabilities to deliver an end-to-end user experience. And the richer the desired user experience, the wider the database capability requirements.
“You still see Oracle and SQL Server and DB2 and Postgres as the transactional data core. It’s a huge market. You put all the NoSQLs together, of which the biggest is probably something like MongoDB, they’re still really, really small, then there could also be vector databases like Pinecone,” Ranganathan said.
“But the important thing is, when somebody is building a new application or a new user experience, do we need to create more database sprawl?”
This feeds into another idea: In GenAI app development, where people don’t start a minimum viable product (MVP) on Day 0, how do they ensure eventual scalability and resilience? And how does YugabyteDB fit in?
“Distributed systems are essential for resilient and scalable GenAI applications. Their interconnected nodes provide redundancy and distribute workloads, ensuring continuous operation and the ability to handle large traffic volumes. Because we’ve focused on production-grade for SQL relational applications, you get that resilience from Day 1,” Ranganathan explained.
Performance Advisor and Agentic AI
So, onto Performance Advisor. There is some natural compatibility with agentic AI, but also some confusion in my mind. Obviously, transactions need to be atomic, but AI queries can loop if the goals are not attained. How are stray prompts dealt with? Are the prompts used within Performance Advisor carefully curated?
Ranganathan pointed out that the transaction step was not YugabyteDBʼs sole focus. Performance Advisor “looks at a lot of other signals,” he said. “What is your commodity hardware, the cloud native hardware that you’re running on? What are the signals that they’re putting out in terms of data access, or availability, or CPU usage? We look at how many connections the application is establishing. We look at geodistribution patterns to see where the connections are coming from and where they’re connecting to.”
“When somebody is building a new application or a new user experience, do we need to create more database sprawl?”
— Karthik Ranganathan, Yugabyte founder and co-CEO
So it feels like what we used to call an expert system, I observed. He nodded. “And the reason why it becomes interesting from an agent point of view is that there is some knowledge in the cloud architectures, e.g., AWS, GCP, Kubernetes, etc., and the infrastructure layer, the VMs, the usage, the networking, all of that. And there’s some knowledge in regular relational databases, like how do you write your queries and tune them? So we’re putting all of these together to let developers who are building apps and the SREs troubleshooting issues in production, interact with it.”
I slipped in a more sensitive question: Is Yugabyte storing data to improve the knowledge of the Yugabyte Performance Advisor system for future training purposes?
Ranganathan stepped through this confidently. “We don’t collect personal data or identifiable data, and we obviously ask users for permission to take data, depending on where the agents are.” If the agents are running in their own cloud systems, then the process is a lot more efficient.
“We collect a lot of metrics and a lot of configurations. Absolutely. But what we need is the fingerprint. A user persona and various signals. We don’t need to know the name of your cluster or the rows in the query.” The Performance Advisor lists the identifiable root causes and gives each a probability score.
Finally, an ecosystem play question: Is YugabyteDB trying to become the de facto vector database for cloud native systems?
“If you look at tooling written for the AI market, there’s a natural food chain,” explained Ranganathan. At the top are the AI libraries. One step below are the specialized vector databases (like Pinecone). And third, there’s the class of general purpose databases, including pgvector adaptations, which are getting pretty good at doing vector stuff.
“With our latest release, we’re taking it from level three to level one. We keep the interface the same as pgvector, so everybody can use it. We also infuse it with cloud native properties of resilience, scale, automatic sharding, and all of that stuff. So you don’t have to worry about it, and you can just deal with it in the cloud, which is our purpose.”
YugabyteDB’s Open Source Roots Remain Strong
I was curious to know Ranganathan’s thoughts on the tech trend away from open source. For example, we’ve seen products move from Mozilla Public License to the more restrictive “source-available” Business Source License.
As it happened, he was on home territory with this question. “We started YugabyteDB in early 2016. And when we started it, potential investors told us open source was not a viable business model.
“It’s been debated forever because I think it’s hard to figure out the nuances of monetizing open source. We’re continuing and reaffirming our stance to stay open. In the database market, the revenue model is not simply the database. It’s in the database as a managed service.”
Meeting Users Where They Are
With Performance Advisor and the agentic AI track, YugabyteDB is simply aligning with where its users’ systems already are: dealing with terabytes of streaming data that all intelligent systems feed on. The right information still has to be stored resiliently, queried over, and acted on. As an open source system, YugabyteDB has a chance to establish itself in the heart of the boom.
