Alibaba Cloud Elasticsearch Agent Engine Edition is a cloud-native search engine for retrieval-augmented generation (RAG), AI Coding, Agent memory, and multi-tenant search scenarios. It exposes a Collection as the unified access point and organizes different business spaces, such as knowledge bases, code repositories, Agents, and tenants, as Slices.
Why you need it: challenges of multi-business-space search
RAG, AI Coding, Agent memory, and multi-tenant search applications typically need to host many independent knowledge bases, code repositories, memory spaces, or tenant data spaces in a single search system. These workloads share the following challenges:
Coexistence of many business spaces — Access patterns differ significantly across business spaces. Some stay continuously active, while others remain rarely accessed for long periods. Maintaining a separate index for each space makes management and capacity planning increasingly complex as your business grows.
Uneven hot/cold distribution — Large numbers of rarely accessed spaces occupy compute and storage resources over long periods, while active spaces need stable, low-latency responses. Traditional architectures struggle to balance cost and performance.
Divergent read/write peaks — Data ingestion and queries each have their own peaks and valleys. When writes, index building, and queries share the same set of nodes, write surges directly impact query latency.
To address these challenges, Agent Engine Edition decouples persistent storage, write compute, and query compute. Index data and persistent state are stored in object storage, and separate node types handle writes and queries. For the role of each component, see Core architecture in this topic.
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 topic.
What it solves: core benefits and scenarios
Read/write splitting with independent scaling
Agent Engine Edition runs writes and queries on different node roles. Configure Index nodes based on your data ingestion volume, and configure Search nodes based on your query concurrency. When one type of workload grows, adjust only the corresponding resources, which greatly reduces contention between writes, index merging, and queries for the same compute resources. Write surges are largely isolated from query latency, and vice versa.
On-demand caching with automatic hot/cold tiering
Complete index data is stored in object storage, and the local disks of Search nodes serve as a query cache. Frequently accessed data is continuously reused from the cache, so hot queries respond in milliseconds. Rarely accessed data is loaded from object storage only when needed. Size the local cache around the active working set; it does not need to match the total data volume. Inactive business spaces consume no compute or cache resources, and their storage cost is limited to object storage pay-as-you-go fees.
Cache benefits depend on the hot/cold distribution of your 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 your actual data.
Hundreds of millions of business spaces under unified management
Agent Engine Edition is designed to support hundreds of millions of business spaces under unified management in a single Collection. An application can treat each knowledge base, code repository, Agent, or tenant as a Slice and complete both reads and writes through the same Collection. The platform manages the underlying indexes and shards based on capacity, so applications do not need to create a separate index for each business space or maintain underlying index names or table schemas in application code. The performance test described in Performance reference in this topic covers 10,000 business spaces.
At query time, you can select one Slice, multiple Slices, or explicitly select all Slices. The query scope must be specified explicitly by default. For the default query behavior, see How data is queried in this topic.
Failure recovery in seconds without data migration
Index data, write logs, and cluster state are stored in object storage, and compute nodes hold no local persistent state. After a node failure, the platform quickly schedules a replacement node that resumes operations from object storage and rebuilds the local cache on demand, with no full data migration required. Shard recovery in traditional stateful architectures takes tens of minutes to hours, so this design reduces the impact scope of a failure.
If the write layer temporarily cannot host the primary (write-serving) shard, new writes are paused. As long as the corresponding Search (query-serving) 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, and combine full-text index, vector KNN, filtering, and aggregation capabilities. Official Python, Java, Go, and JavaScript clients, Kibana, and other ecosystem components can reuse the request structure and query syntax of compatible interfaces, which reduces interface-layer changes. Before migration, verify the interfaces and ecosystem components you use against the compatibility documentation for your instance version.
Disk-native vector index (DiskBBQ)
Agent Engine Edition uses the disk-native vector index DiskBBQ, which delivers IO-predictable KNN queries through hierarchical K-means clustering combined with BBQ quantization. At query time, DiskBBQ probes at most two levels of centroids and reads hit clusters in block-sequential order, which makes it well suited to 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 performance degrades gradually rather than abruptly when memory is constrained. The test results in Performance reference in this topic cover query latency only, not index build speed; verify build performance with your own workload before you make a selection. For field configuration, KNN query parameters, and complete examples, see DiskBBQ and Sliced DiskBBQ vector retrieval.
Scenarios
The following table describes typical scenarios for Agent Engine Edition and the recommended data organization for each scenario:
| Scenario | Recommended data organization | Core value |
| Enterprise knowledge base and RAG | Treat each knowledge base as a Slice | A single Collection manages very large numbers of knowledge bases. Active bases respond in milliseconds, and 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 largely unaffected by batch writes. |
| Agent memory | Partition Slices by tenant, Agent, or independent memory space | Writes are immediately queryable. Dormant memories across large numbers of Agents consume no compute or cache resources. |
| Multi-tenant search service | Treat each tenant or business space as a Slice | The platform manages the underlying indexes, and data is physically clustered per tenant. The query cost of a single tenant depends only on that tenant's own data volume. |
What it consists of: core concepts and architecture
Core concepts
To understand Agent Engine Edition, first distinguish Collection from Slice:
| Concept | Description |
| Collection | The unified entry point for applications to access data. You use it in the same way as 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 corresponding 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 need to store 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
The core architecture of Agent Engine Edition rests on three ideas: persistent data is stored uniformly in object storage, writes and queries are handled by different node types that scale independently, and multiple business spaces are organized through Collections and Slices. 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 locate the data that corresponds to a request. |
| Index node | Handles document writes, write log persistence, index building, and background merging. |
| Search node | Runs full-text, vector, filtering, and aggregation queries, and caches the data required by queries locally. |
| Object storage | Stores index data, write logs, and the persistent state required for cluster operation. Data durability is 11 nines or higher. Billing is based on the actual storage used, with no capacity to pre-provision. On the console instance details page, this capacity is displayed as OpenStore Storage and OpenStore Storage Usage. |
How data is written
When writing data, applications use the Collection name in the URI of the request and identify the business space that the data belongs to through a Slice.
Index nodes process the request. The system confirms write completion to the client only after the write 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
When querying data, applications use the Collection name in the URI of the request and specify one or more business spaces through Slices. By default, queries that do not specify a Slice are rejected, which reduces the risk of unintentionally querying the entire Collection when routing information is missing.
Search nodes first read the data required by the query from the local shared cache.
On a cache miss, Search nodes load the data range required by the current query from object storage. Subsequent queries continue to reuse the hot data that has already entered the cache.
To maintain query availability during node failures, see Stateless architecture and resource planning to configure the number of replicas and Search nodes.
Performance reference
The following results come from a test conducted in July 2026 under a typical application scenario, and they show cold and hot query performance under those test conditions. The test results 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 Agent 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, and 2.8 TB of data |
| Vector configuration | 512-dimensional vectors, dot_product similarity, and bbq_disk index (DiskBBQ) |
| Query method | KNN query that returns 10 results, with a candidate set of 100 |
| Latency metric | Server-side processing time took. Client-side processing and network latency are not included. |
| 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, the minimum number of nodes, and dedicated master node configuration are subject to the options currently available on the purchase page. The latency in the preceding table cannot be reproduced with configurations lower than the test specifications, so 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 you make a formal selection, perform capacity assessment and stress testing with your actual business data and queries.
Version and compatibility
Agent 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, and the last version segment differentiates feature iterations of Agent Engine Edition itself. This version number does not correspond one-to-one with specific Elasticsearch 9.x minor versions, and it does not imply support for every Elasticsearch 9.x feature and API.
Supported features and APIs may vary across 9.99.x versions. Before you create an instance or migrate 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, and security capabilities.
The current Agent 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 number displayed on the console. For the actual Elasticsearch kernel version, the cluster API response is authoritative. When you install custom plugins, use the 9.99.0 version number that matches Agent Engine Edition.
Regions and zones
The regions and zones supported by Agent Engine Edition are subject to the items actually available for purchase on the purchase page. Instance specifications, billing methods, and availability are subject to the Alibaba Cloud official website, the console, and official release announcements. Before a formal migration, complete solution evaluation and performance verification based on API compatibility, data scale, hot/cold distribution, and target query load.
What's next: how to get started
Follow these steps to get started with Agent Engine Edition instances:
Confirm the region and version: On the Alibaba Cloud official website or in the console, confirm that the target region is open for purchase, and consult the API compatibility documentation for the instance version to confirm that the interfaces and ecosystem components you depend on are supported.
Plan your data organization: Based on the Scenarios section, decide whether 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, and configure Search nodes based on query concurrency and the active working set. For the replica and Search node configuration that maintains query availability during node failures, see Stateless architecture and resource planning.
Integrate and verify: Use the Elasticsearch REST API or an official client to complete write and query integration, specify the query scope through Slices, and verify full-text, vector KNN, filtering, and aggregation capabilities.
Run capacity assessment and stress tests: Run capacity assessment and performance stress tests with your actual business data and queries, focusing on cold and hot query latency and cache hit performance, before you proceed with the formal migration.
Future directions
Building on the object-storage-native architecture foundation, the roadmap for Agent Engine Edition includes sub-second zero-copy branching (creating an independent data branch for any Slice based on copy-on-write, suited to evaluation, canary releases, and rollbacks), compute-layer Scale to Zero (automatically scaling idle business spaces down to near zero so that cost aligns further with actual active load), and deeper integration with Alibaba Cloud Elasticsearch ecosystem capabilities. Specific feature release dates are subject to product announcements.