Alibaba Cloud Redefines Database in the AI Era

Author | Chai Xuchen

Editor | Zhang Xiaoling

In the face of the current trend in the tech circle where "AI Native" is often mentioned, Li Feifei, Senior Vice President of Alibaba Cloud and head of the Database Product Division, appears quite calm, even actively cooling down this wave.

Wang Yuan, head of the Technical Architecture Department of Alibaba Cloud's database products, candidly told Wall Street Insights on January 20 that many vendors' slogans of "AI Native" are somewhat "Great Leap Forward." Instead of rushing to label themselves as "native," Alibaba Cloud's PolarDB has chosen a more pragmatic goal—first achieving "AI Ready."

To help everyone understand what "AI Ready" means, Li Feifei used an intuitive "4+1" formula.

Imagine that previous databases were like a neatly organized filing cabinet, only storing text and tables. However, data in the AI era is diverse, including images, videos, and logs. Therefore, the first step to being "AI Ready" is to transform the database into a "big lake," capable of storing tables as well as these chaotic data, which is called "Lakebase." Next, the database must learn to organize this vast and fragmented information clearly through unified metadata management, much like a librarian.

An even more interesting change is to enable the database to "grow a brain."

Li Feifei explained that while large models are smart, they only learn from past data. If you ask it, "How many people attended the PolarDB conference today?" it certainly won't be able to answer because it doesn't know what is happening at this moment. This is where the value of the database lies—it holds the latest "hot data." By directly running AI models in the database (model operatorization), large models can read the latest hot data in real-time, preventing AI from "hallucinating" and allowing it to answer current questions.

As for the "+1," it refers to keeping pace with rising hardware prices. Recently, memory prices have skyrocketed, and Alibaba Cloud has pooled hardware resources through technical means, similar to shared bicycles, allowing everyone to share expensive memory and computing power, thereby reducing costs.

Since we are currently only "ready," what kind of database qualifies as "AI Native"? Li Feifei provided a very sharp criterion, comparing it to an athlete's physical examination.

He said, it's like someone claiming to be a national-level athlete; just looking at their appearance is not enough; you have to measure their body fat percentage. If the body fat percentage is still above 20%, then there's no need to boast; only when it drops below 5% can one possess the physical quality of a world-class athlete.

Corresponding to databases, Li Feifei believes that a true "AI Native" must meet two hard indicators: first, at least half of your database users are not humans but AIAgents; second, half of the content output by the database is not traditional tabular data but Tokens (semantic units) that AI can understand. As long as these two standards are not met, calling oneself "AI Native" is mostly just storytelling Although Fei-Fei Li is very restrained in defining concepts, companies are moving quickly in practical applications.

Take Li Auto, a new force in car manufacturing, as an example. They do not treat PolarDB merely as a data storage warehouse; instead, they have transformed it into an intelligent processing center. Li Auto utilizes the one-stop capability of PolarDB to not only complete data cleaning and labeling but also to directly perform feature extraction and inference within the database.

This means that from the data generated by the vehicle to the final intelligent decision-making, data does not need to be moved around; the "chemical reaction" is completed within the database. This usage is the best example of what Fei-Fei Li refers to as "AI-ready."

In addition to technology, Wang Yuan also specifically mentioned an economic calculation. In the AI era, not only is computing power expensive, but even the memory for storing data is increasing in price, potentially multiplying several times in the future. At this time, the advantages of cloud databases become apparent.

If cloud technology is not used, companies buying their own servers will face rising costs. However, PolarDB, through "Serverless" technology, can achieve extreme elasticity—when there are no tasks, it may not even occupy computing nodes, and when tasks arrive, it can start in seconds. This "pay-as-you-go" model is key to helping companies save money during a hardware price increase cycle.

It can be said that the signal conveyed by Alibaba Cloud this time is very clear: on the road to the future, focus less on concepts and more on internal capabilities. After all, only when AI agents truly take over the read and write operations of databases can the so-called "AI-native era" be said to have truly arrived.

Below is the transcript of the conversation with Fei-Fei Li, Senior Vice President of Alibaba Cloud and Head of the Database Product Division, and Wang Yuan, Head of Product Management and Technical Architecture of the Database Product Division:

