Answer in brief
AWS’s September 30 release searches within a metadata-selected set before ranking vectors. The operational detail matters: an index created today can still use the older mode if its bucket predates the release.
The order of operations changes
AWS introduced metadata pre-filtering for Amazon S3 Vectors on September 30. In the new ENHANCED mode, the service first identifies vectors matching a filter and then performs similarity search within that set. For an assistant looking through one customer’s records, that changes which material can compete for a place in the retrieved results before the language model sees anything.
The release targets a specific failure in practical retrieval: a search can return plausible material yet miss relevant records inside a narrowly defined collection. Our reading is that this is an application-quality change as much as a storage feature. The improvement matters when an answer depends on finding the right evidence, but it cannot correct misleading content already present in that evidence.
An old bucket can give a new index the old behavior
Existing indexes stay in CLASSIC mode until updated. AWS also distinguishes the date of the vector bucket from the date of an individual index. Buckets created on or after September 30 default to ENHANCED. An older bucket keeps its existing default, including for indexes created later, unless the administrator changes that default explicitly.
This is the detail most likely to complicate a rollout. Two teams creating indexes on the same day could receive different behavior because their buckets have different histories. The table records the documented states, not performance measurements. Inventorying index modes and bucket defaults gives a clearer deployment picture than relying on the date when an application was released.
| Situation | Documented mode | Action for ENHANCED |
|---|---|---|
| Existing index | CLASSIC until changed | Update the index mode |
| New index in an older bucket | Existing bucket default | Set the bucket default explicitly |
| Bucket created from 30 September | ENHANCED default | Verify index configuration |
| Vectors already stored | Retained in place | No re-ingestion required |
Recall is measured against the permitted collection
AWS says highly selective filters can return up to five times more matching vectors than the same query on CLASSIC indexes. That is a vendor claim about a particular retrieval condition. It does not mean every answer is five times more accurate, nor does it provide a universal latency improvement. We have not reproduced the comparison or run an independent benchmark.
A useful local evaluation would define the relevant documents within each intended search scope, then compare how many are retrieved under identical inputs. It should include small customer collections and broader filters, since the difficulty changes with selectivity. The final answer deserves a separate check: retrieving an extra document helps only if the assistant uses it correctly and attributes its conclusion to the right material.
Filtering is a general search problem
The official pgvector documentation offers independent technical context for this issue. It explains that filtering after an approximate index scan can leave too few results, and describes iterative scans that continue looking until sufficient results or configured limits are reached. This is background about another implementation, not evidence that pgvector and S3 Vectors have equivalent algorithms or measured performance.
The comparison clarifies the question a developer should ask of any vector service: at what stage is the allowed collection applied, and what happens when too few candidates survive? Product names alone do not answer it. A relevant benchmark needs the same embeddings, collection, filter and target result count, along with the cost and latency of the complete query.
Metadata becomes part of the application contract
The release also adds prefix matching with the $startsWith operator. AWS documents up to 2 KB of filterable metadata per vector and up to 100 filter constraints per query, counted by evaluated values. These limits make the shape of metadata consequential. A concise field identifying a collection can be more practical than sending a long list of individual record identifiers.
As an illustrative design question, consider an assistant searching material assigned to one project. The application needs a consistent project field, correct values when records change and a rule for deleted or reassigned documents. A search filter expresses that chosen scope; its existence alone does not prove that the caller is authorized to choose any project. Access checks still belong in the surrounding application design.
The rollout can be evaluated without changing the model
AWS says the update requires no re-ingestion or query changes and carries no additional feature charge. Standard S3 Vectors charges remain. The announcement states availability in commercial regions supporting the service and AWS China regions. Teams should match that statement to the actual region and index they operate, then confirm the resulting mode rather than infer it from an account setting.
For an enterprise already using this store, a focused comparison can hold the model constant and examine the retrieval layer alone. Record missing evidence, irrelevant results and response time before and after the mode change. That makes the consequence understandable: the September release changes how scoped evidence is found, while the quality of the records and the assistant’s interpretation remain separate responsibilities.
Questions and answers
Must existing vectors be uploaded again?
AWS says the mode change happens in place without re-ingesting vectors or changing queries. Teams still need the relevant permissions and should verify the index mode and retrieval behavior after the update.
Does a new index automatically use ENHANCED?
Only the bucket’s default determines that. Buckets created on or after September 30 use ENHANCED; older buckets retain CLASSIC until their default is changed, including for newly created indexes.
Does the feature make search free?
No. AWS states that pre-filtering has no additional feature charge. Standard storage, upload and query charges still apply, and a complete application may also incur embedding, model and other service costs.