Agents Are "Redoing" Databases

11/06 2026 430

As the primary users of databases gradually expand from humans to agents, database architectures that have been used for decades are undergoing reconstruction.

Author | Doudou

Editor | Pi Ye

Produced by | Industry Home

"What is the company's total events budget?" To a finance professional familiar with the business, this may seem like an all-too-simple question. But in an enterprise-level agent scenario tested by a database vendor, the answer given by AI was off by nearly 15 times.

Faced with this simple natural-language instruction, the agent autonomously queried enterprise databases, mechanically summed the columns containing "amount" fields, and ultimately produced an absurd figure of 29.16 million yuan. Under the enterprise's actual financial standards, the real events budget was only 1.98 million yuan.

Obviously, the problem is that the agent fundamentally does not know which field the company's so-called "events budget" actually corresponds to.

This somewhat absurd blunder reveals a contradiction commonly found in current enterprise agent implementations: models are becoming increasingly smart, but enterprise data systems may not be ready for AI to work autonomously.

This has also prompted enterprises to re-examine their data infrastructure.

In February this year, Gartner pointed out in a study on enterprise AI data architecture that insufficient data preparation has become a major obstacle to AI applications, driving more than 75% of organizations to prioritize investment in AI-ready data capabilities. In other words, when enterprises find that upgrading large models alone cannot solve business problems, they begin to turn their attention to databases that were previously hidden in the background. Competition in AI implementation is extending from model capabilities to the data foundation.

This demand has further driven market growth. The China Academy of Information and Communications Technology's "Database Development Research Report (2026)" shows that the size of China's database market in 2025 was approximately 67.796 billion yuan and is expected to reach 97.974 billion yuan by 2028, with a compound annual growth rate of 13.06%. While the market continues to expand, the new demands brought by agents are also pushing database vendors to readjust their product directions.

Base software vendors with a keen market sense are also clearly accelerating their actions.

In January this year, Volcano Engine open-sourced OpenViking, a context database for agents, attempting to uniformly manage agents' memory, resources, and skill invocation; in March, Huawei released an AI data platform focused on knowledge retrieval and KV Cache acceleration; in May, Tencent Cloud introduced Branch capabilities to TDSQL-C and upgraded team-level Agent Memory; in June and August, OceanBase successively launched a lake-database integrated architecture and millisecond-level snapshot cloning (Fork) functionality; in October, MirrorEngine Technology released the MIP enterprise-level AI data platform.

In just a few months, from transactional databases and real-time analytics to lakehouse platforms, vendors with different technical paths have intensively launched new capabilities, and product boundaries have begun to blur.

One fact is that as the primary users of databases gradually expand from humans to agents, database architectures that have been used for decades are undergoing reconstruction.

I. Old Databases Cannot "Hold" New Agents

Why do database systems that have served enterprises for decades suddenly require large-scale transformation in the agent era?

In fact, over the past four decades, databases and surrounding data systems have mainly served "people," with clear divisions of labor. Traditional databases store structured data such as orders and transactions; network drives and data lakes store unstructured data such as contracts, recordings, images, and videos; search engines and vector databases are responsible for "finding things" by keywords or similarity.

In the past, employees searched and verified across several systems, and it did not matter if it took half a day to produce a report. Now, it has been replaced by agents that work 24 hours without stopping, can continuously query multiple systems within seconds, invoke model reasoning, and even directly execute operations.

At this point, the limitations of traditional database architectures begin to emerge.

First, AI can see data but cannot understand the business. The erroneous budget of 29.16 million yuan mentioned at the beginning is a typical example.

For databases, sales, gross margin, and events budgets can all be represented as fields and calculation formulas. But enterprise business rules are far more complex than fields. For example, when calculating sales, should refunds be deducted? When counting last month's orders, should it be based on order placement time or payment time?

In the past, people could fill in this information based on business experience. Now, if an agent does not know the rules, it may generate an SQL statement that is syntactically completely correct but completely wrong in business results.

In its "The State of Context Engineering" report released in 2026, Redis surveyed more than 1,000 IT and AI infrastructure leaders. The results showed that 97% of respondents believe context is crucial to AI, but 55% of organizations lack reliable business semantic models, 47% lack context relationship graphs associated with business entities, and only 4% of organizations have reached the highest context maturity stage defined in the report.

This means that the difficulties facing enterprise AI are no longer just understanding natural language, but also how to accurately understand enterprise business rules and obtain confirmed business context.

However, even if AI understands the data, it may not be able to obtain complete data in real time. Agents also face a second wall, namely that data is scattered across different systems.

