The database layer is one of the most exciting areas in tech today. Yet, it is often overlooked. A number of companies are innovating in this space, including Cockroach Labs, MongoDB, Redis and TiDB. Notably, each of them builds on different database engines such as Postgres, SQL and MySQL while offering distinct managed services.

While Snowflake and Databricks appear to be placing their bets on Postgres, TiDB CTO Ed Huang believes it is MySQL that will ultimately become the default choice for powering AI agents. “I found that SQL is still the best bridge between the LLM, the data source, and the human being,” Huang said in an exclusive interview with AIM.

Huang explained that when an LLM attempts to access a database, it first generates a SQL query that can be reviewed by a human. According to him, this review step acts as a safeguard and allows people to verify the intent and structure of the query before it reaches the underlying data source.

Recently released protocols like Model Context Protocol (MCP) will be foundational in building effective AI agents, he said. While Google recently introduced its A2A (Agent-to-Agent) protocol, he argued that MCP has an edge due to its developer-friendly design and growing network effects. 

Huang revealed that thousands of MCP servers and clients are already communicating with each other, along with a growing ecosystem of tools like MCP search engines, which makes it a more viable and scalable standard.

Explaining the critical role of SQL in enabling trustworthy AI agents, Huang said, “MCP sends the SQL query to the underlying data source, which is TiDB, a SQL database. If the query is correct, I can guarantee that the result returned from the database will also be correct.”

TiDB, he explained, has already introduced several AI-focused capabilities, such as vector indexing and full-text search, all of which are now generally available through TiDB’s serverless cloud offering. To further support AI application developers, TiDB has also released a Python SDK, making it easier for developers to build AI-native applications.

Citing a case study, Huang said a decentralised finance (DeFi) analytics platform uses TiDB as the backend database for storing and managing data in its cloud version. He added that many such use cases are emerging where TiDB plays a central role in helping developers build AI agents and applications.

TiDB is Scalable

Huang pointed out that building a distributed database isn’t easy, especially when tackling Online Transaction Processing (OLTP) workloads, which require both performance and long-term stability. It takes years to mature the product enough for customers to trust it.

“TiDB spent nearly 10 years building that trust, not just with enterprise customers but also within the open-source community. He added that one of TiDB’s biggest competitive advantages is that it is battle-tested, widely adopted, and supported by a very open and active community,” he said.

TiDB is a cloud-native distributed SQL database that combines transactional performance with real-time analytical capabilities. It supports elastic scaling, simplifies operations, and handles both OLTP and online analytical processing (OLAP) workloads within a single system. This allows teams to run real-time analytics directly on transactional data without maintaining separate databases.

Citing AWS’s recent general availability launch of DSQL as an indicator, Huang said that the distributed database market is gaining traction. “Amazon found that distributed SQL, or distributed database, is a big market. So even though they have very successful products like Aurora and RDS, they still realised there’s a huge opportunity,” he said. 

Comparing TiDB with major cloud players, he said they have around 20 to 30 engineers, while TiDB has about 300 engineers focused on just one thing. “That’s also a big competitive edge compared to the cloud vendors,” he said.

Moreover, Huang explained that traditional concerns around large data volumes are no longer the biggest challenge in database scalability. Many technologies can already manage hundreds of terabytes. 

According to him, elasticity and metadata scalability are becoming increasingly important, especially for enterprise and SaaS companies. 

For example, companies want to scale out during peak usage and scale back to reduce costs.

“Can I scale out my system for my peak time? But after the peak time, can I shrink the cluster back to a smaller size, because I want to save the cost?”—this is the question many companies are grappling with as they seek more cost-efficient infrastructure. 

Huang added that others, particularly in the SaaS sector, may not have huge volumes of data but deal with millions of tables and schemas due to multi-tenancy. This creates pressure on managing metadata like schema versions, connections, and table counts. He said TiDB has been actively addressing these issues, which has led to growing adoption in the SaaS industry by companies like Atlassian and HubSpot.

Growing Customers 

Huang said that TiDB has major tech companies as its customers, including Databricks, Pinterest, and Flipkart. “Databricks is using TiDB to power their entire metadata system. Every time you run a Spark job on Databricks, the metadata is stored in TiDB, which is very mission-critical,” he said. 

“Compared to two years ago, we’re now seeing more customers using TiDB Cloud. More than 70% of our revenue comes from the cloud offering. That’s a big shift and a good sign,” he added. 

Regarding competitors like CockroachDB, Huang said he is a big fan of their technology, noting that both companies started in the same year. He added that despite overlapping markets, the direct competition between CockroachDB and TiDB is relatively low. 

Moving past market comparisons, he said that modern AI agents need access to diverse data types, knowledge graphs, documents, JSON, time-series, and vector data. If this data is scattered across separate systems, it becomes hard for an LLM to retrieve and reason over it.

“If your data is stored piece by piece in different sources, it becomes really hard for the LLM to access it in a useful way. Instead of putting the data in different sources, I’d rather put it all together.”

Instead of building another system, he said it’s better to add vector indexing to an existing database that already handles other data types. Huang prefers storing everything in one database with a unified interface like TiDB, rather than splitting it across specialised systems such as separate vector DBs, document DBs, and more.

The future of AI agents depends on databases that are easy to scale, work across data types, and support rapid development. TiDB is betting big on being that solution.

The post Why This CTO Thinks MySQL Will Power AI Agents appeared first on Analytics India Magazine.