Which AWS Store Can Do Vector Search

The situation

The retrieval side of a Bedrock assistant needs somewhere to hold a few million embeddings and answer nearest-neighbour queries against them. The instinct is to reach for a dedicated vector database and compare pricing, and that comparison has its place. But most teams walk into this already operating three or four data stores, and several of those can run vector search directly once a feature, a plugin, or an extension is turned on.

So the real question is narrower than “which vector store”. It is: given the engines already in the account, which one becomes a vector storeVectorAn ordered list of numbers – in AI usage, almost always an embedding – and by extension the databases that index them for nearest-neighbour search. with the least new surface area, and what exactly do you switch on to get there. The trap is assuming a store supports vectors because it is popular and managed. DynamoDB is the one everybody reaches for; it is also the one that cannot do this at all.

What actually matters

Vector search is not a separate product category so much as a capability that several storage engines have grown. The engine holds a float[] per row, builds an approximate-nearest-neighbour index over those arrays, and answers “closest k to this query vector” quickly. What differs is not whether the engine can do it, but how the capability is exposed and what it costs you to switch on.

The first thing that matters is the shape of the switch. On some engines vector search is a native, first-class feature you configure at index-creation time. On others it is a plugin or extension you install, then an index setting you flip. On a couple it is nothing at all, and no amount of configuration will change that. Knowing which category an engine falls into is most of the battle, because it tells you whether “we already run this” means “we are five minutes from a vector index” or “we need a different engine”.

The second is whether Bedrock Knowledge Bases can drive the store for you. A Knowledge Base handles chunking, embedding, and upsert, but only against the vector stores it integrates with. If you pick a store off that list, the ingestion pipeline is managed. If you pick one that is not, you own the embed-and-write loop yourself. That is a real fork in how much you build, and it often outweighs the raw engine comparison.

The third is the operational gravity you already have. An engine your team runs, patches, monitors, and reasons about is worth a lot. The vector index rides on top of infrastructure you already trust, and the query language is one your team already speaks. This is why “which store can do it” so often collapses into “which store are we already good at”, and why the same corpus lands on OpenSearch at one shop and pgvector at another.

The fourth is the algorithm and the query surface, and here the engines converge more than they differ. Almost everything uses HNSWHNSWA graph-based vector index that walks neighbour links to find close vectors fast, at the cost of extra memory per vector. under the hood; the distance metric must match the embedding model that produced the vectors, and getting cosine-versus-inner-product wrong quietly wrecks recallRecall (retrieval)The share of genuinely relevant passages a search actually returns – what you lose when you retrieve fewer chunks. . Filtering and hybrid keyword-plus-vector support vary, but they are second-order next to the enablement question.

What we’ll filter on

1. Native capability, is vector search a built-in feature, a plugin or extension, or absent?
2. What you actually enable, the concrete switch, index type, or CREATE EXTENSION that turns it on.
3. Bedrock Knowledge Base integration, can a managed pipeline write to it, or do you own ingestion?
4. Query surface, does it support metadata filtering and hybrid keyword-plus-vector search?
5. Operational fit, is it an engine the team already runs and understands?

The vector-capable landscape

Amazon OpenSearch Service (managed domain). This is the “OpenSearch with plugins” case. The k-NNNearest-neighbour searchFinding the vectors closest to a query vector; at scale it’s approximated, trading a little accuracy for a lot of speed. plugin ships with the service; you enable vectors per index by setting "index.knn": true, then declaring a field of type knn_vector with its dimension and a method (hnsw on the FAISS or Lucene engine, or ivf). Metadata filtering is efficient with Lucene or FAISS filtering, and hybrid searchHybrid searchRunning a keyword match alongside a vector search and fusing the two rankings, so exact identifiers survive that meaning-based search would blur away. is a first-class feature through a search pipeline with a normalization-processor. It is the most capable surface on this list and the one to pick when retrieval quality and query flexibility matter most, at the cost of running a domain (or paying the OpenSearch Serverless floor).

Amazon OpenSearch Serverless. Same engine, different packaging. There is no plugin toggle; you create a collection of type VECTORSEARCH and it is a vector store by definition. You trade the domain’s capacity planning for a two-OCU minimum. This is the default target for a Bedrock Knowledge Base when nobody specifies otherwise.

