VectorDBs Everywhere: Which to Choose
A practitioner's field guide - August 2026 ~10 min read
Every AWS data service suddenly speaks "vector." Here's how DynamoDB, Aurora pgvector, OpenSearch, and S3 Vectors actually compare, with real pricing, published benchmarks, and a decision guide.
What is a vector database?
A vector database stores data as embeddings, long lists of numbers that a machine learning model produces to capture the meaning of a piece of content, whether that's a sentence, an image, an audio clip, or a user's behavior. Items with similar meaning end up close together in this numeric "vector space," so instead of matching exact keywords, a vector database finds the nearest vectors to a query using similarity search (approximate nearest-neighbor, or ANN). That makes them the backbone of modern AI features: semantic search (results that understand intent, not just keywords), retrieval-augmented generation (RAG) (feeding an LLM the most relevant context from your own data), recommendation engines, personalization, AI-agent long-term memory, and anomaly or fraud detection. The catch is that you don't generate the embeddings in the database, you produce them with a model (e.g. Amazon Titan, Cohere, or OpenAI) and store them for fast similarity lookups. The rest of this post is about where to store them.
TL;DR
- Already on DynamoDB? Its new native vector search (GA Aug 5, 2026) lets you skip a second database entirely, serverless, single-digit-ms, trillions-of-vectors scale.
- Need rich SQL filters + lowest cost at small/mid scale? Aurora PostgreSQL with
pgvector, under $50/month for most RAG workloads. - Need hybrid keyword + vector, faceting, sub-100 ms SLOs? OpenSearch is still the gold standard, but you pay a floor (~$175–$700+/mo).
- Cold-path / write-heavy / cost-obsessed? S3 Vectors is the new cheap default (~$5–$36/mo at real workloads), if you can tolerate 100–300 ms p95.
Two years ago, "add vector search" meant standing up a dedicated vector database and building a sync pipeline to feed it. In 2026 the opposite is true: your operational database, your object store, and your search engine all do vectors natively. The question is no longer "which vector DB do I bolt on?" but "which system I already run should own my vectors?"
This post walks through the four AWS options teams actually weigh against each other, what each is genuinely good at, and, most importantly, what each costs.
The contenders
1. DynamoDB Vector Search (New, GA Aug 2026)
DynamoDB now stores embeddings as a standard List-of-Numbers attribute and runs approximate-nearest-neighbor search via a new
SearchVectors API, no separate store, no sync pipeline. AWS quotes single-digit-millisecond latency at 99%+ recall, scaling to trillions of vectors. Fully serverless, pay-per-request.- Up to 4,096 dimensions; Cosine, Euclidean, Dot-product distance
- Inline filters, equality only (no ranges/BETWEEN/IN yet)
- Top-K up to 100; max 5 vector indexes per table; on-demand capacity only
- Works with Global Tables (index auto-replicates), PITR, Streams, not DAX
2. Aurora PostgreSQL + pgvector (Cost champ)
The pragmatic favorite. A Postgres extension that adds a
vector type with HNSW/IVFFlat indexes. You get the entire SQL surface, joins, ranges, arbitrary WHERE, hybrid queries, alongside similarity search. Community benchmarks put it at ~1.5 ms / 98–100% recall at 1M vectors with tuning (defaults can drop to 55–83% recall, so tune it).3. OpenSearch (Service / Serverless) (Search quality)
The purpose-built search engine. Best-in-class hybrid search (BM25 keyword + vector fusion), rich filtering, faceting, aggregations, and GPU-accelerated billion-scale indexing. ~100% recall, ~2.7 ms, high QPS. The catch is a cost floor and cluster/collection management.
4. S3 Vectors (Cheapest, slower)
Amazon's newest entrant, GA in 2025: vectors stored directly in S3 and priced on a fully consumption-based model. It reset the cost-performance frontier for vector search, but it's a pure vector store, so you trade features and latency for radical cheapness.
S3 Vectors, in depth
What it is: A native S3 capability that stores vectors as objects and exposes a managed ANN index over them via
s3vectors: APIs. No cluster, no instances, you pay for storage, writes, queries, and data processed.Where it wins:
- Cost, by a wide margin, on real workloads it comes in 15–66x cheaper than an OpenSearch Serverless baseline. First-month minimum can be as low as ~$0.60 (10 GB, no queries).
- Write-heavy & long-tail archives, AI-agent long-term memory, offline clustering, feedback/ticket analysis, historical reference corpora.
- Massive fan-out, up to 2 billion vectors per index, 10K indices per bucket (~20T per bucket); great for multi-tenant / multi-region.
Where it hurts:
- Latency: managed ANN over S3 gives p95 in the 100–300 ms range, fine for batch/cold-path, wrong for a 100 ms hot path.
- Pure vector only: no BM25, no tokenization, no full-text fusion, no GraphRAG topology. If you need hybrid, you're on OpenSearch.
- Metadata limits: 40 KB total per vector, but only 2 KB / 50 keys filterable. Long payloads must be truncated to summaries.
- Throughput caps: 1,000 req/s, max 500 vectors/batch, 2,500 vectors/s aggregate.
- Migration trap: cosine ordering is opposite OpenSearch, S3 Vectors returns distance (lower = closer, range 0–2); OpenSearch returns a relevance score (higher = closer). Any tuned
min_scorefilter will silently invert recall unless renormalized.
S3 Vectors price components (us-east-1): Storage $0.06/GB-mo, PUT $0.20/logical-GB, Query API $2.50/M calls, Data processing tiered per index ($0.004/TB first 100K vectors, $0.002/TB beyond).
Capability comparison
| Dimension | DynamoDB | Aurora pgvector | OpenSearch | S3 Vectors |
|---|---|---|---|---|
| Model | Serverless NoSQL | Relational (PG ext.) | Search engine | Object store |
| Latency (p95) | Single-digit ms | ~1.5 ms (tuned) | ~2.7 ms | 100–300 ms |
| Recall | 99%+ | 98–100% (tuned) | ~100% | 94–98% |
| Max dimensions | 4,096 | 2,000 (HNSW) | 16,000 | 4,096 |
| Filtering | Equality only | Full SQL | Rich + hybrid | Flat KV <2 KB |
| Hybrid (BM25+vec) | No | Partial | Yes | No |
| Top-K / query | 100 | Unbounded (SQL) | 10,000 | 100 |
| Scale ceiling | Trillions | ~1–5M sweet spot | Billions (GPU) | 2B / index |
| Ops burden | Zero | Medium | Medium–High | Zero |
Published benchmark data
The numbers below come from an independent, reproducible benchmark suite comparing OpenSearch, pgvector, and S3 Vectors on identical hardware and datasets (recall@10, single-query latency, and sustained QPS). DynamoDB's are AWS-published figures for its new vector search, shown for reference, note they aren't from the same test harness, so treat cross-rows as directional.
| Platform | Recall@10 | Latency | QPS | Best for |
|---|---|---|---|---|
| pgvector | 100%* | 1.5 ms | 673 | PostgreSQL integration |
| OpenSearch | 100% | 2.7 ms | 370 | Production, hybrid search |
| S3 Vectors | 94–98% | 134 ms | 7 | Cost-optimized, RAG |
| DynamoDB (AWS-published) | 99%+ | <10 ms | n/a | Operational data + vectors |
*pgvector hit 100% recall only with tuned parameters; defaults achieved just 55–83% recall. DynamoDB QPS not published as a fixed number, it scales horizontally with on-demand capacity. Source: reproducible vector-search benchmark suite (OpenSearch vs pgvector vs S3 Vectors), 2026; DynamoDB figures from the AWS GA announcement.
The part everyone actually cares about: cost
Pricing below is US East (N. Virginia) list pricing as of mid-2026. Vector costs ride on each service's underlying billing model, so here are the rate cards first, then a modeled workload.
Rate cards
| Service | How you're billed | Key rates |
|---|---|---|
| DynamoDB (on-demand) | Per request + storage | Writes $0.625/M WRU, Reads $0.125/M RRU, Storage $0.25/GB-mo |
| Aurora pgvector (Serverless) | Per ACU-hour + storage | ~$0.12/ACU-hr, scales down when idle, <$50/mo typical RAG |
| OpenSearch Serverless | Per OCU-hour (floor) | 1-OCU dev ~$175/mo, 2-OCU HA ~$350/mo, Bedrock KB floor ~$700/mo |
| S3 Vectors | Storage + PUT + query API | Storage $0.06/GB-mo, PUT $0.20/GB, Query $2.50/M calls |
Modeled workload: 10M vectors (1,536-dim), 1M queries/month
A typical small/medium RAG or semantic-search deployment. Approximate monthly cost:
| Service | Est. monthly cost | Notes |
|---|---|---|
| S3 Vectors | ~$11 | Storage $3.54 + PUT $1.97 + API/processing $5.87. Cold-path king. |
| Aurora pgvector (Serverless) | ~$45 | Scales down when idle; ~90% cheaper than the AOSS floor. |
| DynamoDB Vector | ~$50–90 | Depends on query/write mix; no floor, scales to near-zero at rest. |
| OpenSearch Serverless (1 OCU) | ~$175 | Dev config floor, before this workload's real OCU sizing. |
| OpenSearch Serverless (2-OCU HA) | ~$350 | Production HA baseline across two AZs. |
DynamoDB vector-search pricing rides its standard on-demand request + storage rates; the range reflects query volume and item size. Verify all figures against the live AWS pricing pages and Pricing Calculator before budgeting.
> The crossover isn't a single index size, it's the point where a capacity-priced engine (OpenSearch OCUs), sized to your real working set, costs less than the per-query bill of a consumption-priced store. For hot-path, high-QPS workloads that point arrives fast. For cold-path or batch, it never does.
What happens at 400M vectors?
At the medium/large end (400M vectors, 10M queries/mo), S3 Vectors runs about $1,217/month. OpenSearch's 2-OCU minimum can't physically hold 400M vectors (~50M per OCU is the rule of thumb); sized realistically at 8–16 OCUs it lands at $1,400–$2,800/month. So the cheap-vs-premium gap narrows dramatically at scale, the deciding factor becomes latency and hybrid-search needs, not raw storage cost.
Decision guide: which one for your workload?
Run your workload down these priority-ordered checks. Stop at the first "yes."
- Need hybrid keyword + vector search (BM25), faceting, or GraphRAG? → OpenSearch / AOSS
- Is your operational data already in DynamoDB? → DynamoDB Vector Search
- Need p95 < 200 ms or rich SQL filtering (ranges, joins)? → Aurora pgvector
- Cold-path / batch / write-heavy and cost is the priority? → S3 Vectors
- None of the above? → Default to Aurora pgvector, the cheapest sane default at <5M vectors.
How to choose (summary)
| If your priority is… | Choose | Why |
|---|---|---|
| Data already in DynamoDB; agentic memory / RAG at scale; zero ops | DynamoDB | No second database, no sync pipeline, trillions-scale |
| Rich relational filtering + lowest cost at <5M vectors | Aurora pgvector | Full SQL, HNSW, ~$45/mo, first-class Bedrock KB support |
| Hybrid keyword+vector, faceting, sub-100 ms SLOs | OpenSearch | BM25 + vector fusion, tokenization, boolean filters |
| Cold-path, write-heavy, batch, cost-minimized | S3 Vectors | 15–66x cheaper on real workloads; 200–300 ms OK |
The bottom line
The "dedicated vector database" is quietly becoming a feature rather than a product. For the majority of RAG systems, which index under 5M documents, pgvector on Aurora is genuinely fine and the cheapest sane default. If your operational data already lives in DynamoDB, its new native vector search removes an entire system from your architecture. Reserve OpenSearch for when search quality features (hybrid, ranking, aggregations) are the point, and reach for S3 Vectors when the workload is cold and cost is everything.
Pick the database you already operate well. In 2026, it probably does vectors now.
Sources
- Amazon DynamoDB now supports real-time vector search at any scale
- Using vector indexes in DynamoDB
- S3 Vectors vs OpenSearch: Decision Tree from 30+ Projects
- Cutting Bedrock KB costs by 90%: OpenSearch Serverless to Aurora pgvector
- Understanding DynamoDB Pricing (2026)
- Vector search benchmarks: OpenSearch, pgvector, S3 Vectors
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article