Amazon ElastiCache Serverless for Valkey Adds Vector, Full-Text and Hybrid Search Plus Aggregations: Requires Valkey 9; AWS Says Latency Can Be "as Low as Microseconds," Vector Recall "Up to 99%" and Throughput "Billions of Queries per Day," Vendor Claims This Report Did Not Test, With No Stated Data Size, Hardware or Pricing
On November 10, 2026, AWS announced that Amazon ElastiCache Serverless for Valkey supports vector, full-text and hybrid search and aggregations, lets one query combine search types, and suggests a separate datastore for each agent, session or task. AWS says vector search latency can be "as low as microseconds" at "up to 99% recall", that it can serve "billions of queries per day", and that updates are searchable "in as little as microseconds" after writes complete; "as low as" and "as little as" describe best cases, "up to 99%" caps recall, and "billions of queries per day" is a capacity claim with no stated conditions. All are AWS statements, and neither source gives data size, vector dimension, hardware, test method or price. Search is available on ElastiCache Serverless with Valkey 9 in all commercial Regions, GovCloud (US) and the European Sovereign Cloud Region; the guide adds that node-based clusters need Valkey 8.2 or later. These are minimum versions, not proof that every feature is the same on each version. The pages do not explain access control on the public endpoint or the limits of search write throttling.
On November 10, 2026, AWS announced that Amazon ElastiCache Serverless for Valkey now supports vector, full-text and hybrid search, together with aggregations. The notice describes the problem it targets: applications that search live data face a hard trade-off between latency and recall, and updates often take time before they become searchable. This report uses the AWS notice and the ElastiCache User Guide page "Getting started with Search". All speed and recall figures in both pages are AWS statements. Neither page names a dataset, vector size, hardware or test method, so this report treats them as qualified AWS claims that it did not test, not as measured results.
The notice makes three performance statements. Search can run "with latency as low as microseconds at up to 99% recall for vector search"; it can serve "billions of queries per day"; and updates are searchable "in as little as microseconds, as soon as writes complete". The first and third carry qualifiers; the second does not. "As low as" describes a best case, not a typical or guaranteed figure. "Up to 99% recall" is a ceiling, and recall is the share of true nearest neighbors the search finds, so it varies with index settings and data. "Billions of queries per day" is a capacity claim with no stated test conditions; it is not a stated limit or a daily quota. The guide adds that ElastiCache for Valkey offers "the lowest latency vector search with the highest throughput and best price-performance at 95%+ recall rate among popular vector databases on AWS", with no comparison data on the page. The notice says you can tune recall as needed, which implies the trade-off between speed and recall remains and is now a setting that you choose.
On features, the guide lists real-time full-text search, exact-match search on tags, numeric range search, vector search and hybrid search. The notice says you can combine search types in a single query and analyze results with server-side aggregations. The two pages do not show which combinations, operators or commands are supported, or whether they differ by engine version. The guide points to separate Search features and limits and Command Reference pages for that, and this report did not read them. The notice names uses such as product discovery, recommendation systems and retrieval-augmented generation. The guide says the vector support is meant for embeddings from providers such as Amazon Bedrock, Amazon SageMaker, Anthropic or OpenAI, and for indexing, searching and updating billions of high-dimensional vectors with up to 99% recall. "Billions" is a design claim; the pages do not state a tested size, cost or memory need.
The notice also pitches the feature for AI agents. It says developers can give every agent, session or task its own datastore for memory and context retrieval, so agents can experiment, fail and retry without touching production or each other. Each datastore, it says, is ready in seconds, reachable over a public endpoint with no network setup, and billed only for what it uses, with zero infrastructure to manage. A public endpoint is convenient. The notice does not describe how access is controlled on it, and a security team should read the ElastiCache documentation for authentication and encryption before using it for agent memory that may hold sensitive text. This report did not read that part.
The version conditions are the key facts. The notice says search is available on ElastiCache Serverless for Valkey on version 9, in all commercial AWS Regions, AWS GovCloud (US) Regions and the AWS European Sovereign Cloud Region. You create a new serverless cache or upgrade an existing one to Valkey 9 with the AWS Management Console, SDK or CLI. The guide gives a wider picture: search works on node-based clusters with Valkey 8.2 or later and on ElastiCache Serverless caches with Valkey 9.0 or later. These are minimum versions for search; the pages do not show that every search feature works the same on each version. So an existing cache on an older engine version has to be upgraded first, and the pages do not describe what an upgrade involves. The notice describes Valkey as "the most permissive open source and vendor-neutral alternative to Redis and the recommended engine for ElastiCache". That is AWS's description of its own recommendation.
The guide lists three sub-topics under search: features and limits, choosing the appropriate configuration, and search write throttling. The last one matters. A cache that updates searchable data as soon as writes complete has to protect itself under heavy write load, and the existence of a throttling topic suggests limits apply. The page captured here does not explain them, so the claim that updates are searchable "as soon as writes complete" should be tested under your own write rate. The guide also says that for agent workflows there is an "ElastiCache Skill" and a Valkey MCP server that manage indexes, generate vector embeddings and offer a unified search tool. This report did not test them.
Several things are missing from the sources. There is no price: the notice sends readers to the pricing page. There are no benchmarks with stated data size, vector dimension or hardware, no comparison with other vector databases beyond AWS's own claim, and no description of memory use per million vectors. A team weighing this against a separate search or vector store should run its own test with its real vectors, filters and write rate, measure recall at the latency it needs, and compare the cost with the pricing page. The practical gain, if the claims hold, is to keep fast key-value data and search in one service. The pages do not prove that they hold.
Sources
FAQ
Which version do I need to use search in ElastiCache?
The notice says search is available on ElastiCache Serverless for Valkey on version 9. The guide says node-based clusters need Valkey 8.2 or later and serverless caches need Valkey 9.0 or later. An existing cache on an older version must be upgraded first, and the pages do not describe how.
Can I treat "microseconds" and "up to 99% recall" as guarantees?
No. "As low as" and "up to" describe a best case and a ceiling. Neither page gives data size, vector dimension, hardware or test method, so these are AWS's own statements. A team should measure recall and latency with its own vectors, filters and write rate.
Do the sources give a price or explain access control on the public endpoint?
No. The notice only points readers to the pricing page and gives no price, and neither source explains how access to the public endpoint is controlled. The guide lists search write throttling as a topic, but the captured page does not explain the limits. Read the authentication and encryption documentation before using sensitive data.