Amazon S3 Vectors adds metadata pre-filtering for up to 5x higher recall on filtered searches

This fixes a well-known weakness of filtered vector search. Previously, S3 Vectors applied metadata filters after the nearest-neighbor search. With a selective filter, such as one tenant or one document folder, most of the top-k results would be thrown out, leaving few or no relevant hits. Now filters are evaluated first, and similarity search runs only within the matching subset. AWS says this returns up to 5x more matching vectors on selective filters.

The new $startsWith operator filters by prefix. That makes it easy to restrict a search to a path, a URL prefix or a hierarchical identifier. Typical uses include a RAG system that searches only one customer's documents, or an agent that searches within a specific repository directory.

Competitive context: pre-filtering is standard in dedicated vector databases such as Pinecone, Weaviate and Qdrant, and in pgvector setups. S3 Vectors' pitch is low cost and object-storage scale rather than lowest latency. Closing the recall gap removes a main reason teams might choose a dedicated vector database. Together with Aurora PostgreSQL's new DuckDB-powered lake queries and S3 Tables' full Iceberg V3 support, the update shows AWS consolidating more of the data layer for agents into S3.

Caveats:

- AWS gave no latency or cost impact figures.

- The "up to 5x" figure applies to selective filters. Broad filters will see little change.

- Teams should benchmark with their own data before replacing a dedicated vector store.