Alibaba Cloud Elasticsearch AI Engine Edition is a cloud-native search engine for retrieval-augmented generation (RAG), AI Coding, Agent memory, and multi-tenant search. It exposes a Collection as the unified access point and organizes business spaces such as knowledge bases, code repositories, Agents, and tenants as Slices within the Collection.
AI Engine Edition is available only to allowlisted users until August 30. Supported regions, zones, instance specifications, billing methods, and activation procedures are subject to the options currently available on the Alibaba Cloud official website, console, and official release announcements.
Why you need it
RAG, AI Coding, Agent memory, and multi-tenant search applications typically host many independent knowledge bases, code repositories, memory spaces, or tenant data spaces in a single search system. These workloads share three challenges:
Coexistence of many business spaces — Access patterns vary widely across spaces. Some spaces stay continuously active while others sit idle for long periods. Maintaining a separate index per space makes management and capacity planning increasingly complex as the number of spaces grows.
Uneven hot/cold distribution — Many rarely accessed spaces occupy compute and storage over long periods, while active spaces need stable, low-latency responses. Traditional architectures struggle to balance cost and performance across this distribution.
Divergent read/write peaks — Ingestion and queries each have their own peaks and valleys. When writes, index building, and queries share the same nodes, write surges directly impact query latency.
To address these characteristics, AI Engine Edition decouples persistent storage, write compute, and query compute. Index data and persistent state are stored uniformly in object storage. Index nodes handle writes and index building. Search nodes handle queries. You configure resources independently based on write volume and query volume. Active data is accelerated through local caching, while inactive data is loaded on demand.
On the console purchase page and in the instance list, the two node types are displayed as Index Nodes and Query Nodes, which correspond to Index nodes and Search nodes in this document.
Core capabilities and scenarios
Read/write splitting with independent scaling
Writes and queries use different node roles. Configure Index nodes based on ingestion volume, and configure Search nodes based on query concurrency. When one type of workload grows, adjust only the corresponding resources — writes, index merging, and queries no longer contend for the same compute. Write surges do not affect query latency, and query load does not slow ingestion.
On-demand caching with automatic hot/cold tiering
Complete index data is stored in object storage. The local disks of Search nodes serve as a query cache. Frequently accessed data is served continuously from the cache and returns hot queries in milliseconds, while infrequently accessed data is loaded from object storage only when needed. Local cache is sized around the active working set and does not need to match the total data volume. Inactive business spaces consume no compute or cache resources — their cost is limited to object storage pay-as-you-go fees.
Cache benefits depend on the hot/cold distribution of the workload, cache capacity, node specifications, and query concurrency. For workloads with highly dispersed or frequently changing access patterns, perform capacity assessment and performance tests with actual data.
Large-scale business spaces with unified management
An application can treat a knowledge base, code repository, Agent, or tenant as a Slice and read and write through the same Collection. The platform manages the underlying indexes and shards based on capacity. Applications do not need to create a separate index per business space or track underlying index names and table structures in application code.
When querying, you can select one Slice, multiple Slices, or explicitly select all Slices. By default, applications must specify the query scope, which reduces the risk of unintentionally scanning the entire Collection when routing information is missing.
Failure recovery without data migration
Index data, write-ahead logs, and cluster state are stored in object storage. Compute nodes hold no local persistent state. After a node failure, the platform schedules a replacement node that resumes operations from object storage and rebuilds the local cache on demand — no full data migration is required. Compared with the tens of minutes to hours of shard recovery in traditional stateful architectures, the blast radius of failures is significantly reduced.
If the write layer temporarily cannot host a primary shard, new writes are paused. As long as the corresponding Search shard remains available, the system can continue to serve queries against data that has already been persisted and published.
Elasticsearch ecosystem compatibility
Within the supported API scope, applications can continue to use the Elasticsearch REST API and Query DSL, combining full-text search, vector KNN, filtering, and aggregation. Official Python, Java, Go, and JavaScript clients, Kibana, and other ecosystem components can reuse the request structure and query syntax of compatible interfaces, reducing interface-layer changes. Before migration, verify the interfaces and ecosystem components you use against the API compatibility documentation for the target instance version.
Scenarios
| Scenario | Recommended data organization | Core value |
| Enterprise knowledge base and RAG | Treat each knowledge base as a Slice | A single Collection manages large numbers of knowledge bases. Active bases respond in milliseconds. Dormant bases incur only object storage fees. |
| AI Coding and code search | Treat each code repository or project as a Slice | Code becomes searchable within seconds after commit. Developer real-time searches are not affected by batch writes. |
| Agent memory | Partition by tenant, Agent, or independent memory space as Slices | Writes are immediately queryable. Dormant memories across large numbers of Agents consume no compute or cache resources. |
| Multi-tenant search services | Treat each tenant or business space as a Slice | The platform manages underlying indexes. Tenant data is physically clustered. Single-tenant query cost depends only on that tenant's data volume. |
Core concepts and architecture
The core architecture rests on three ideas: persistent state is stored in object storage, write and query resources scale independently, and multiple business spaces are organized through Collections and Slices.
Core concepts
To understand AI Engine Edition, distinguish Collection from Slice:
| Concept | Description |
| Collection | The unified entry point for applications to access data. Its usage is similar to an Elasticsearch index name. A Collection can contain multiple business spaces. |
| Slice | A logical data space within a Collection. For example, a knowledge base, code repository, Agent, or tenant can each be a Slice. |
When reading and writing data, applications use the Collection name to access data and specify the target business space through a Slice. The platform routes requests to the data that corresponds to the Slice and manages the underlying indexes and shards. Applications do not maintain or directly operate on underlying index names.
Slices organize data and scope queries. They are not equivalent to account permission boundaries. If you need identity authentication and permission isolation between tenants, design your solution by combining application-layer authentication with the security mechanisms supported by the product.
Core architecture
Query data enters the local cache on demand. The responsibilities of each component are as follows:
| Component | Primary responsibilities |
| Collection and Slice | Collection serves as the data access entry point. Slice identifies a business space within the Collection, and the platform uses it to route requests to the corresponding data. |
| Index nodes | Handle document writes, write-ahead log persistence, index building, and background merging. |
| Search nodes | Execute full-text, vector, filtering, and aggregation queries, and cache query-required data locally. |
| Object storage | Stores index data, write-ahead logs, and persistent state required for cluster operation. Data durability is 11 nines or higher. Billing is based on actual storage used, with no pre-provisioned capacity required. On the console instance details page, this capacity is displayed as OpenStore Storage and OpenStore Storage Usage. |
How data is written
Applications use the Collection name in the request path and identify the target business space through a Slice.
Index nodes process the request. The system confirms write completion to the client only after the write-ahead log (Translog) is synchronously persisted to object storage.
Index nodes generate index files in the background and publish a new index version (Commit). After Search nodes refresh, new data enters query results following Elasticsearch near-real-time semantics.
How data is queried
Applications use the Collection name in the request path and specify one or more business spaces through a Slice. Queries without a specified Slice are rejected by default to prevent unintentional full-scope queries. To query across the entire Collection, explicitly select all Slices at query time.
Search nodes first read query-required data from the local shared cache.
On a cache miss, Search nodes load the required data range from object storage. Subsequent queries continue to reuse hot data that has already entered the cache.
To maintain query availability during node failures, configure the number of replicas and Search nodes as described in the AI Engine Edition Usage Guide.
Disk-native vector index (DiskBBQ)
AI Engine Edition uses DiskBBQ, a disk-native vector index that achieves IO-predictable KNN queries through hierarchical K-means clustering combined with BBQ quantization. At query time, it probes at most two levels of centroids and reads hit clusters in block-sequential order, which makes it naturally suited for SSD caching and object storage without requiring vectors to reside in memory. Compared with HNSW, DiskBBQ improves index build speed by approximately one order of magnitude and degrades gracefully under memory constraints instead of experiencing a performance cliff.
Performance reference
The following results come from a test conducted in July 2026 under a typical application scenario. They demonstrate cold and hot query performance under those specific test conditions. They do not constitute a product SLA, an instance specification commitment, or general performance conclusions for other environments.
| Test item | Configuration |
| Test environment | Alibaba Cloud Elasticsearch AI Engine Edition, 2 Index nodes and 2 Search nodes, each with 16 vCPUs and 64 GiB of memory |
| Data scale | 10,000 business spaces, 93.68 million documents in total, 2.8 TB of data |
| Vector configuration | 512 dimensions, dot_product similarity, bbq_disk index (DiskBBQ) |
| Query method | KNN query, returning 10 results with a candidate set of 100 |
| Latency metric | Server-side processing time took; does not include client-side processing or network latency |
| Access state | Sample count | P50 (median) | P90 | P99 |
| Cold query | 180 | 225 ms | 377 ms | 605 ms |
| Hot query | 1,800 | 1 ms | 32 ms | 65 ms |
The preceding data was obtained with Index nodes and Search nodes of 16 vCPUs and 64 GiB. Node specifications, minimum node count, and dedicated master node configuration are subject to the options currently available on the purchase page. The performance in the preceding table cannot be reproduced with specifications lower than the test configuration — do not expect equivalent performance at the minimum specification. Actual query performance is also affected by the data volume of a single Slice, vector dimensions, recall parameters, node specifications, cache capacity, concurrent load, and network conditions. Before making a formal selection, perform capacity assessment and stress testing with your actual business data and queries.
Version and compatibility
AI Engine Edition uses version numbers in the 9.99.x format. 9.99 indicates that the product belongs to the Elasticsearch 9.x compatible series. The last version segment differentiates feature iterations of AI Engine Edition itself. This version number does not correspond one-to-one with specific Elasticsearch 9.x minor versions, nor does it imply support for every Elasticsearch 9.x feature and API.
Supported features and APIs may vary across 9.99.x versions. Before creating an instance or migrating workloads, consult the API compatibility documentation for the instance version displayed on the console to confirm support for data access, query scope, vector search, data replication, security capabilities, and other features.
The current AI Engine Edition 9.99.0 corresponds to Elasticsearch kernel version 9.5.0, so the version number returned by the cluster API differs from the version displayed on the console. Going forward, the actual Elasticsearch version is based on the cluster API response. When installing custom plugins, use the 9.99.0 version number that matches AI Engine Edition.
Regions and zones
The supported regions and zones are subject to the options currently available on the purchase page. Instance specifications, billing methods, and activation procedures are subject to the Alibaba Cloud official website, console, and official release announcements. Before formal migration, complete solution evaluation and performance verification based on API compatibility, data scale, hot/cold distribution, and target query load.
What's next
Follow these steps to start using AI Engine Edition instances:
Confirm region and version — On the Alibaba Cloud official website or console, confirm that the target region is open for purchase. Consult the API compatibility documentation for the instance version to confirm that the interfaces and ecosystem components you depend on are supported.
Plan data organization — Based on the Scenarios section, decide how to partition Slices — by knowledge base, code repository, Agent, or tenant — and plan the number and naming of Collections.
Create an instance and configure resources — Configure Index nodes based on expected write volume. Configure Search nodes based on query concurrency and the active working set. To maintain query availability during node failures, configure the number of replicas and Search nodes as described in the AI Engine Edition Usage Guide.
Integration and verification — Use the Elasticsearch REST API or an official client to perform write and query integration. Specify the query scope through Slices, and verify full-text search, vector KNN, filtering, and aggregation.
Capacity assessment and stress testing — Perform capacity assessment and stress testing with your actual business data and queries. Focus on cold and hot query latency and cache hit performance before proceeding with formal migration.
Future directions
Building on the object-storage-native architecture, the roadmap includes sub-second zero-copy branching (creating independent data branches for any Slice based on copy-on-write, suited for evaluation, canary releases, and rollbacks), compute-layer Scale to Zero (automatically scaling idle business spaces to near-zero to further align cost with active load), and deeper integration with Alibaba Cloud Elasticsearch ecosystem capabilities. Specific feature release timelines are subject to product announcements.