Q: How do you understand "AI-ready" from cloud-native databases?

Fei-Fei Li: From native to AI-ready, I share with Wang Yuan that I repeatedly emphasize this point, which I believe is "4+1"—four points plus one foundation. First, the storage layer is moving towards lakebase. The database originally focused on structured data storage, and the lake focuses on semantic shortcut and even answer shortcut data storage combined, which is the first lakebase. This is very important in the AI era because the types of data that can be processed have greatly diversified; I can do embedding, feature extraction, and multimodal retrieval. This is a necessary first step towards AI-ready, so it is lakebase.

Second is the unified management of source data. A characteristic of the AI era is that there are particularly many data sources, including logs, transaction-generated data, and even images, text, audio, and video. Each type of data is particularly large, and there are many sources of the same type of data, so the unified relationship of metadata becomes very important. Previously, metadata was hundreds of GB, 1TB, or 2TB; now metadata can be several TB, so the unified management of metadata has become a crucial lever, and metadata needs to be updated in real-time. We have integrated the ZeroETL technology we previously developed in the data plane into metadata management The data source has changed, and the matterdata information has changed. We can synchronize it in real-time to the metadata management layer. In summary, it is matterformetters (phonetic), the unified management of metadata. This is the second key capability.

The third key capability is multimodal retrieval and processing, moving from structured to semi-structured and unstructured integration, combined with embedding capabilities, vectors, full-text retrieval, and other multimodal aspects. This is the third.

The fourth point includes two sub-points: model operatorization + support from AgentAI, which are organically integrated. We need to provide model inference services in the database. More than a year ago, we proposed model operatorization, and many people did not understand why we were doing this. Now it seems very natural because models will consume all data; cold data and warm data will all be consumed by the model, making cold data less meaningful as it becomes part of the model parameters. Even warm data can be updated to the model in near real-time today through Lora fine-tuning technology.

Currently, the only data that cannot be consumed by the model in real-time is hot data. This is because models today do not have the capability for real-time CRUD (Create, Read, Update, Delete) operations. Hot data must be persistent and long-term, holding significant value. If the model lacks the support of hot data, it will generate illusions and fail to understand the facts.

Hot data and model online inference create a chemical reaction, which is why we are doing model operatorization in the database. The future will definitely be a token world, and in the coming year, tokens may increase by 100 times or even 1000 times globally. How will these tokens be consumed? For most enterprises and individuals, directly to token usage is unclear. It's like giving someone iron, copper, or gold without knowing how to use it, but if you give them a gold necklace or bracelet, they know how to use it. Therefore, tokens must be used in contextual scenarios, and the combination of model operatorization and hot data provides this value.

There is also a logic to contextualization: once model operatorization is achieved, hot data is converted into tokens in real-time. How can we use it contextually? Various agents must be developed for AgentAI, deploying agents, and running verticaAgent on the database, which is also a very important capability. This is the fourth direction: model operatorization + support from AgentAI. These are the four key elements for databases to become AI-ready: lakebase, unified metadata technology, multimodal retrieval and processing, and model operatorization with AgentAI support.

What does “+1” mean? It must keep pace with hardware development. All systems, databases, are just hardware that changes over time. When we were young, we had a 386 or 486 with 64K or 32K of memory. Today, with PolarDB, we have officially launched commercial services on the public cloud, capable of pooling over 100TB of memory, with CPU + GPU inference nodes accessing the same memory pool, and underlying storage pooling. Therefore, hardware optimization, including serialold memory pooling, PD separation, KV cache, and these hardware capabilities are essential KVcache must be combined with hardware; doing KVcache solely from the software level is meaningless. It must take into account hardware characteristics, such as the DRAM in GPU nodes, DRAM in CPU nodes, remote DRAM, and HBM. How to pool these resources, along with the SSD layer, is crucial.

Therefore, with the continuous iteration of hardware characteristics, memory strength is essential. As mentioned earlier, the key challenge during the early development of databases was memory strength, and today, this "ghost" of memory strength has returned. It was mentioned earlier that memory prices have increased by 30%-40% in the past few months, and we believe that memory prices may rise by another 2 to 3 times. This is tied to breakthroughs in hardware innovation, which is the "4+1," and AI is ready to do several things.

