Not a pgvector competitor: a different tool. Hot, relational data stays in pgvector next to the app. The long tail goes here, at storage prices, with zero capacity planning.
Use it when
- Searching 10 years of contracts or call transcripts, RAG over a document archive.
- Long-term memory for one AI agent per customer.
- A separate index per client, almost free while idle.
- Tens to hundreds of millions of vectors, queried occasionally, where about 100 ms (under a second cold) is fine.
- Bedrock Knowledge Bases with the lowest storage cost.
Don't use it when
- Search on the latency-critical path of a busy user request.
- Filters that need SQL joins. It has metadata filters only, and no keyword search.
Pricing
Sydney storage $0.066/GB-month; about $2.50 a month for 1M vectors, $15–154 for 10M, $76–473 for 100M (vs $2,000–12,000 to hold 100M in Postgres). No servers to size.
Gotchas, with fixes
Gotcha: No hybrid (keyword + vector) search.
Fix: Search pgvector and S3 Vectors separately and merge with Reciprocal Rank Fusion, or put OpenSearch's s3vector engine on top at scale.
Provisioning
Official Pulumi package · Official Terraform provider
Terraform AWS provider has aws_s3vectors_vector_bucket and aws_s3vectors_index; @pulumi/aws exposes them (s3 module), and @pulumi/aws-native has an s3vectors module.
Instead, consider
- pgvector Hot, relational, latency-sensitive vectors.
Worked examples
Where it fits
- Semantic search and RAG: Pick 02.
When the collection is huge, cold or per client, and 100 ms is fine.
Sources
Last reviewed by Nicolas Dao