Take smart car cockpits as an example. When the owner says "I'm a bit tired," for AI to give reasonable suggestions, it may need to simultaneously obtain voice instructions, in-car visual information, vehicle speed, and driving status. But these data often come from different systems with different update times, so AI may obtain information from different moments; repeated cross-system retrieval will also increase latency. For agents that require real-time interaction and even execute operations, a lag of a few seconds may affect judgment.

The same Redis report found that 54% of surveyed organizations believe isolated vector storage is affecting the actual effectiveness of agents, and 69% believe agents have difficulty reliably understanding cross-system data relationships. Another 21% of organizations admit that their systems often or usually use outdated, batch-synchronized data for critical decisions.

More troublesome is that cross-system queries also increase computing, network, and token overhead. A 2026 McKinsey survey shows that about 20% of respondents said AI operating costs have limited their use. How to reduce ineffective retrieval and avoid repeatedly inputting redundant data into models has also become a cost issue.

However, compared with being unable to understand and unable to query completely, what truly poses a greater impact on traditional database architectures is that agents not only check accounts, but also begin to create and modify accounts themselves.

In the past, enterprises ran a small number of large and relatively stable core business systems, and databases were maintained by professional teams. Now, agents can automatically create small applications such as bookkeeping and inventory, frequently establish test environments, modify data, verify results, and start over after failure.

Traditional database management models have thus become uneconomical. If a complete physical database is created for every application, storage and management costs would be unbearable; if a single table structure is shared, data isolation, permission control, and personalized computation would become complicated. Not to mention that letting tens of thousands of agents directly trial and error on production databases would also bring enormous security risks.

Obviously, the objects served by databases are expanding from a small number of stably running traditional applications to massive, dynamic, short-lifecycle AI applications.

At this point, the three major transformation directions for databases in the agent era are gradually becoming clear: first, "understanding the business, knowing the standards, and being traceable" to solve data understanding problems; second, "multimodal integration, real-time association, and one-time complete query" to solve data acquisition problems; third, "use immediately, build immediately, discard immediately" to solve the operation and management problems of dynamic applications.

Ultimately, for agents to truly enter the core business of enterprises, databases must help them cross three thresholds: calculate correctly, see completely, and act safely. This is precisely the main direction in which database vendors are currently reworking their products.

II. "Embedding" Context into Databases

Facing the new requirements raised by agents, database vendors are giving different answers.

First, in order to enable agents to "understand the business, know the standards, and be traceable," vendors have begun adding a layer of business semantic capability to databases.

In June this year, Tencent Cloud upgraded the WeData unified semantic layer to accumulate business terminology, metric standards, and rules; in October, MirrorEngine Technology released the MIP enterprise-level AI data platform, introducing the semantic layer into the execution chain of AI analysis; OceanBase provides semantic modeling capabilities through DataStudio and supports natural language analysis with DataPilot.

Behind these actions, they are actually doing the same thing: preparing an enterprise-specific "business dictionary" and "calculation manual" for agents.

For example, what sales means, how refunds are calculated, and which orders cannot be included in statistics are all defined in advance. After receiving a task, the agent no longer guesses based on field names, but queries and calculates according to business rules recognized by the enterprise, and makes the results traceable.

Knowing the rules alone is not enough; agents also need to remember historical experience. In January this year, Volcano Engine open-sourced the context database OpenViking to uniformly organize memory, resources, and skills; in March, Huawei released an AI data platform providing capabilities such as knowledge retrieval, KV Cache acceleration, memory extraction, and recall.

Although the two have different technical paths, their goal is to enable agents, when executing tasks, not only to find data, but also to obtain relevant knowledge, historical memory, and business context.

Having solved "understanding," the next step is "seeing completely." To this end, vendors have begun trying to break down the boundaries between these systems. For example, Volcano Engine VikingDB supports image-text multimodal retrieval and attribute filtering; OceanBase's lake-database integrated architecture and MirrorEngine's MirrorData attempt to connect the retrieval and association analysis of structured business data and unstructured content.

In simple terms, this means breaking down the walls between the three previous data rooms so that one data foundation can simultaneously handle different types of information such as transaction records, contract documents, and images.

Take e-commerce after-sales as an example. A buyer uploads a photo of a cracked phone screen to apply for a return. In the past, staff might need to separately query the image library, customer service records, and order system. Now, through multimodal retrieval and business data association, the system has the opportunity to find similar cracked-screen photos, filter related complaints, and then associate orders to find the carrier express and refund amount within the same query chain.

In this way, agents do not need to repeatedly move data between multiple systems, the query chain is shorter, and latency and additional overhead can also be reduced.