Question: You mentioned that the cost of using databases has further decreased. What optimizations have been made in architecture during the cost reduction process?

Wang Yuan: Regarding costs, the significant cost-effectiveness and advantages can be summarized in three points: first, resource pooling; second, multi-tenant sharing; and third, elastic scaling. First, from the cloud computing era to the AI era, one logic has not changed: only by scaling to a certain extent can there be a cost advantage or cost dividend, allowing these benefits to be passed on to users. Therefore, PolarDB first has the largest database user base in the cloud, which is our strong moat, allowing us to do this.

Second, multi-tenant sharing. From a technical perspective, we can analyze what has been done at the storage layer, memory layer, and computing power layer. At the storage layer, as Li Feifei mentioned, there are three tiers of data: cold, hot, and warm. If all data is hot data, costs will certainly remain high. For an enterprise or organization, most data has certain warm or cold attributes and can be retrieved when needed. At this point, PolarDB needs to enter more high-cost-performance storage media and classify data storage within the enterprise. However, classification storage should not shift the management burden to users; the database must perform intelligent cold and hot tiering, intelligent data scheduling, cross-border flow, and migration. This is the first thing PolarDB's storage layer does to reduce costs.

At the memory layer, as mentioned, CXL is a technology we strongly promote. CXL intuitively provides a super-large-scale remote memory pool, which allows for reusable and multi-tenant shared memory. In addition to accelerating high-consumption memory queries and analyses, it can also enable sharing between tenants. If we can improve memory utilization, it will also drive up CPU utilization, which can significantly reduce costs. Given the current trend of skyrocketing memory prices, there will be greater dividends in the future through this technological means, benefiting users.

Because PolarDB has chosen an integrated architecture, we will integrate TP, AP, and IP processing. This allows us to perform heterogeneous computing power mixed scheduling. We can mix GPU and CPU computing power, for example, within PolarDB, we can mix the Spark framework and Ray framework, allowing for comprehensive utilization of both CPU and GPU. Meanwhile, operations processed by the CPU, such as tagging and ETL operations, can determine how many GPUs to activate for the next embedding operation based on CPU throughput These aspects will not only improve efficiency but also bring considerable cost reduction operations.

In terms of product form, we have also made designs. Our main product, serverless, is an extremely flexible product form. In the future, we believe that Agents will be the main users of databases. A research report states that 80-90% of newly created databases may be autonomously created by Agents. Agents are running programs 24/7, and the workload they bring is completely different. It may involve high queries, high concurrency, or large queries, or it may not work for a period of time. At this time, the ability to be elastic can, in extreme cases, have zero computing nodes, only data storage without computing power. However, once computing power is available, corresponding computing nodes can be activated in seconds to handle tasks submitted by Agents or users. Through product form, we can also ensure that we have corresponding price advantages in market competition.

We ensure the price competitiveness of our products in the market through a series of technical means and product form design.

Li Feifei: With the rising storage costs, this is a cyclical issue. Looking back at history, storage prices rise for a period, manufacturers increase production, and prices come down. However, I personally believe this cycle is very long because it is a transformation of the era.

So in the short term, perhaps in three to five years, the prices of storage, whether DRAM or the entire HBM, will rise. I personally believe that the cloud-native technologies and product capabilities we have accumulated over the years will become increasingly valuable. Some customers previously built their own servers, thinking that servers are not worth much and the costs are low. That era is gone and will not return. If you do not implement memory pooling, storage pooling, serverless, or elastic scheduling, costs will continue to rise. This is my judgment about the future.

Question: What efforts has Alibaba made internally to integrate different product capabilities to build an AI-native database? Now that various database vendors are building intelligent database foundations, what differentiated experience does PolarDB bring to developers?

Li Feifei: All Alibaba Cloud products were initially integrated with Baolian over a year ago. At the political developer conference, we integrated models with Baolian, and there were some skeptical voices questioning why we were doing this. Looking back now, it is absolutely a journey that has successfully passed through many mountains, and it was definitely the right thing to do.

