AWS ElastiCache Serverless adds Valkey vector search without instance planning

What changed

Vector search has landed on ElastiCache Serverless for Valkey. According to a hands-on write-up on dev.to, AWS switched the feature on for serverless caches running Valkey 9 or later on November 10, 2026, bringing vector search, full-text search, combined queries and server-side aggregations to the managed tier.

The practical shift is capacity planning. Previously, vector search on ElastiCache required a cluster on provisioned nodes, where you selected instance types and sized memory yourself. A serverless cache removes that work: it provisions in seconds and is billed by usage. Node-based clusters keep their search support; the new part is not having to think about instance sizes at all.

Citing the AWS announcement, dev.to reports microsecond-level latencies and recall of up to 99 percent for vector search. Recall measures how many of the true nearest neighbours an approximate search actually finds. Freshly written entries become queryable immediately, with no indexing step to wait for. Availability covers every commercial Region plus GovCloud and the AWS European Sovereign Cloud, and existing serverless caches can be upgraded to Valkey 9.

How the queries work

As with other vector stores, ElastiCache holds embeddings: numerical representations of text produced by a model, positioned so that entries with similar meanings sit close together even when they share no words. A query then looks for the k nearest neighbours, or KNN. To keep this fast across millions of entries, Valkey uses the HNSW algorithm, a layered graph approach that returns approximate results; an exact but slower FLAT mode is also available.

Indexes are not limited to vectors. The dev.to article outlines three additional field types: TEXT for full-text matching, TAG for exact values such as a genre, and NUMERIC for ranges like a publication year. In the Valkey Search query language you write a filter, an arrow operator, then the KNN clause, so the neighbour search runs only across entries that satisfy the filter.

The hybrid caveat

That filter-then-KNN pattern is what AWS means by hybrid search here, and the naming deserves scrutiny. Valkey Search also defines a separate FT.HYBRID command that fuses text and vector rankings into a single result list. Per the ElastiCache feature documentation cited by dev.to, Valkey 9.0 does not support that command, so customers get filtering followed by a vector search rather than a weighted blend of two ranked lists. Anyone arriving from Elasticsearch expecting Reciprocal Rank Fusion should calibrate accordingly, although for most everyday applications filter-plus-vector is enough.

Reaching it from Lambda

The networking side matters as much as the search itself. AWS introduced public endpoints for ElastiCache Serverless with Valkey 9 back in September; the endpoints are not new, but only now do they pair with search capability. The dev.to author assembled a working example around the combination: a book-search application for an imaginary municipal library, with embeddings from Amazon Bedrock's Titan Text Embeddings V2 model, a search index in Valkey, and a Lambda function behind an HTTP API deployed through the Serverless Framework.

The Lambda deliberately runs without a VPC. It reaches Bedrock and the cache over the public internet, with traffic encrypted via TLS and access governed by IAM, which spares users the cost of a NAT gateway. The client is Valkey GLIDE, the official Valkey client: largely written in Rust and distributed as a native library, it refreshes IAM tokens automatically and exposes the search commands through a dedicated GlideFt module.

The memory catch

Going serverless does not make memory somebody else's problem. The dev.to article identifies memory as the biggest pitfall: each vector is kept in RAM twice, so cost estimates should start from vector count and dimensions rather than assuming the serverless tier hides memory usage.

Why it matters

This release lowers the barrier to semantic search on AWS considerably. With no instances to size, no cluster to operate and no VPC or NAT gateway to pay for, a working hybrid search setup is now roughly one cache creation plus an IAM policy away — an architecture that fits naturally alongside serverless functions.

The framing also reveals the target audience. As dev.to notes, the announcement points to a pattern where each AI agent, session or task gets its own datastore behind a public endpoint with no network setup — a design plainly shaped around agents and their need for memory. The caveats are real but manageable: a narrower definition of hybrid than some will expect, and a doubled memory footprint that quietly drives the bill. Knowing both up front separates a cheap experiment from an expensive surprise.