Finally, in order to enable agents to act safely, technology service providers have successively launched environments for safe trial and error. In May, Tencent Cloud introduced Branch for TDSQL-C; in June, Huawei Cloud's TaurusDB for PostgreSQL storage-compute separation edition released support for branch management; in August, OceanBase further added Fork capabilities.

In simple terms, an agent can quickly create an isolated data branch from the original database. It is like placing a "transparent draft paper" over the real ledger. The agent can modify and test on its own branch and directly discard it after failure without affecting the original data, and without having to fully copy a database every time. OceanBase disclosed that its related solution can reduce total cost of ownership by 30% to 50% in specific scenarios. This means that databases are beginning to be conditionally able to support large numbers of agents in creating, using, and releasing independent data environments on demand.

Looking back, it is not difficult to find that although vendors have different technical paths, their transformation directions are becoming increasingly consistent: through semantic layers and context management, enable agents to understand the business; through multimodal fusion, reduce cross-system retrieval; through database branching, enable agents to trial and error safely at low cost.

In the past, databases were mainly responsible for preserving facts, while how to understand facts, judge right and wrong, and take action was people's work; now, as agents begin to take over these tasks, databases also have to assume part of the responsibilities originally completed by people.

III. Database Engine Switch: Returning from AI to the Business Itself

From semantic layers and multimodal retrieval to database Fork, vendors are gradually filling in the capabilities required by agents.

However, when these technologies truly enter enterprises, some problems that are not obvious in product demonstrations begin to be exposed.

First is the technical debt enterprises already carry.

Over the past two years, in an effort to accelerate AI adoption, many enterprises have rushed to build vector databases, knowledge bases, data lakes, and various Agent platforms. Different departments have chosen different vendors, and problems have followed: duplicated deployments, inconsistent interfaces, and scattered permissions.

Salesforce's MuleSoft "2026 Connectivity Benchmark Report" shows that surveyed enterprises manage an average of 957 applications, yet only 27% are truly interconnected. Even among enterprises moving faster on Agent transformation, that figure rises only to 32%. More alarming still, 50% of AI Agents continue to operate in isolation.

This means that even if vendors such as Tencent, Huawei, Volcano Engine, OceanBase, and MirrorEngine Technology offer more unified data capabilities, enterprises cannot simply tear everything down and start over.

A more realistic path is to keep core systems in place and integrate gradually through unified queries, open interfaces, and incremental migration. That puts database vendors under pressure not only to compete on product capabilities but also to solve complex system compatibility and delivery challenges. Whoever can lower enterprises' transformation costs will stand the best chance of winning orders.

Yet even with systems connected, Agents may still fail to truly understand the business.

Databases can embed semantic layers, but the business experience enterprises have accumulated over decades does not automatically become standard rules. Consider a master technician at a manufacturing enterprise diagnosing equipment failure: the judgment may require combining temperature, vibration, equipment age, and maintenance experience. Some standards are written in operation manuals; others exist only in personal experience.

To give Agents similar judgment capabilities, this tacit knowledge must be sorted out—applicable conditions, exceptions, and the basis for each judgment clarified—and then transformed into executable, verifiable rules. What complicates matters further is that different departments may define the same metric differently, and rules must be continuously updated as the business changes.

This is no longer simple technical development but a knowledge engineering project requiring the joint participation of business experts, data engineers, and IT teams.

A 2026 iResearch report on Agent practices in central state-owned enterprises cited a Fortune Global 500 infrastructure central state-owned enterprise that had previously built systems such as a knowledge portal and knowledge map, accumulating nearly 10,000 high-quality engineering technical documents. Even so, when introducing Agents, it still had to reorganize knowledge organization, retrieval mechanisms, professional terminology, and security requirements—and ultimately chose to add AI capabilities on top of its original systems rather than tear them down and rebuild. That is the case for a single enterprise; if Agents are rolled out across dozens of departments and hundreds of business lines, the workload of rule maintenance, version management, and cross-department coordination will only grow.

IDC's research in September this year also pointed out that for Agents to enter core business processes, business experts, IT, and deployment teams need to be involved over the long term in data governance, knowledge building, and process restructuring—a considerable hidden labor investment.

This means that database vendors in the future will not only need to deliver software but may also need to participate in business knowledge governance. How to use standardized products to handle a large volume of non-standardized requirements will become a new challenge.

And when enterprises finally complete system transformation and clarify business rules, a third hurdle remains: how to manage tens of thousands of Agents running simultaneously.

In the past, databases mainly handled relatively predictable business requests. Today, large numbers of Agents may simultaneously initiate high-frequency queries, create test branches, modify data, and even call one another. Without constraints, this may not only cause computing power and costs to spiral out of control but may also trigger risks such as unauthorized access and mistaken data operations.