I can tell you that the token volume growth of PolarDB and the entire Yaochi database has increased more than 100 times in just a few months. Through the Yaochi database products, whether it is PolarDB Lingdong, RDS, ADB calling Baolian, or calling model operator services, or calling PAI, our token consumption has increased 100 times in just a few months, experiencing explosive growth.

What products have been integrated? Baolian, PAI, PAI provides customized model inference service capabilities and fine-tuning capabilities.

We have also developed model operator services ourselves, so we can provide model inference capabilities during SLA elastic bursts, which is model operatorization. Moreover, all of these can be accessed through SQL statements or APIs. The next key thing we will focus on is, of course, we already have this capability, but it is not perfect. In addition to SQL API and open SDK, we will support natural language in the future Natural language can seamlessly call all of these using large models, connecting everything from TP to HP and IP. This is our current situation.

This is directly related to AI, where the AI team is deeply integrated with the storage and computing teams; Alibaba's storage and computing are deeply integrated. In response to your earlier question, which products are connected in the AI direction?

Wang Yuan: During the earlier sharing, there was a viewpoint that in the future, database users will not only be the current developers but also more ordinary users. We believe that in the future, they will be direct users of the database because the capabilities of large models will likely enable our databases to directly serve ordinary users. Based on this assumption, what experiential enhancements have we made for developers, especially traditional data developers? Up to today, PolarDB has chosen the integrated path, and in the AI era, the integrated path has chosen the lakebase technology route. It has evolved from traditional cloud-native relational databases handling structured data to now fully supporting the processing capabilities of unstructured data, semi-structured data, and all multimodal data.

Specifically, regarding the capabilities provided to developers, the most fundamental is vector capabilities. Vector capabilities will definitely be provided to developers; in the AI era, vectors will be the most universal type of data representation. We believe that if a database does not support vectors, it cannot be considered a database of the AI era. However, vectors alone are not enough, as they are just one type of representation. For an enterprise or organization, multimodal data management is key, especially for some enterprises' experiences and knowledge.

For example, continuous construction data, graph data, and full-text data, a large number of business tags are full-text data. All of these need to provide integrated multimodal management capabilities. Furthermore, to enhance the experience for developers, we need the database and applications to get closer together. On this basis, we provide some integrated RAG capabilities. Additionally, we introduce model operators in the circle, allowing developers to conveniently integrate large model capabilities within the circle, whether the large model is deployed internally in the database or provided as a remote calling service in a MaaS manner, all of which can offer developers an integrated and transparent service approach. This is how we define the upgrade of experience capabilities aimed at developers.

For ordinary users, we believe that the greater growth potential lies here, or that databases need to be able to break out of their data circles and enter the AI circle, or get closer to AI, where the next step in experience becomes more critical. For example, natural language interaction and multimodal interaction are capabilities that PolarDB is already providing to users, and in the future, this may become mainstream. We believe that there will certainly be command-line interactions and tool-based interactions, existing between agents and databases through command-line and script interactions, while the interaction between users and databases will definitely be enhanced through natural language and more intuitive multimodal interaction methods.

Secondly, we hope that databases manage data in a way that is closer to human thinking. What does this specifically mean? In addition to managing data and managing schemas, we need to manage knowledge and memory, including how to organize my knowledge, my memory, working memory, factual memory, and experiential memory, and how to manage their flow. We hope that PolarDB can provide corresponding memory management or knowledge management capabilities Thirdly, support for the development and application of intelligent agents. In the future, we hope that PolarDB will serve as a data-centric AI infrastructure, and we have high expectations for PolarDB.

Q: In the AI-ready phase, from 2022 to 2025, over four years, you just shared four major capabilities, including model operators and multimodal processing capabilities. By early 2026, after acquiring these four capabilities, will we have truly completed the AI-ready phase?

Li Fei Fei: The capabilities discussed at today's developer conference are the AI-ready connected database. Some database vendors have already proclaimed AInative, but we prefer to be pragmatic and do not want to make such claims because the AI track itself is still rapidly evolving, changing every day. In China, we work for 14 hours while Americans start working during the day, and globally, it’s a relay race. Moreover, it’s not a complete relay; there’s overlap. We work for 14 hours, and they also work for 14 hours. While we are still awake, they are already up and working, and when we are getting ready to sleep, they continue working.

