ElastiCache Serverless search: what it means for RAG

On November 10, 2026, AWS announced that ElastiCache Serverless for Valkey supports vector, full-text and hybrid search, plus aggregations. If you already run ElastiCache and keep embeddings for RAG, agent memory or semantic caching in a separate vector database, this gives you one fewer system to consider. If you have no latency problem and your vector store works, you can ignore it.

What was announced, and what is different?

AWS says you can now run vector, full-text and hybrid queries on a serverless cache and combine them in one query. It adds server-side aggregations and says updates are searchable within microseconds of write completion. The announcement quotes latency "as low as microseconds" at up to 99% recall. Treat both numbers as vendor claims: they depend on your data, index settings and recall target, and you should measure them yourself.

Search requires ElastiCache for Valkey version 9. The announcement lists all commercial Regions, AWS GovCloud (US) and the AWS European Sovereign Cloud. You create a new serverless cache or upgrade an existing one, using the console, SDK or CLI.

Before this change, the search documentation and its limits page show search was available on node-based clusters: vector search from Valkey 8.2, and text, tag, numeric, hybrid search and aggregations from 9.0. What is new is that you can get it without choosing node types and shards yourself.

1. App or agentsends the user question
2. Embedding modelturns text into a vector
3. ElastiCache searchvector, text or hybrid query
4. Model callanswers with retrieved text

What are the limits of the serverless version?

The search features and limits page gives different maximums for serverless and node-based caches. As of November 2026, for ElastiCache Serverless:

• Vector dimensions: up to 4,096 (node-based 9.0 allows 32,768).
• Indexes per cache: 1,000. Fields per index: 1,000.
• Prefixes per index: 8.
• Nearest neighbors (K) in a vector query: 512 (node-based 9.0 allows 10,000).
• HNSW parameters: M up to 32, EF_CONSTRUCTION up to 256, EF_RUNTIME up to 512.
• Text attributes per index: 64.

The same page says Valkey 9.0 search is based on Valkey Search 1.2 and does not support the FT.HYBRID command. Check how hybrid queries are expressed in the current command reference before you design around them.

A dimension limit of 4,096 covers most common embedding models, but check yours. A K of 512 is plenty for typical RAG retrieval, where you pass a handful of chunks to a model. It matters more if you re-rank thousands of candidates.

Does it replace your vector database?

Not automatically. AWS positions this for latency-sensitive uses such as agent memory, product discovery, recommendations and RAG (the search docs also list semantic caching). A few honest trade-offs:

• It is an in-memory system. Valkey keeps data in memory, so a large corpus of embeddings has a different cost profile than disk-based stores. Run the numbers for your corpus size.
• Indexes bring operational rules. An index backfill pauses if memory fills up, and the docs warn about limits on transactions and snapshots with indexes. Read the operational restrictions before you commit.
• Access control works at the index level. A user can use an index only if they can read all keys the index prefixes could match. That matters for multi-tenant data: one index per tenant is the cleaner model, but mind the 1,000-index limit.
• It is not a system of record. Keep your source documents elsewhere and be able to rebuild the index.

If your vectors already live in PostgreSQL with pgvector and your latency is fine, moving them is a decision you need a reason for.

What does it cost?

AWS says billing follows what each datastore uses, and the limits page says serverless search is billed through ElastiCache Processing Units (ECPUs) and data stored. The announcement lists no rates and points to the ElastiCache pricing page. As of November 2026, that page's Valkey Serverless examples in US East (N. Virginia) use $0.084 per GB-hour of data stored and $0.0023 per million ECPUs, with a 100 MB minimum per cache. It also says each search index adds 30% of the text or numeric data it covers and 10% of the vector data it covers to what you pay for. The page includes a worked agent-memory example; read it, and recheck the rates for your Region.

Embeddings are the usual cost surprise. A million chunks at 1,024 dimensions of 4-byte floats is about 4 GB of raw vectors, plus the 10% index charge, so roughly 4.4 GB billed, before the text. That is an illustrative calculation, not a benchmark.

How would a team try it safely this week?

1. Pick one read-heavy use, such as semantic caching or agent memory, not your main product search.
2. Create a separate serverless cache on Valkey 9 in a non-production account. Do not upgrade a production cache first.
3. Load a sample of real documents (for example 50,000 chunks) and the embeddings you already use.
4. Build a small set of real questions with known good answers. Compare recall and latency with your current store, using the same data.
5. Watch the ECPU and data-stored usage that drive the bill for a full day of realistic traffic, then compare the bill estimate.
6. Test failure cases: a full cache, an index rebuild, and a client that retries on timeout.

What would we check first?

Before adopting it, we start with these questions:

• Is latency really the bottleneck? Model calls often take far longer than a vector lookup. If retrieval is a small share of the response time, search speed will not change what users feel.
• How is tenant data separated? Index-level access and the prefix limit shape your design.
• What is the rebuild plan? If the index is lost, how long does reloading and re-embedding take, and what does it cost?
• Does it fit your data residency rules? Confirm the Region, especially for Canadian data.

If you want a senior second opinion on an AI retrieval architecture, our services page describes how we work.

This article is general information, not financial or architecture advice. Check current AWS documentation and pricing for your Region before you decide.