Which AWS Store Can Do Vector Search

Update, 6 August 2026. DynamoDB shipped native vector search on 5 August 2026, generally available in every commercial Region, the AWS GovCloud (US) Regions and the China Regions. This post originally called it the one store on the list that could not do vector search at all. The landscape, the table, the diagram and the takeaways below have been rewritten around what it actually does. The limits that replaced the old blanket one are narrower and sharper: DynamoDB is not a Bedrock Knowledge Bases target, its inline filters match on equality only, and it does no hybrid keyword-plus-vector retrieval.

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 nearly all of those can run vector search directly once a feature, a plugin, or an extension is turned on.

So the question is narrower than “which vector store”. 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 switches differ more than the feature lists suggest. One engine takes an index setting, one takes a SQL extension, and several take a store type you choose at creation and cannot change afterwards.

What actually matters

Several storage engines have grown vector search as a feature of the engine. Each holds a float[] per row, builds an approximate-nearest-neighbourANNIndex structures (HNSW graphs, IVF partitions) that answer the k-nearest-neighbours question fast by giving up guaranteed exactness – recall becomes a tunable knob rather than a certainty. index over those arrays, and answers “closest k to this query vector” quickly. They differ in how the capability is exposed and what you have to do to turn it 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 several it is a store type chosen when the store is created, and changing your mind later means creating another one. Knowing which category an engine falls into tells you whether “we already run this” means a five-minute index change or a fresh deployment.

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 fork decides 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 carries less risk than a new one. 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 query surface, and this is where the engines separate most sharply. Almost all of them use HNSWHNSWA graph-based vector index that walks neighbour links to find close vectors fast, at the cost of extra memory per vector. or something like it underneath, and the distance metric must match the embedding model that produced the vectors, because getting cosine-versus-inner-product wrong wrecks recallRecall (retrieval)The share of genuinely relevant passages a search actually returns – what you lose when you retrieve fewer chunks. without raising an error. Metadata filtering and hybrid keyword-plus-vector search are the capabilities that vary, and on several engines that variation decides the pick outright.

What we’ll filter on

1. Native capability, is vector search a built-in feature, a plugin or extension, or a store type you create?
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, range conditions, and hybrid keyword-plus-vector search?
5. Operational fit, is it an engine the team already runs and understands?

The landscape

Amazon OpenSearch Service (managed domain). This is the “OpenSearch with plugins” case. The k-NNk-NNThe retrieval question itself: given a query vector, return the k closest vectors under the index’s distance metric – answered exactly by comparing against everything, or quickly by an ANN index. 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. Operating the domain is what that takes: shard sizing, instance sizing, graph memory headroom, version upgrades.

There is a second switch on the domain, and it changes the design more than any index setting does. From engine version 2.9, Amazon OpenSearch Service can register a Bedrock embedding model as an AI connector inside the domain and attach it to an ingest pipeline. OpenSearch then calls the embedding model itself, at index time and again at query time. A client then sends raw text in a neural query and gets nearest neighbours back, rather than computing a vector first and posting the array. That moves where the embedding model lives. It becomes a property of the index rather than of every caller. Drift between the model that wrote the vectors and the model that reads them cannot happen, and a second application searching the same corpus needs none of the embedding code. Without it, every writer and every reader has to agree on the model and the dimension by convention, and a convention is documented rather than enforced. Three consequences come with it. The domain needs outbound access to Bedrock and an IAM role for the connector, index throughput now inherits the embedding model’s throttling limits, and swapping the model still means a reindex. This Amazon Bedrock integration carries the more advanced vector database architectures. It also makes topic-based segmentation practical: several indexes, each scoped to a topic with its own embedding model and chunking, all queried through the same plain-text call.

Neural search has a sparse counterpart. A sparse encoder runs in place of a dense embedding model, producing weighted term expansions. It drops into the same hybrid pipeline beside the normalization-processor when a corpus carries vocabulary that dense embeddings blur: part numbers, drug names, internal codenames. A Bedrock Knowledge Base arranges the same work differently: the embedding model is configured once on the Knowledge Base, which calls Bedrock and writes the vectors, so the store behind it never needs a connector of its own.

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. Search and time-series collections cannot hold k-NN indexes, and the type is fixed once the collection exists. Capacity is a minimum and maximum OCU count, set separately for indexing and for search, and the minimum can be zero, so an idle collection scales all the way down. It is one of four stores Bedrock will create for you in the Knowledge Base quick-create flow, and the one the console offers first.

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 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. Source documents usually stay in S3, with each row holding the vector, the metadata, and the object key that points back at the original. Aurora PostgreSQL is a Knowledge Base target, and Aurora PostgreSQL Serverless is one of the quick-create options. Bedrock needs pgvector 0.5.0 or later, the RDS Data API enabled, and a Secrets Manager secret for the database user. Amazon RDS for PostgreSQL runs pgvector just as well, but it is not on the Knowledge Base list, so ingestion there is yours.

Amazon DocumentDB. The Mongo-compatible store has native vector search on 5.0 and later instance-based clusters. You create an index with a vector type, choosing hnsw or ivfflat, the number of dimensions, and a similarity of euclidean, cosine, or dotProduct. Queries go through the $search aggregation stage. Indexes cap at 2,000 dimensions, though up to 16,000 can be stored unindexed, so check the embedding model against that ceiling first. The pick when the application already speaks the MongoDB API and you would rather not stand up a second engine.