Aurora and RDS for PostgreSQL (pgvector). Postgres becomes a vector store the moment you run CREATE EXTENSION vector;. You then store a vector(n) column, build an HNSW or IVFFlat index, and query with the distance operators (<=> cosine, <#> inner product, <-> L2). Metadata filtering is just a WHERE clause the planner pushes down, and hybrid search means combining pgvector with Postgres full-text search and ranking the two yourself. The pick when the metadata is relational and the team lives in SQL. Aurora PostgreSQL is also a Knowledge Base target, so a managed pipeline can drive it.

Amazon DocumentDB. The Mongo-compatible store grew native vector search: you create an index with a vector type, choosing hnsw or ivfflat, the number of dimensions, and a similarity of euclidean, cosine, or dotProduct, then query with the $search aggregation stage. The pick when the application already speaks the MongoDB API and you would rather not stand up a second engine.

Amazon MemoryDB and ElastiCache (Redis/Valkey). In-memory vector search. You create a search index with a VECTOR field, HNSW or FLAT, and query for nearest neighbours in single-digit milliseconds. MemoryDB adds durability that plain ElastiCache does not. The pick for a hot, latency-critical corpus small enough to hold in RAM; memory is the ceiling, and at tens of millions of vectors it gets expensive.

Neptune Analytics. The graph analytics engine stores vectors alongside the graph and runs similarity search over them (load embeddings, then query top-kTop-kHow many chunks a retrieval step returns per query – the dial that trades answer coverage against token cost. by embedding). Its reason to exist here is GraphRAG: when retrieval wants to combine semantic similarity with graph relationships, Neptune Analytics does both, and Bedrock Knowledge Bases can target it for exactly that.

Amazon S3 Vectors. Vectors stored natively in a purpose-built S3 bucket type with a query API, priced for scale, latency measured in sub-second rather than sub-millisecond. Not the shape for an interactive assistant’s hot path, but the right home for a very large, cold, cost-sensitive archive, and a supported Knowledge Base target.

Amazon Kendra. Worth naming so it is placed correctly. Kendra is a managed intelligent-search service that does its own chunking, embedding, and semantic ranking internally; you point it at connectors and query it. It is a retriever you can wire into a RAG flow, not a raw vector store you control the index of. Reach for it when you want retrieval as a managed black box rather than a vector index you tune.

Amazon DynamoDB. The trap. DynamoDB has no vector index and no nearest-neighbour query, and no setting enables one. “DynamoDB with vector search turned on” does not exist. What does exist are two adjacent patterns that get mistaken for it. The first is DynamoDB as the source-of-truth or metadata store sitting beside a real vector store: the document text and attributes live in DynamoDB, the embeddings live in OpenSearch. The second is the zero-ETL integration from DynamoDB to OpenSearch Service, which streams items into OpenSearch, where the k-NN plugin does the actual vector work. In both cases the vectors are searched in OpenSearch. If a scenario offers “enable vector search on DynamoDB” as an option, it is the distractor.

Side by side

Store	Vector search is	What you enable	Bedrock KB target	Best when
OpenSearch Service (domain)	a plugin	index.knn: true + knn_vector field	✓	max query flexibility, hybrid, you run a domain
OpenSearch Serverless	native (collection type)	create a VECTORSEARCH collection	✓	managed default, no capacity planning
Aurora / RDS PostgreSQL	an extension	CREATE EXTENSION vector	✓	relational metadata, SQL-native team
DocumentDB	native feature	vector index (hnsw/ivfflat)	✗	app already on the MongoDB API
MemoryDB / ElastiCache	native feature	VECTOR field in a search index	✗	hot, small, latency-critical corpus
Neptune Analytics	native feature	load embeddings, similarity query	✓ (GraphRAG)	vectors plus graph relationships
S3 Vectors	native (bucket type)	a vector bucket + index	✓	huge, cold, cost-sensitive archive
Kendra	managed retriever	index + connectors (not a raw store)	n/a (is the retriever)	retrieval as a managed black box
DynamoDB	not supported	nothing, pair it or zero-ETL to OpenSearch	✗	never the vector store itself

Routing by what you already run

The picks in depth

OpenSearch, domain versus serverless. The engine is the same; the question is who plans capacity. Run a managed domain when you already operate OpenSearch for logs or search, want the fullest query surface (Lucene filtering, hybrid pipelines, fine k-NN tuning through m, ef_construction, and ef_search), and can size shards and instances. Take Serverless when you would rather pay the two-OCU floor than plan capacity, which is why a Bedrock Knowledge Base defaults to it. Both do pre-filtered metadata search well, which keeps recall high when a filter is selective.

pgvector on Aurora or RDS. The extension turns any Postgres into a vector store, and the appeal is that the vector column, the metadata columns, and the transactional data share one query, one plan, and one backup. Build the HNSW index deliberately: on millions of rows it takes time and wants maintenance_work_mem raised, so schedule it off-peak. Because Aurora PostgreSQL is a Knowledge Base target, you can get the managed ingestion pipeline and SQL-native querying at once.

DocumentDB and MemoryDB. These earn their place by removing an engine rather than adding one. If the application already runs on DocumentDB, a vector index there is one fewer system to operate, and the same holds for a Redis or Valkey cluster you already run for caching. MemoryDB’s in-memory speed is real, and so is its cost ceiling: a corpus that outgrows RAM outgrows this option. Neither is a Bedrock Knowledge Base target today, so you own the embed-and-upsert loop.

Neptune Analytics and S3 Vectors. Both are narrow-purpose picks. Neptune Analytics is for GraphRAG, where a plain nearest-neighbour result is not enough and the retriever wants to walk relationships from the matched nodes. S3 Vectors is for scale and thrift, where the corpus is enormous, mostly cold, and a sub-second query is acceptable. Reaching for either outside its niche means paying for a capability the workload does not use, or missing the latency the workload needs.

DynamoDB, said plainly. It stores the documents and their attributes beautifully and answers key lookups in single-digit milliseconds, and it will never answer a nearest-neighbour query. When a design pairs DynamoDB with a vector store, the split is deliberate: DynamoDB is the durable record, the vector store is the index. The zero-ETL integration to OpenSearch Service automates keeping that index fresh, streaming item changes into OpenSearch where the k-NN plugin does the search. Read any “enable vector search on DynamoDB” option as the wrong answer.

What’s worth remembering

1. Vector search is a capability several engines grew, not a product you must buy separately. Ask what the engines already in the account can do before adding one.
2. Know the shape of the switch. OpenSearch Service is a plugin (index.knn), pgvector is an extension (CREATE EXTENSION vector), DocumentDB and MemoryDB and Neptune Analytics are native features, OpenSearch Serverless and S3 Vectors are store types you create.
3. DynamoDB cannot do vector search, and nothing enables it. Pair it with a vector store, or zero-ETL it into OpenSearch. “Turn on vectors in DynamoDB” is always the distractor.
4. Bedrock Knowledge Base integration is a real fork. OpenSearch (both), Aurora PostgreSQL, Neptune Analytics, and S3 Vectors get a managed ingestion pipeline; DocumentDB and MemoryDB mean you own the embed-and-write loop.
5. OpenSearch is the most flexible surface: hybrid search, efficient filtering, tunable k-NN. Take the domain when you run one, Serverless when you would rather not plan capacity.
6. pgvector wins when metadata is relational and the team is SQL-native, and it keeps everything in one engine, one plan, one backup.
7. DocumentDB and MemoryDB are the “one fewer engine” picks, chosen because the app already runs on them, not on their own merits.
8. Neptune Analytics is for GraphRAG and S3 Vectors is for huge cold archives. Both are narrow; using them off-niche costs latency or money.
9. Kendra is a managed retriever, not a raw vector index. Pick it when you want retrieval as a black box rather than an index you tune.
10. The distance metric must match the embedding model on every one of these. Cosine-versus-inner-product mismatches silently destroy recall regardless of which engine you enabled.

The corpus that lands on OpenSearch at a log-heavy shop lands on pgvector at a Postgres shop and on DocumentDB at a Mongo shop, and all three are defensible for the same reason: the vector index rode in on an engine the team already runs. The one answer that is never defensible is enabling vector search on DynamoDB, because there is no switch to throw.