It is too early to call the AI track AInative because AI itself is undergoing rapid transformation. This is why we firmly advocate for AI-ready instead of AInative. I believe that calling it AInative now is a leap forward; whoever claims to have an AI native database is making a leap forward. Because AI itself is rapidly changing, we are at AI-ready. When will we know when it is AInative? And what will an AInative database look like? We can envision the future without any problem and have our judgments about it. I do not believe anyone has achieved what is called AInative at this moment; those claims are merely storytelling, while we talk about AI-ready as being real and achieved step by step.

Secondly, what will AInative look like in the future? In two sentences: (1) The future world will definitely be one where massive agents use databases. (2) The future world will definitely be token-dominant events. By these two standards, we can measure whether a database is AInative. For example, there are two key standards for measuring whether an athlete is a national-level athlete. I can also claim to be a national-level athlete, but you wouldn’t believe it. The key indicator is body fat percentage; if the body fat percentage is between 20-25%, claiming to be a national-level athlete is nonsense. It should be at least below 5% for a world-class athlete, or at least below 7%. Your basic athletic quality must meet certain standards.

A massive number of agents using the database is one standard, and the second is a massive number of tokens. If a database enters the AInative era, the measurement standard is how much of its capability is being used by agents; at least half of the database's capability should be used by agents. This is the first standard. The second is its output; today, the output of databases is often in tables, row by row. Its output, measured in bytes, is important because rows and tokens cannot be compared. It’s okay; we can cover it in bytes. If half of its output bytes are tokens, achieving these two standards means it is AInative, which we have not yet reached. Let’s take a closer look What needs to be done to achieve an AI native database?

Starting with the end in mind and working backward, to accomplish these two things, what do I need to do? This is a framework for logically thinking about problems. I want half of my strength to be as an Agent, emphasizing bytes, while the other half is tokens. What should my database do? It must continuously iterate and evolve in the direction I just mentioned, such as model operatorization, seamless integration of model invocation capabilities, Agents, and not just single Agents, but multi-Agent orchestration and invocation, marketAgent collaboration, and how to support this in the database, along with a super strong multi-tenant capability. The SaaS scenario is the prototype of multi-Agents, and in the future, multi-Agents will definitely be more SaaS than today's SaaS. Therefore, multi-tenant isolation will become a rigid requirement.

Then there’s multi-version iteration, seamless integration of AI inference, and rag knowledge bases. This is what we just discussed; rag refers to multi-modal retrieval, real-time knowledge updating embeddings, which are key characteristics of future AI native. There’s also seamless natural language querying, and not just querying, but natural language defining problems, going directly from questions to queries to actions.

Why do I mention actions? In e-commerce like Taobao, placing an order in the order system ultimately happens in the database, so the database is a natural place for actions to occur. Previously, actions were exchanged through APIs, but in the future, AI native will likely allow Agents to directly issue commands to the database. The database is where actions take place.

The Qianwen APP has connected all of Alibaba's ecosystems, but the essence remains unchanged. Through Qianwen, you can order milk tea or place orders on Taobao using natural language, find clothes like this, and it generates photos for you. You say you want clothes like this and place an order on Taobao; ultimately, the action occurs in the database. An AI native database must be the place where actions happen.

Question: Does the Alibaba ecosystem have the Qianwen large model and many native Agent applications? Recently, Qianwen APP was one of the earliest in China to enable cross-application calls within the Alibaba ecosystem. Has PolarDB explored any collaborative efforts with them, and are there any practical experiences?

Li Feifei: There are many. In the main forum share just now, we invited the Bai Lian PD to share; we are deeply collaborating.

Wang Yuan: In this era, data is fuel, and the database is the engine. We need to better power the large models, and the group is definitely a good testing ground for us. Recently, Qianwen has fully integrated with Alibaba, and within Alibaba Cloud, Bai Lian is not only the largest user but also one of the largest users within Alibaba Cloud. Our daily token consumption has increased several hundred times from the beginning of the year to now, which is our own consumption.

Has anyone paid attention to the database field? In the second half of the year, besides large models, there is another popular concept originating from an open-source project called Superbase. Its philosophy is backend as a service. The design concept is centered around the database, growing the backend services needed for enterprise applications on the database. Although this concept is very straightforward, those who can understand it are truly remarkable Question: In the future, there may be many cross-application calls for Agents. Should there be many trust protocols for Agents as well?

