AWS vector store guide: pick OpenSearch for speed, Aurora+pgvector for joins, S3 Vectors for scale

Quick answer for executives

OpenSearch: pick this when you need sub‑50 ms median latency, a mix of semantic and keyword relevance, and faceted filtering for product search or e‑commerce.
Aurora + pgvector: pick this when you need to join vectors with relational data or require transactional guarantees, for example customer chatbots, RBAC, or metadata joins.
S3 Vectors: pick this when you need massive, cost‑sensitive capacity for research or large offline corpora and can tolerate sub‑second retrieval.

Why this decision matters

Retrieval Augmented Generation systems embed documents and queries, retrieve the top‑n chunks (usually 5-10), and hand them to an LLM as grounded context. Your vector store controls three concrete business levers: latency (how responsive the app feels), storage cost (how big your bill will be), and retrieval quality (how relevant the LLM’s context is).

AWS’ published benchmarks (authors Deepak Dalakoti, Petar Vuk Avramovic, Rhys Lewis) put three customer‑managed backends into numbers you can act on: Amazon OpenSearch Service, Amazon Aurora PostgreSQL with pgvector, and Amazon S3 Vectors. The results make trade‑offs tangible for product search, deep research agents, and customer‑facing chatbots.

Benchmarks: what was measured (short methodology)

  • Datasets: ESCI “Shopping Queries” product catalog (1, 215, 851 products, 97, 345 judged queries; 5, 000 sampled queries for evaluation); a Wikipedia subset (used with Amazon Titan Text Embedding v2, 1024‑dim); and a 500, 000‑chunk book‑summary knowledge base for Aurora tests.
  • Indexing & engines: OpenSearch Serverless Classic used FAISS‑style k‑NN with HNSW (M=24, ef_construction=128); Aurora used pgvector with HNSW and IVFFlat options; S3 Vectors used Titan v2 1024‑dim float embeddings and object‑store indexing. Distance metrics reported: L2 for floats, Hamming for binary.
  • Metrics: ranking quality reported as NDCG@10; latency percentiles p50/p95/p99; ANN index size in GiB. OpenSearch latency reported at concurrency 1 and concurrency 10 where noted; Aurora instances were warmed for ≥15 minutes to remove startup bias. S3 Vector latencies exclude embedding generation time.
  • Important caveat: AWS notes these workloads were tailored per database rather than a single head‑to‑head test, so the figures illustrate trade‑offs rather than a strict apples‑to‑apples comparison.

What the benchmarks found

Amazon OpenSearch Service, low latency and hybrid relevance

OpenSearch is the low‑latency, feature‑rich option in these tests. It supports k‑NN semantic search, BM25 keyword search, hybrid fusion, plus faceted filters and aggregations for product UIs. The product test indexed 1, 215, 851 product descriptions from ESCI and evaluated 5, 000 queries.

  • 1024‑dim float (baseline semantic k‑NN): NDCG@10 = 0.3627; p50 = 31 ms; ANN index = 5.34 GiB.
  • 512‑dim float: NDCG@10 = 0.3628 (AWS reported p = 0.87 vs 1024); p50 = 25 ms; index = 2.79 GiB.
  • 1024‑dim binary: NDCG@10 = 0.3438 (−5.2%); p50 = 22 ms; index = 0.40 GiB.
  • 1024 float, on_disk with 32× internal quantization (disk‑efficient mode): NDCG@10 = 0.3610 (−0.5%); p50 = 99 ms; index = 0.40 GiB.

Hybrid search (example weighting: 0.7 semantic / 0.3 lexical) improved ranking quality on the product dataset to NDCG@10 = 0.3850, roughly +6.0% versus semantic‑only. That pattern, hybrid recovering precision lost to quantization or binarization, matters if keyword relevance and filtering are part of your UX.

Amazon S3 Vectors, elastic scale and cost focus

S3 Vectors targets massive, budget‑sensitive corpora. AWS tested Wikipedia subsets (Titan Text Embedding v2, 1024 dims, ~300 token chunks) and reported sub‑second medians even up to ~1M vectors. Latencies exclude embedding generation:

  • ~5K vectors: p50 = 82 ms; p95 = 180 ms; p99 = 220 ms.
  • ~250K vectors: p50 = 205 ms; p95 = 416 ms; p99 = 527 ms.
  • ~500K vectors: p50 = 266 ms; p95 = 386 ms; p99 = 479 ms.
  • ~1M vectors: p50 = 294 ms; p95 = 395 ms; p99 = 506 ms.

AWS reports up to 90% lower vector storage cost compared with “traditional vector databases.” Treat that as a vendor figure and validate it against your TCO. Storage savings alone won’t capture indexing cost, query cost, egress, or engineering operational overhead.

Amazon Aurora PostgreSQL + pgvector, relational joins with balanced latency

Aurora with pgvector stands out because it supports relational joins, ACID semantics, and the SQL ecosystem. That matters when retrieved vectors must be joined to metadata, ACLs, or transactional records. In a 500K‑chunk knowledge base test (1024‑dim embeddings):

  • HNSW: p50 = 31.91 ms; p95 = 38.20 ms; p99 = 89.00 ms.
  • IVFFlat: p50 = 35.94 ms; p95 = 42.38 ms; p99 = 94.08 ms.

These medians are sub‑50 ms and show Aurora can be competitive while keeping the relational model intact. The reported latencies were measured against warmed provisioned instances via the RDS API. If your workload performs heavy joins or returns large payloads, expect the numbers to shift.

