Feature overview
The Alibaba Cloud Elasticsearch (ES) engine-enhanced edition strengthens complex queries, elastic scaling, and large-scale data storage through a proprietary retrieval kernel, storage engine, and managed write service. Match each advanced enhancement to your workload by query latency, write scale, data retention period, and resource cost.
Advanced enhancements cover the following capabilities: FalconSeek accelerates queries; OpenStore high-performance retrieval and OpenStore log enhancement optimize the storage layer for online retrieval and log analysis respectively; Indexing Service hosts writes and index building; and SliceCollection, provided by the Agent engine edition, targets RAG, AI coding, Agent memory, and multi-tenant search. The version matrix below lists the supported versions and default switch states of each feature.
Core value
| Value dimension | Features | How it works and business value |
| Faster performance | FalconSeek; Indexing Service | FalconSeek optimizes the execution path for complex queries and vector retrieval to improve query performance; Indexing Service optimizes the write and index-building pipeline to improve write throughput. |
| Better elasticity | OpenStore high-performance retrieval; OpenStore log enhancement | OpenStore high-performance retrieval uses shared storage to reduce data migration during compute scaling; OpenStore log enhancement makes storage capacity scale with the actual data volume. |
| Cost optimization | OpenStore high-performance retrieval; OpenStore log enhancement; Indexing Service | OpenStore high-performance retrieval removes the need for each compute replica to keep a full copy of the data; OpenStore log enhancement uses object storage to lower long-term retention cost; Indexing Service removes the need to reserve fixed compute for peak writes. |
| Scenario-based capability packaging | Retrieval: FalconSeek + OpenStore high-performance retrieval; Log: Indexing Service + OpenStore log enhancement; AI/Agent: SliceCollection | Combining query, storage, and write capabilities by workload simplifies resource planning and operations for online search, log analysis, and large-scale business-space retrieval. For the combination that matches each business scenario, see Capability combinations by scenario. |
Feature descriptions
FalconSeek: acceleration for complex queries and vector retrieval
FalconSeek is a cloud-native retrieval kernel built on Alibaba's proprietary Havenask engine. Its C++ columnar in-memory design and fully asynchronous execution framework optimize performance-sensitive scenarios such as complex aggregations, high-cardinality term queries, and vector retrieval.
Optimized query execution: Improves compute and data-access efficiency for workloads such as complex aggregations, semantic search, and image-based search.
Balanced performance and compatibility: The default
nativestrategy uses FalconSeek first and falls back to the native Elasticsearch engine for syntax or features that FalconSeek does not yet support. You can also specify an execution strategy for comparison or debugging.Per-index enablement: Configure
After you enable the feature on an instance, you must still enable FalconSeek for each target index. Applying a configuration change to an existing index requires you to close and reopen the index, so schedule a change window in advance. For configuration steps, see FalconSeek cloud-native kernel.index.havenask.engine.enabled: truefor each index that needs acceleration.
OpenStore high-performance retrieval: shared storage for fast compute scaling
OpenStore high-performance retrieval corresponds to the "OpenStore storage-compute separation (high-performance retrieval) engine". It combines DFS shared storage with a local cache: persistent data is stored separately from the compute nodes, and the local cache serves hot access. This capability suits real-time search, online analytics, and real-time reporting.
Reduced data migration: Compute nodes can access data in shared storage, which eases the dependence on migrating full shard data during scaling.
Lower replica storage overhead: Compute replicas share persistent data, so each replica no longer keeps a full copy of the data. Data reliability is guaranteed by the underlying storage.
Balanced query latency and capacity growth: The local cache accelerates hot-data access, and you can plan compute, cache, and shared-storage capacity separately based on query load and data scale.
This capability focuses on resource elasticity and storage efficiency for online retrieval. Shared storage still requires capacity planning, and the local cache size and hit ratio also affect query performance. For architecture and configuration limits, see Openstore engine: Decoupled storage and compute for high-performance retrieval.
OpenStore log enhancement: low-cost retention with direct queries on historical data
OpenStore log enhancement corresponds to the "OpenStore intelligent hybrid storage (log analysis) engine". By using Object Storage Service (OSS) together with a cache, it supports long-term retention of massive log and time-series data. This capability suits log, monitoring metric, audit, and IoT data analysis.
Pay for actual storage: You do not need to buy fixed disk capacity that covers the entire retention period in advance; storage cost changes with the actual data volume.
Direct queries on historical data: Offloaded data can still be queried through Elasticsearch without a snapshot restore first.
Simplified hot-cold data management: Data is offloaded automatically, which reduces the manual work of maintaining hot-cold tiering and restoring historical data.
This capability focuses on long-term retention cost and suits log-analysis workloads with relatively low query frequency and higher tolerance for query latency. For sustained high-concurrency, low-latency queries, evaluate the cache hit ratio and choose OpenStore high-performance retrieval if needed. For details, see OpenStore Storage Engine (Log Analytics).
Managed writes and index building
Indexing Service offloads write computation and index building to a cloud service. Through physical replication, storage-compute separation, and write-path optimization, it reduces the write-computation pressure on your query cluster. Indexing Service suits log and time-series analysis scenarios with high write throughput, large write-traffic fluctuations, and relatively low query frequency.
Elastic write resources: The backend manages compute resources based on write load, which reduces the need to reserve fixed nodes for write peaks.
Separate read and write planning: The write side and the query side are provisioned independently — write resources follow write load, and query resources follow retrieval needs. For the billing items of each side, see Cost structure and resource planning.
Simplified write operations: The service manages the hosted write resources and related parameters, which reduces capacity-management work on the write path.
The managed service imposes limits on write traffic, document count, and shard count, and the service controls somerefresh,merge, andtranslogparameters. For access methods, billing, and usage limits, see Introduction to the Indexing Service series. Public write benchmark data is provided in Performance reference.
SliceCollection: unified management of massive Agent and tenant business spaces
SliceCollection is provided by the Agent engine edition for RAG knowledge bases, AI coding repositories, Agent memory, and multi-tenant search. A Collection gives your application a single entry point, and Slices organize the individual business spaces — knowledge bases, code repositories, Agents, or tenants — which reduces the complexity of managing a separate traditional Elasticsearch index for each business space.
Single entry point: Access and manage a group of business spaces through a Collection to simplify application integration.
Organize data by business space: Use Slices to represent knowledge bases, code repositories, Agents, or tenants, which fits retrieval needs across many independent business spaces.
Decoupled storage, write, and query: Object storage holds index data and persistent state, index nodes handle writes and index building, and query nodes handle retrieval, so you can plan compute separately by read and write load.
Consider this capability when the main challenge is managing many business spaces and scaling read and write loads independently. For core concepts and the single entry point, see SliceCollection for Massive Multi-tenant Retrieval.
Capability combinations by scenario
| Business scenario | Capability combination | Role of each feature | Selection focus |
| Complex aggregations, semantic or vector retrieval on standard indexes | FalconSeek | Accelerates query execution on the target index | Query syntax, index configuration, and performance gains on the real query set |
| Online search and real-time analytics with clear data growth or traffic fluctuation | FalconSeek + OpenStore high-performance retrieval | FalconSeek accelerates queries; OpenStore high-performance retrieval optimizes shared storage, cache, and compute elasticity | Target latency, hot-data scale, cache hit ratio, and scaling needs |
| High-concurrency log writes and long-term data retention | Indexing Service + OpenStore log enhancement | Indexing Service hosts writes; OpenStore log enhancement provides low-cost storage and historical queries | Peak writes, data visibility, retention period, and historical query frequency |
| Large numbers of knowledge bases, code repositories, Agents, or tenant spaces | Agent engine edition + SliceCollection | Manages business spaces uniformly and plans storage, write, and query resources separately | Number of business spaces, active ratio, read/write load, and query patterns |
Each combination in the table requires both features to be available for your instance. The version matrix below reports support and default switch states for each feature separately, so confirm the availability of a specific combination in the documentation for each feature.
Feature and version support
The following table lists feature support and default switch states for each version and product form.
| Version / product form | FalconSeek | OpenStore high-performance retrieval (DFS) | OpenStore log enhancement (OSS) | SliceCollection | Indexing Service |
| 9.4 (recommended) | ○ | ○ | ○ | — | ○ |
| 8.17 | ◐ | ◐ | ○ | — | ○ |
| 7.10 | — | ◐ | ○ | — | ○ |
| 6.7 and other versions | — | — | — | — | — |
| Agent engine edition (9.x) | — | — | — | ● | — |
Legend: ○ On by default, can be disabled; ◐ Off by default, can be enabled; ● On by default, cannot be disabled; — Not supported or not applicable.
The matrix is for checking feature support and the default switch state of each feature. It does not mean that all features take effect on the same instance at once, and existing instances do not change automatically. The default switch state is the state at the purchase or instance-configuration entry, so indexes, data streams, and business spaces may still require further configuration: FalconSeek, for example, must be enabled for each target index even when it is on by default at the instance entry. Actual availability depends on the site, region, instance architecture, and the options available in the console.
Cost structure and resource planning
When you choose features, evaluate the total cost across compute, storage, cache, and managed services.
| Feature | Resources or costs to note | Planning basis |
| FalconSeek engine | FalconSeek currently has no extra charge; the workload still consumes the instance's compute, memory, and storage resources | Query type, index scale, vector dimension, and recall parameters |
| OpenStore high-performance retrieval | Compute nodes, local cache disks, and DFS shared storage | Persistent data volume, hot-data scale, and query concurrency |
| OpenStore log enhancement | Storage billed by actual usage, plus the corresponding compute and cache resources | Daily increment, retention period, and historical query frequency |
| Indexing Service | Actual write traffic, managed storage space, and query-cluster resources | Peak traffic, per-shard writes, and hosting period |
| SliceCollection | Persistent storage, write compute, and query compute of the Agent engine edition; see the product billing documentation for specific billing items | Number and active ratio of Slices, read/write load, and query concurrency |
Free-trial policies and specific prices are subject to the latest billing documentation and to the prices shown on the purchase page. When you evaluate capacity, review throughput, query latency, data visibility, and actual resource usage together.
Performance reference
Alibaba Cloud's public Indexing Service write benchmark uses the nyc_taxis dataset from ES Rally. Each test group uses 3 data nodes, 15 shards, and 1 replica, with asynchronous translog and physical replication enabled and refresh_interval set to 5 seconds.
| Per-node specification | General-purpose edition write TPS | Indexing Service write TPS | Throughput ratio (Indexing Service / General-purpose edition) |
| 2 cores, 8 GB | 24,883 | 226,649 | About 9.11× |
| 4 cores, 16 GB | 52,372 | 419,574 | About 8.01× |
| 8 cores, 32 GB | 110,277 | 804,010 | About 7.29× |
The ratios are computed from public TPS values and compare complete write solutions that include cloud-managed resources. In the test, write-visibility latency was 5 seconds for the general-purpose edition and 6 seconds for Indexing Service. The data comes from Introduction to the Indexing Service series and does not represent a pure-kernel performance ratio under the same total resources. Actual gains depend on your data, configuration, and load.
The performance and cost of the two OpenStore types also depend on the storage medium, cache hit ratio, and access pattern. See the reference metrics in Openstore engine: Decoupled storage and compute for high-performance retrieval and OpenStore Storage Engine (Log Analytics).
References
For open source features available in each version, see Features by version.
To create an Alibaba Cloud ES instance, see Create an Alibaba Cloud Elasticsearch cluster.