Wang Yuan: Yes, for multi-person collaboration, the MartinAgent system, and the atoa framework need to support this. Access between Agents definitely requires mutual integrity. Just now, after PolarDB integrated with backend service and moved towards supporting Astrategicapplication, including atoa and MCP, all of these need to be managed. I mentioned earlier that in the future, end users of databases may not use command lines, but I was referring to a longer-term future; in the short term, it is definitely still needed. In the long-term evolution, I personally believe that if Agents are the main force accessing databases, then MCP, atoa, and even various programs and scripts should be written, generated, and called by the Agents themselves, with humans simply posing questions to the database.

Question: Currently, Alibaba Cloud's PolarDB is still AIready and not AI native. Who is using it now? Some customers are concerned that so-called AI native may bring higher costs.

Li Feifei: Today, companies like Li Auto and Du Xiaoman are using it. Of course, not every customer has utilized the AIready product capabilities, but Li Auto definitely has. As I shared earlier, they have built a one-stop data platform, from data labeling and cleaning to embedding feature extraction, and then integrating with transaction data and hot data for online inference. They have utilized all these capabilities, essentially leveraging lackbase, multi-modal retrieval, model operatorization, and Baolian calls.

Additionally, we have a best practices book, and we will provide an electronic version code later. You can scan it. It covers the panoramic acceleration of enterprise large model applications with PolarDB AI, featuring about ten to twenty cases from leading enterprise clients across various industries. The first question cited Li Auto as an example, and regarding the best practices of PolarDB's AI capabilities, there are already a tremendous number of cases. This book summarizes them, and you can take a look. Please scan the QR code later.

AIready to AInative are all concepts. Today, we should not focus on conceptual support. The future world will definitely be an AInative world. When we will reach that world, I don't know, but it will definitely be accelerated. However, at this point, I don't believe we can claim to be AInative. Because AI itself is undergoing tremendous changes, how do we define what AInative means? This is the logic I mentioned earlier. But each of us is racing towards AInative, including PolarDB itself. This is the core logic I just discussed.

Question: If it is a traditional combination, such as using a search engine + traditional database or a combination of traditional database + vector database + in-memory database, what changes do I need to make when migrating to an Agentic architecture, and what benefits can I gain? Wang Yuan: Whether to completely rebuild AI-oriented data infrastructure is essentially a question. You ask me, no need. Everyone is embracing AI, especially enterprises, should adopt a smooth migration evolution approach, but the speed should be accelerated compared to the traditional era, rather than passively waiting for a smooth upgrade. The process of smooth upgrading must be accelerated.

If we completely overturn and rebuild, it cannot be said to be wrong, but it is somewhat too radical and risky. Therefore, PolarDB is designed based on this premise, how to support users in upgrading from traditional IDC or traditional architecture to cloud-native architecture, and further upgrading to an AI-ready data platform. In fact, PolarDB has a complete set of designs, specifically, we can talk about three points:

1. PolarDB itself is a cloud-native relational database, which is fundamental. Extending to the AI era, PolarDB is the entry point for our hot data, so PolarDB will always be compatible with PG and MySQL, and fully compatible with applications in these two ecosystems, allowing applications to migrate without modification. We will also provide integrated solutions for smooth migration. This is to ensure that customers do not experience interruptions in existing applications when upgrading their data infrastructure or AI infrastructure with PolarDB, making the transition smoother. Because we need to ensure that customer business operations run normally before upgrading capabilities, this is the most direct and acceptable approach. Therefore, the first step is that PolarDB must do well in being the entry point for hot data and must support all TP online business types while providing a complete smooth upgrade solution.

2. PolarDB itself is associated with a lakebase architecture. Once hot data comes in, it will successfully activate the warm and cold data within the enterprise. Therefore, PolarDB provides a smooth solution for warm and cold data to enter the lake. Currently, if using traditional architectures, such as ES, MySQL, or PG for online databases, these data are definitely fragmented. When a piece of data changes in business, the corresponding file in your object storage or file system cannot change. Therefore, PolarDB's lakebase architecture integrates and manages all cold and warm data, ensuring consistency and linkage between metadata.