How to map needs to a backend (practical guidance)

  • Speed + hybrid relevance + faceted filters: OpenSearch. Consider 512‑dim floats as a cost/latency sweet spot; test binary or on_disk if index footprint is a hard constraint but validate quality.
  • Relational joins, metadata, transactional workflows: Aurora + pgvector. Use HNSW for lower median latency; IVFFlat if memory is the bottleneck and you can tolerate different tail behavior.
  • Massive scale, research, low storage cost: S3 Vectors. Good for offline agents, large corpora, and archival search where sub‑second latency is acceptable.
  • Tiering: a common architecture is S3 Vectors for the cold/full corpus, with hot subsets promoted to OpenSearch (speed) or Aurora (relational access) as needed.

Practical knobs and what to test

  • Dimensionality sweep: compare 1024 → 512 → 256 dims. 512 sometimes matches 1024 quality at lower footprint (observed on the product dataset), but results are dataset‑dependent.
  • Quantization / binarization: reduces index size dramatically (e.g., 5.34 GiB → 0.40 GiB in the OpenSearch tests) but can reduce NDCG. Hybrid fusion can recover some quality.
  • Index algorithm: HNSW gives lower median latency and is a good starting point. IVFFlat lowers memory at the cost of different tail behavior, measure p99 if latency SLOs matter.
  • Hybrid weight tuning: the AWS example used 0.7 semantic / 0.3 lexical. Tune this on a held‑out relevance set. More lexical weight helps exact queries and filtering; too much can hurt pure semantic matches.
  • Concurrency and tail latency: test at your expected QPS and concurrency. OpenSearch reported p50 at concurrency 10 for several configs; S3 Vectors results were run without heavy concurrency reporting in the published numbers.

Operational trade‑offs to budget for

  • Cold start & warm‑up: serverless collections and DB instances have warm‑up characteristics. AWS warmed Aurora nodes for ≥15 minutes in the benchmark, plan for similar behavior in production.
  • Index updates: online incremental updates differ across systems. OpenSearch supports more real‑time indexing and filtering semantics; S3 Vectors targets batch/elastic workloads where rebuild or staged updates are common.
  • Security & governance: evaluate RBAC, encryption, audit logs, and multi‑tenant isolation for each service in your regulatory context.
  • Cost of ownership: storage is only one line item. Include ingestion compute, query costs, cross‑region replication, and engineering time to tune indexes and promotion pipelines.
  • Promotion pipeline: if you tier (S3 → OpenSearch/Aurora), build automated export/import with warm‑up steps and measure promotion latency.

Run these experiments in your environment (short checklist)

  • Baseline: embed your full corpus with your chosen embedding model and measure NDCG@k (k=5 or 10) on a realistic query set.
  • Dimensional sweep: run indexes at 1024, 512, 256 and compare NDCG, index size, and p50/p95/p99 under production concurrency.
  • Quantization & binary tests: measure size vs quality trade‑offs and test hybrid fusion to recover ranking.
  • Index‑type sweep: test HNSW vs IVFFlat (or provider equivalents) and record tail behavior for your QPS.
  • Cold‑start and promotion: simulate promotion of hot subsets from S3 to OpenSearch/Aurora and measure warm‑up time until SLOs meet production targets.

Operational example patterns

  • E‑commerce search: full product corpus in S3 Vectors for analytics; hot SKUs and user‑facing indexes in OpenSearch with hybrid search and faceted filters.
  • Internal research agent: S3 Vectors for the full document pool; background retriever jobs feeding summaries into a smaller OpenSearch index for faster exploratory queries.
  • Customer support chatbot: Aurora for knowledge base with metadata joins (policies, permissions), HNSW for fast retrieval; cold content archived to S3 Vectors.

Key takeaways, questions you’d ask

  • Which backend gives the fastest median retrieval for product search?

    Amazon OpenSearch Service showed median latencies in the low tens of milliseconds (p50 ≈ 22-31 ms depending on embedding type) and hybrid search improved ranking quality by about 6% versus semantic‑only on the tested product dataset (AWS benchmarks).

  • Can I shrink index size without wrecking quality?

    Yes, but test first. AWS found binary embeddings and on_disk quantization produced large size reductions (e.g., 5.34 GiB → 0.40 GiB) with modest NDCG loss; hybrid search helped recover quality on the product tests. Your mileage will vary by corpus and embedding model.

  • What if I need millions of vectors but can tolerate higher latency?

    Amazon S3 Vectors scales to tens of millions of vectors and AWS reports up to 90% lower storage cost versus traditional vector DBs; median query times were under ~300 ms at ~1M vectors in the published tests. Treat the cost claim as a vendor figure and validate with a TCO calculation that includes query, egress, and operational costs.

  • When should I use Aurora with pgvector?

    Use Aurora when you must join vector results with relational data or need transactional features. AWS’ benchmark on a 500K‑chunk knowledge base showed HNSW median ~32 ms, competitive while preserving SQL semantics.

  • Are these numbers a definitive head‑to‑head?

    No. AWS explicitly states the workloads were tailored to each database rather than a single shared dataset. The published figures illustrate trade‑offs; you should run equivalent tests on your corpus and embedding model before deciding.

“The right vector store is ultimately the one that best fits your workload’s latency, cost, and retrieval quality requirements.”, AWS benchmarking team

Final, practical note

Think of vector stores as a budget allocation decision: where do you want to spend latency, storage, and engineering effort? Start with a clear SLA, run the five experiments above on your data, and plan for a tiered path, S3 Vectors for capacity, OpenSearch for speed and hybrid relevance, Aurora when relational joins matter. Those trade‑offs decide whether your RAG system is useful and economical or frustrating and expensive.

0