Search features and limits
Search availability
ElastiCache Valkey version 9.0 and above provides support for pure non vector, vector, and hybrid workloads including Numeric, Tag (exact-match), Full-text, Vector searches, and Aggregations on node-based clusters in all AWS Regions at no additional cost.
ElastiCache Valkey version 8.2 provides support for Vector Search on node-based clusters in all AWS Regions at no additional cost.
You can also use search on your existing clusters by upgrading from any version of Valkey, or Redis OSS to Valkey versions mentioned above, in a few clicks with no downtime.
Search is currently available on all ElastiCache instance types other than nodes with data tiering. Using search on t2, t3, and t4g instances requires increasing the memory reserve to at least 50% for micro and 30% for small instances. See this page to find out more.
Parametric restrictions
The following table shows limits for various search items:
| Item | Maximum value (9.0+) | Maximum value (8.2) |
|---|---|---|
| Number of dimensions in a vector | 32768 | 32768 |
| Number of indexes that can be created | 1000 | 10 |
| Number of fields in an index | 1000 | 50 |
| FT.SEARCH TIMEOUT clause (milliseconds) | 60000 | 60000 |
| Maximum number of prefixes allowed per index | 16 | 16 |
| Maximum length of a tag field | 10000 | 10000 |
| Maximum length of a numeric field | 256 | 256 |
| HNSW M parameter | 2000000 | 2000000 |
| HNSW EF_CONSTRUCTION parameter | 1000000 | 4096 |
| HNSW EF_RUNTIME parameter | 1000000 | 4096 |
| Number of terms allowed to be used in a query string in FT.SEARCH/FT.AGGREGATE commands | 1000 | 16 |
| Number of text attributes allowed per index | 64 | NA |
| Maximum text word expansions in Prefix, Suffix, Fuzzy, and Stem Term Searches | 200 | NA |
Operational restrictions
Index Persistence and Backfilling
You can read more about this at Valkey search index creation and backfill
Scaling limits
In ElastiCache Valkey version 9.0, during scaling events, the write RPS may reduce for the duration of the event. In ElastiCache Valkey version 8.2, during scaling events, the index may undergo backfill as data is migrated and this will result in a reduced recall for search queries.
Snapshot import/export and Live Migration
The RDB files from the one cluster with search indexes can be imported to another ElastiCache Valkey cluster with version 8.2 or higher. The new cluster will rebuild the index content on loading the RDB file. However, the presence of search indexes in an RDB file limits the compatibility of that data with prior versions of Valkey. The format of the search indexes defined by the vector search functionality is only understood by another ElastiCache cluster with Valkey version 8.2 or higher. However, RDB files that do not contain indexes are not restricted in this fashion.
Out of Memory during backfill
Similar to Valkey OSS write operations, an index backfill is subjected to out-of-memory limitations. If engine memory is filled up while a backfill is in progress, all backfills are paused. If memory becomes available, the backfill process is resumed. It is possible to delete an index when backfill is paused due to out of memory.
Transactions
The commands FT.CREATE and FT.DROPINDEX, cannot be executed in a transactional context, i.e., not within a MULTI/EXEC block or within a LUA or FUNCTION script. Additionally, the FT.SEARCH and FT.AGGREGATE commands cannot be executed in a transactional context in a ElastiCache Valkey Cluster operating in Cluster Mode.
Search security
Valkey ACL (Access Control Lists)@search, is provided and many of the existing categories (@fast, @read, @write, etc.) are updated to include the new commands. Search commands do not modify key data, meaning that the existing ACL machinery for write access is preserved. The access rules for HASH and JSON operations are not modified by the presence of an index; normal key-level access control is still applied to those commands.
Search commands with an index also have their access controlled through ACL. Access checks are performed at the whole-index level, not at the per-key level. This means that access to an index is granted to a user only if that user has permission to access all possible keys within the keyspace prefix list of that index. In other words, the actual contents of an index don't control the access. Rather, it is the theoretical contents of an index as defined by the prefix list which is used for the security check. Situations where a user has read and/or write access to a key but is unable to access an index containing that key are possible. Note that only read access to the keyspace is required to create or use an index – the presence or absence of write access is not considered.