Especially in highly sensitive scenarios such as finance and healthcare, databases not only need to control access permissions but also need to support mechanisms such as resource quotas, operation auditing, and exception circuit breakers to ensure that every step an Agent takes is controllable and traceable.

Looking back, the challenges that Agents bring to databases have already gone beyond the scope of traditional technical upgrades.

Transforming existing systems tests architectural compatibility and engineering delivery; business knowledge governance tests the combination of product capabilities and industry experience; and multi-Agent operation tests permission management, resource scheduling, and continuous operations capabilities.

Therefore, the next round of competition in the database industry is not only about who can launch multi-model tables, semantic layers, or millisecond-level Fork first, but also about who can bring these technologies into enterprises' core businesses at lower cost and in a more controllable way.

And this is also changing the future product forms, competitive boundaries, and commercial value of the database industry.

IV. Who will define the next-generation database?

When databases begin to assume responsibilities such as business understanding, context management, and Agent operation assurance, a deeper change is taking place: the original product boundaries and value division of labor in the database industry are being redrawn.

This change is already reflected in the product forms of databases.

In the past, transactional databases, analytical data warehouses, data lakes, vector databases, full-text search engines, and even BI platforms each had their own roles. Today, as Agents place higher demands on data understanding, real-time analysis, and autonomous execution, these originally independent capabilities are accelerating toward convergence.

In the future, databases may gradually form a three-layer architecture consisting of "a unified lake-warehouse multi-model engine at the bottom, semantic and context management in the middle, and an Agent operation and evaluation environment at the top." The boundary between traditional databases and AI data platforms will also become increasingly blurred.

And more noteworthy than product convergence is the change in the database's own role.

In the past, databases were mainly responsible for storing and querying data, while how to understand the business and judge right from wrong depended more on people. Today, databases are beginning to manage enterprises' business rules, metric definitions, historical experience, and operational processes, providing Agents with a reliable basis for decision-making.

In other words, databases are moving from being a "warehouse" for passive data storage and retrieval toward a "business brain" (Context Engine) capable of organizing and managing enterprise context. Whether an Agent can truly understand an enterprise depends to a large extent on whether the underlying data system can provide accurate and complete business context.

This role change is also driving innovation in database operating models. As multi-Agent collaboration and autonomous trial and error become the norm, traditional monolithic large databases struggle to meet massive and dynamic application demands. Through millisecond-level Fork, on-demand resource allocation, and automatic release during idle periods, lightweight and elastic database services are expected to become a new direction of development.

So what does this change mean for the industrialization of AI?

From today's perspective, databases help enterprises save the trouble of cross-database operations and Token waste through multi-model integration, lock down the traceability of business definitions through the semantic layer, and cut trial-and-error costs by 30% to 50% through second-level sandboxes. This is equivalent to laying safe tracks and traffic lights for fast-moving AI, enabling Agents to truly venture into core production systems such as bank risk control, healthcare, automotive cockpits, and large-scale retail business analysis.

In addition, it is reconstructing the delivery chain and business ecosystem of ToB software.

In the past, when enterprises built an AI application, they needed to find integrators themselves to piece together databases, network drives, vector databases, knowledge bases, BI reports, and agent frameworks bit by bit, making the chain extremely long and fragile. Today, database vendors are moving upward and directly turning the cumbersome "system integration engineering" into out-of-the-box "standard foundational capabilities."

More importantly, it also gives Chinese database vendors new opportunities in this industrial competition that has not yet taken final shape.

Looking back at the mobile internet era, massive transaction and high-concurrency scenarios such as "Double 11" drove the development of China's distributed databases. Today, Agents place new demands on real-time processing, multimodal integration, and high-concurrency operation, and also provide new opportunities for the technical capabilities accumulated by Chinese vendors.

Unlike some overseas vendors that extend from data lakes and analytics platforms toward real-time transactions, Chinese vendors such as OceanBase, Tencent Cloud, and Volcano Engine, relying on long-term accumulation in large-scale transactions, real-time analytics, and internet business scenarios, are expanding toward AI-native data foundations.

Different technical routes are moving toward the same direction, which also shows that the competitive landscape of global AI data infrastructure has not yet taken final shape. In this process, Chinese vendors also have the opportunity to rely on technical accumulation in real business scenarios to participate in defining the next generation of AI data infrastructure, rather than remaining merely "followers" of standards already set in Silicon Valley.

Solemnly declare: the copyright of this article belongs to the original author. The reprinted article is only for the purpose of spreading more information. If the author's information is marked incorrectly, please contact us immediately to modify or delete it. Thank you.