This means that if I add a business tag or a modification record, the corresponding rodata in the file system or object storage system will correspondingly update. This can truly achieve real-time, consistent, and integrated updates of multimodal data. After ensuring data consistency, correctness, and real-time performance, this is the foundation for business innovation. This is the second layer, achieving the linkage of cold, hot, and warm three-layer data based on ensuring consistency, correctness, and real-time performance.

1. We will provide a series of supports that make it easy for customers to innovate, including the managed ray framework I mentioned, to process data for customers, faster hosting of the superbase framework, enabling them to develop enterprise-level applications more quickly, integrating with MaaS, defend, and coder. Whatever development method you can imagine, PolarDB can provide excellent support because there are enterprises that choose web coding, but there are also some enterprises that choose workflow methods to ensure smooth business processes However, in the workflow process, each node will introduce an Agent to ensure higher efficiency. Therefore, PolarDB, as a data platform, needs to support various AI transformation applications, and we will fully integrate with the ecosystem in this regard.

These are the three layers: the entry point for hot data, management and linkage of multimodal data, and support for AI ecosystem compatibility. These are the three key points of the transformation and upgrade plan we provide for PolarDB.

Q: In the past few years, we have seen the wave of AI coming, and the pricing for small and medium-sized enterprises has been continuously decreasing, especially in Alibaba's public cloud segment. On the other hand, we have seen hardware prices continuously rising. What changes have model operatorization and your concept of AI readiness brought to the past pricing curve? Additionally, what optimizations or improvements can be made to Alibaba Cloud's past revenue model or business model?

Li Feifei: As a cloud computing company, including AI platform companies, cloud computing and AI platform companies are essentially scaled businesses. From a business perspective, scale is key. The larger the scale, the more it can release the logic of decreasing scale costs. The lower the marginal cost, the more it can provide benefits to end customers, creating higher value.

In the past few years, we have continuously lowered prices for small and medium-sized customers, which is fundamentally achieved through two core points:

1. Technological innovation: We continuously improve pooling, multi-tenancy, and elasticity, which are more efficient than single-tenancy usage, thus releasing price benefits. This is the most core point.

2. Scale: The larger the scale, the easier it is to perform elastic scheduling. How can a small scale be adjusted? There’s not much to adjust. The larger the scale, the greater the maneuvering space, allowing for peak shaving and valley filling, and elastic scheduling, which releases scale effects.

The first and second points have a dual driving effect, allowing us to continuously release benefits so that most enterprise customers can enjoy these benefits. This is the logic behind the pricing curve.

Additionally, we are currently facing a new wave of cyclical price increases in memory storage, which will last quite a long time. Previously, storage prices had dropped to rock-bottom levels, and storage manufacturers were unwilling to produce. They have capacity but are limiting production, leading to price increases. Once prices rise, someone will inevitably jump in to produce because there is sufficient capacity, and prices will drop immediately. This round of logic is that the capacity is fundamentally insufficient; it’s not that they are deliberately hitting the brakes. The demand has exploded, and even running at full capacity cannot meet market demand. Therefore, this wave of storage price increases is expected to be quite long-term, and this is the underlying logic.

The rise in storage prices leads to price increases across the entire chain, including servers, intelligent computing, and GPUs, which are also likely to rise in price today. GPUs also include HBM and DRAM, which have the same underlying components. This wave of price increases is sustained over a long cycle, but from a historical perspective, it will eventually have cycles. When AI becomes a very mature industry, and the transformation is not happening as quickly as today, with changes occurring every day, it will return to a cyclical pattern. This is an objective law of food development, and the current wave of this cycle is expected to be relatively long. That is my judgment.

How can we help customers create value? In this era, cloud computing vendors and AI platform vendors can create greater value and customer value than if you purchase resources and manage them yourself. The higher the costs, the greater the value they can provide, because you have scale effects. Any individual customer finds it difficult to achieve such large-scale synergy effects as cloud computing and AI vendors, which leads to the logic of decreasing marginal costs The more the bomb cost rises, the more valuable the scale of platformization and the improvement in operational efficiency become