S3 Vectors adds metadata pre-filtering and lifts recall on filtered searches by up to 5×

September 30, 2026. Amazon S3 Vectors adds metadata pre-filtering: the service now evaluates the filter before the similarity search. September 30, 2026. On highly selective filters, the same query returns up to 5 times more relevant vectors than before. September 30, 2026. Each vector carries 2 KB of filterable metadata, a single query accepts 100 filter constraints, and a new $startsWith operator covers paths, URLs and hierarchical keys. Why it matters: most RAG and semantic search applications never search the whole index — they search the subset belonging to one customer, account or category, and that is exactly where they were silently dropping results.

The problem: filtering after the fact loses matches

A filtered vector search must satisfy two requirements at once: return only relevant vectors and search only the right scope. Historically, S3 Vectors handled both in tandem: the similarity search drew its candidates from the entire index, then validated each against the filter on the fly. That mode, now called CLASSIC, produces a counterintuitive consequence: the more selective the filter, the more the genuinely relevant matches risk being missing from the result.

Take a support knowledge base of 8 million tickets. An agent searches the history of a customer who accounts for only 400 tickets. In CLASSIC mode, the search drew candidates from all 8 million, then kept only that customer’s — so the result held only a fraction of the 400 relevant tickets. With pre-filtering, the customer_id filter is resolved first, similarity runs across only the customer’s 400 tickets, and the agent finally sees the prior occurrences.

That is the core point: pre-filtering does not make the search “more precise” in the strict sense — it restores access to the full set of matches that should have been in the answer.

Two index modes, one in-place switch

Every S3 Vectors index has an index mode. In ENHANCED mode, the service resolves the filter first, then searches only the vectors that match. In CLASSIC mode, it runs the search and the filter evaluation in tandem, as before. Existing indexes stay in CLASSIC until you update them.

The switch is deliberately light: a single command, no query changes, no re-ingestion.

aws s3vectors update-index-mode \
  --vector-bucket-name my-vector-bucket \
  --index-name product-catalog \
  --index-mode ENHANCED

Pre-filtering takes effect in place. Existing vectors are not re-ingested, queries do not change, and the new filter operators are available immediately. All of it with no additional cost — only standard S3 Tables pricing applies.

Rich metadata and a prefix operator

The data model grows alongside. Each vector can carry up to 2 KB of filterable metadata, and by default every metadata field is filterable without declaring a schema up front. A single query accepts up to 100 constraints, combinable with $and, $or, equality, numeric ranges and existence checks.

The most awaited addition is $startsWith, which introduces prefix matching into the filter language. For a document store that encodes folder structure into the identifier, one condition is enough to scope a search to a subtree:

--filter '{"$startsWith": {"document_id": "matter-4417/exhibits/"}}'

This operator joins equality, numeric ranges, set membership, existence checks and boolean logic. For multi-tenant indexes, the payoff is immediate: a tenant_id field resolved by pre-filtering isolates the search within a single customer’s data before similarity is even computed.

Because every metadata field is filterable by default, the feature scales without schema migrations: teams add new tenant, status or region fields as their application evolves, then query on them immediately. The 2 KB budget is generous for the identifiers and categorical flags that scoped search actually uses, though it is not meant to carry large payloads — keep documents and summaries in the vector’s source object, not in its metadata.

The full flow in three steps

The implementation follows the usual path. Create the index declaring the embedding model’s dimension and distance, write vectors with their metadata, then query with a filter.

# 1. Create the index
aws s3vectors create-index \
  --index-name product-catalog \
  --vector-bucket-name my-vector-bucket \
  --dimension 1536 \
  --distance-metric cosine

# 2. Write a vector with its metadata
aws s3vectors put-vectors \
  --index-name product-catalog \
  --vector-bucket-name my-vector-bucket \
  --vectors '[{
    "key": "doc-001",
    "data": {"float32": [0.1, 0.2, 0.3]},
    "metadata": {"tenant_id": "t-10428", "category": "legal", "active": true}
  }]'

# 3. Query with a combined filter
aws s3vectors query-vectors \
  --index-name product-catalog \
  --vector-bucket-name my-vector-bucket \
  --query-vector '{"float32": [0.1, 0.2, 0.3]}' \
  --top-k 50 \
  --return-metadata \
  --filter '{"$and": [{"tenant_id": "t-10428"}, {"category": "legal"}, {"active": true}]}'

The dimension must match the embedding model’s output size, and the distance metric must match how it was trained — cosine is the common choice for text embeddings. In ENHANCED mode, S3 Vectors first narrows the search space to vectors satisfying all three conditions, then returns the 50 closest from that subset, not from a sample drawn across the entire index.

Two operational notes. First, pre-filtering is available through the AWS CLI, the console and the SDKs, so teams can enable it without changing their application code. Second, because the switch is in place and reversible in spirit — you can move an index back to CLASSIC the same way — it is a low-risk experiment: flip a staging index to ENHANCED, compare recall against CLASSIC, then roll out.

The feature is available now in every region where S3 Tables is offered, at no additional cost — only standard S3 Vectors pricing applies. Activation happens through the console or the CLI, and teams that drive their infrastructure through AI agents can query the documentation and troubleshooting via the AWS MCP Server and its plugins. For existing indexes, the move to ENHANCED is the only action required: no data migration, no schema change, no application redeployment.

Pre-filtering vs post-filtering: the dilemma the feature settles

The choice between pre-filtering and post-filtering is not new to AWS: it runs through the whole vector-database ecosystem, from pgvector to purpose-built engines. Each approach has a price. Post-filtering guarantees that no relevant vector is dropped by a filter mistake, but it dilutes the search across the whole index — and the larger the index, the more likely the matches of a narrow subset are to be drowned out. Pre-filtering shrinks the search space before computing similarity, so it is faster and returns more, but it assumes the filter itself is correct: a badly written filter returns nothing at all.

What S3 Vectors does is make that choice explicit through the index mode, rather than imposing it silently. The user keeps control: leave an index in CLASSIC if a flawed filter is a worry, or move to ENHANCED once the conditions are trusted. The “up to 5×” figure applies to highly selective filters — typically the multi-tenant scenario where a tenant_id isolates a few hundred vectors among millions — which is precisely where post-filtering hurt the most.

The switch also removes a costly architectural decision. Until now, a team wanting reliable pre-filtering sometimes had to multiply indexes per customer, or adopt an external vector database. ENHANCED mode makes that need obsolete for most RAG and scoped document-search cases, keeping a single index and a single source of truth.

Verdict

If you run a multi-tenant S3 Vectors index or a per-client document search, switch your indexes to ENHANCED mode now: recall can rise up to 5× on selective filters, the operation is free, in place and re-ingestion-free, and your queries do not have to change. If you rarely filter, or filter at very broad scope, the change is safe but less decisive — pre-filtering pays off most when the filter sharply narrows the search space. In every case, make sure your IAM policy grants the new index-mode update actions before you flip the switch.

References

• AWS News Blog — Amazon S3 Vectors now supports metadata pre-filtering for higher recall on filtered searches (September 30, 2026)
• Amazon S3 Vectors — documentation