Amazon MemoryDB and ElastiCache for 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 on MemoryDB, or microseconds on ElastiCache for Valkey, which gained the feature in engine version 8.2. MemoryDB adds durability a cache does not have. Its vector search runs on a single shard, so it scales vertically and to replicas but not horizontally. 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). The vector index can only be created when the graph is created, there is one per graph, and its dimension is fixed at that moment, so the embedding model is a decision you make before any data lands. Its reason to exist here is GraphRAG: when retrieval needs 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 its own query API: up to 4,096 dimensions, cosine or Euclidean, and up to two billion vectors in a single index. Queries land in under a second, and as low as 100 milliseconds once they are frequent enough to stay warm. 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 DynamoDB. A vector index is declared on the table itself, through the VectorIndexes parameter of CreateTable or VectorIndexUpdates on UpdateTable, over an attribute holding the embedding. You set the dimension count (up to 4,096), the distance function (COSINE, EUCLIDEAN, or DOT_PRODUCT, fixed thereafter), and a projection. Reads go through SearchVectors, which returns up to 100 results ranked by score; Query, Scan, PartiQL and DAX do not read the index at all. An optional SearchSchema adds one partition key, scoping each search to a subset of the vectors, and up to 18 inline filter attributes that match on equality only. Both the index and the base table must use on-demand capacity, and indexing runs asynchronously after the write, so a vector becomes searchable a little after the item does.

What DynamoDB does not do is where a design decision usually turns. There is no hybrid keyword-plus-vector retrieval, no range or set-membership filtering, and DynamoDB is not a Bedrock Knowledge Bases target, so ingestion is yours to write. Pairing it with a separate vector store stays the answer when any of those three matters. The item and its attributes live in DynamoDB, and the zero-ETL integration to OpenSearch Service streams changes into an index where the k-NN plugin does the search.

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 wire into a RAG flow, not a raw vector store you control the index of. It went into maintenance mode on 30 June 2026 and closed to new customers on 30 July 2026, so it is only an option for an account that already runs an index. Existing indexes keep working and keep getting bug fixes and security updates, and AWS points new builds at a Bedrock managed knowledge base instead. When you want retrieval as a managed black box rather than a vector index you tune, that managed knowledge base is now where to look.

Evaluation

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; AI connector to embed in-domain	✓	max query flexibility, hybrid, you run a domain
OpenSearch Serverless	native (collection type)	create a VECTORSEARCH collection	✓	managed default, capacity scales to zero
Aurora PostgreSQL	an extension	CREATE EXTENSION vector	✓	relational metadata, SQL-native team
RDS for PostgreSQL	an extension	CREATE EXTENSION vector	✗	same, where managed ingestion is not wanted
DocumentDB	native feature	vector index (hnsw/ivfflat), 2,000 dims max	✗	app already on the MongoDB API
MemoryDB / ElastiCache for Valkey	native feature	VECTOR field in a search index	✗	hot, small, latency-critical corpus
Neptune Analytics	native feature	vector index, at graph creation only	✓ (GraphRAG)	vectors plus graph relationships
S3 Vectors	native (bucket type)	a vector bucket + index	✓	huge, cold, cost-sensitive archive
DynamoDB	native feature	vector index on the table, read by SearchVectors	✗	embeddings beside the operational item

Routing by what you already run

The solution

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 set an OCU floor and ceiling than plan shards, which is why the Knowledge Base quick-create flow reaches for 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 needs maintenance_work_mem raised, so schedule it off-peak. Aurora PostgreSQL gets the managed ingestion pipeline as well; RDS for PostgreSQL gets the same SQL and none of the pipeline.

DocumentDB and MemoryDB. Both of these save you 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 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, and a single shard is as wide as its vector search gets. 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 has 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. Outside those niches, one adds graph machinery nothing queries, and the other adds most of a second to every interactive answer.

DynamoDB, said plainly. The native index is the shortest path when the embedding belongs next to the item that produced it: one table, one write, one API, and no replication pipeline to keep in step. On-demand capacity is a requirement rather than a default you can change, and the index lags the table by a moment on every write. Reach past it when retrieval needs keyword matching alongside similarity, a range filter, or Bedrock’s managed ingestion. Pairing DynamoDB with a vector store remains a deliberate split. DynamoDB is the durable record and the vector store is the index. The zero-ETL integration to OpenSearch Service keeps the two aligned, taking an initial snapshot through export to S3 and then following DynamoDB Streams.

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 setting (index.knn), pgvector is an extension, DocumentDB and MemoryDB and Neptune Analytics and DynamoDB are native index types, and OpenSearch Serverless and S3 Vectors are store types you create.
3. Bedrock Knowledge Base integration decides how much you build. OpenSearch (both), Aurora PostgreSQL, Neptune Analytics, and S3 Vectors get a managed ingestion pipeline; DocumentDB, MemoryDB, RDS for PostgreSQL, and DynamoDB mean you own the embed-and-write loop.
4. Hybrid keyword-plus-vector search and range filtering narrow the list fastest. Needing either sends a design to OpenSearch or pgvector, whatever else is already running.
5. Several choices are permanent. The OpenSearch Serverless collection type, the Neptune Analytics vector index and its dimension, and the DynamoDB distance function are all fixed when the store is created.
6. The distance metric must match the embedding model on every one of these. A cosine-for-inner-product mismatch destroys recall without raising an error.

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. All three are defensible for the same reason: the vector index rode in on an engine the team already runs. Almost every engine on the list answers the nearest-neighbour query now. Where each one stops, at hybrid retrieval, at range filters, at who owns ingestion, is what settles the pick.