You are in an interview or an exam. The prompt reads: “Which AWS services can store embeddings for retrieval augmented generation, and which one would you pick here?” Four service names come to mind, each sounding plausible, and you feel the pull to rank them. That pull is the trap. This article argues that the four AWS vector stores are not competitors to rank. Each one answers a different question about where your data already lives and what shape the query takes. If you read the scenario’s data before you think about products, the right service is usually obvious. It is worth learning because the wrong options in this area are rarely false. They are true statements about the wrong service for the situation, and those are much harder to spot.
The strong answer starts with the data, not the product
Retrieval augmented generation, or RAG, means fetching relevant material from your own sources when a question is asked. That material goes into the prompt, so the model answers from it rather than from memory. The model’s weights, the numbers learned in training, never change.
To retrieve the right passages, each passage is stored as an embedding. An embedding is a list of numbers that places similar meanings close together. A vector store is any database that can hold those embeddings and find the ones nearest to a question’s embedding.
A strong candidate answers in three moves:
- Name the four services that can store embeddings for RAG: Amazon OpenSearch Service, Amazon Aurora, Amazon RDS for PostgreSQL and Amazon Neptune.
- Say that none of them is “the best”.
- Name the signal that selects each one.
That last move is the whole answer. Think of it as choosing a filing cabinet. You put the new folder in the cabinet where the related papers already sit. You do not buy a new cabinet because it has nicer drawers.
The data’s shape and location pick the vector store before any product comparison
Each of the four services answers a different scenario
The four services are easier to hold when each is tied to one sentence a scenario might contain.
Amazon OpenSearch Service is a search and analytics engine with vector search. It fits when search is the main workload, the corpus is large, or the requirement mixes keyword matching with vector similarity. That mix is called hybrid retrieval.
Amazon Aurora is a managed relational database, compatible with PostgreSQL, that can store vectors and run similarity search. It fits when the data is already relational in Aurora and the vectors should sit beside it.
Amazon RDS for PostgreSQL is managed PostgreSQL with vector support. It fits when an organisation already runs PostgreSQL and wants vectors without adopting a new data store.
Amazon Neptune is a graph database. A graph database stores entities and the links between them. Neptune offers vector search alongside graph traversal, so it fits when relationships between entities are part of the answer, not just similarity.
Each vector store is selected by a different phrase in the scenario
Notice that the column on the right never says “fastest” or “cheapest”. The deciding facts are about the existing estate and the shape of the query. A scenario that describes an existing database has usually chosen for you already.
Aurora is a relational database first, which is why it is here
Aurora deserves its own section because candidates often misread it. The current version of the exam guide, v1.1, added it to the list of in-scope services. Study material written for the earlier version may not mention it at all.
The mistake is to assume Aurora must be a purpose-built vector product because it appears in an AI objective. It is not. It is a relational database that can also hold vectors.
The real benefit is that vectors live in the same database as the rows they describe. Take a product’s embedding. It can sit next to that product’s price and stock level, and one query reaches all three. You no longer need a second data store that has to be synchronised, secured, backed up and paid for.
Keeping vectors beside relational rows removes a second store to sync and secure
The pairing to keep straight is Aurora versus RDS for PostgreSQL. Both are compatible with PostgreSQL. The service the organisation already runs decides between them, not any feature of the two products.
Bedrock Knowledge Bases is the managed pipeline around the store
A vector store holds embeddings. It does not, by itself, give you a RAG system. Amazon Bedrock Knowledge Bases is managed RAG: the whole retrieval pipeline offered as a service, so you do not assemble it yourself.
You provide documents in a data source, a choice of embedding model, and either a vector store or a managed default. The service splits documents into passages, embeds each passage, indexes the vectors and keeps the index current. At question time it retrieves passages, assembles the prompt and returns citations.
The signal phrase is “without building a retrieval pipeline.” A scenario that wants grounded answers over its own documents, and does not want to run the plumbing, is pointing at this service. The vector store question still exists inside it, but it becomes a configuration choice rather than a build.
Ingestion runs when documents change; only the question is embedded per request
Follow-up questions, model answers, and the usual slip
An interviewer rarely stops at the first answer. These follow-ups test whether the reasoning holds.
”So which vector database is the best one?”
Model answer: None of them. All four are good products, and the scenario’s existing data and query shape decide. If the scenario gives no signal, say what signal you would need. That might be “Is the data already in PostgreSQL?” or “Do relationships matter?”
The slip: ranking them. Weak candidates pick a favourite and defend it, which shows they have not noticed the question is about fit.
”The data is a graph of suppliers, parts and products. Why not OpenSearch Service?”
Model answer: OpenSearch Service is a fine search engine with vector search, and that description is true. But the requirement says relationships between entities are part of the answer. Graph traversal plus vector search is Neptune’s ground, so Neptune is the choice.
The slip: accepting a true statement about the wrong service. This is the hardest distractor in the area, because nothing in the wrong option is false.
”Your protocols are already stored relationally in Aurora. Where do the embeddings go?”
Model answer: In Aurora, beside the rows they describe. The text, its approval status and its revision metadata already live there. Adding a separate vector store would create a second copy to keep in sync and secure, with no gain the scenario asks for.
The slip: treating Aurora as a purpose-built vector product, or reaching for a separate search engine because “AI needs a vector database.” The selection signal is that the data is already in Aurora.
”When are documents embedded, and when are questions embedded?”
Model answer: Documents are embedded during ingestion, which runs when the documents change. Questions are embedded per request, during retrieval. That gives two pipelines with two different triggers.
The slip: describing the whole corpus as embedded every time someone asks a question. This confuses ingestion with retrieval. It is the most common structural error in this topic.
”Once it is in the vector store, has the model learned our documents?”
Model answer: No. Retrieved text enters the prompt for that one request and is gone afterwards. The model is unchanged, which is exactly why a document published a minute ago can be answered a minute later.
The slip: using the word “learns.” In exam options, that word is very often planted in the distractor, because it describes training rather than retrieval.
”The answers cite their sources. Does that make them correct?”
Model answer: A citation proves where the text came from, not that it was the right text. If a withdrawn policy is still in the index, an answer citing it looks exactly like a correct one. Grounding gives provenance; evaluation is what checks correctness.
The slip: treating “grounded” as a synonym for “right,” and so skipping evaluation.
Most wrong answers here are accurate facts attached to the wrong scenario
Choose the store the estate already implies
Pulling the reasoning together gives a short set of rules you can say aloud in an interview.
Choose Amazon Neptune when the links between entities decide the answer. Choose Amazon Aurora when the data is already relational in Aurora. Choose Amazon RDS for PostgreSQL when an existing PostgreSQL estate should gain vectors without a new store. Choose Amazon OpenSearch Service when search is the primary workload at large scale or the query mixes keywords and vectors. Choose Amazon Bedrock Knowledge Bases when the requirement is grounded answers without building the pipeline yourself.
In my view, the habit that matters most is asking one question before naming any service: where does the data already live, and what shape is the question? Candidates who ask it first rarely fall for the true-but-wrong option.
Key takeaways
- Four AWS services can store embeddings for RAG: OpenSearch Service, Aurora, RDS for PostgreSQL and Neptune. They are matched to scenarios, never ranked.
- The signals: relationships point to Neptune, existing Aurora data to Aurora, an existing PostgreSQL estate to RDS for PostgreSQL, and search-first at scale to OpenSearch Service.
- Aurora is a relational database that can hold vectors beside the rows they describe, not a purpose-built vector product.
- Bedrock Knowledge Bases is managed RAG. Its signal is grounded answers “without building a retrieval pipeline.”
- Documents are embedded when they change and questions per request. A citation proves provenance, not correctness.
This article settles which service a scenario points to. It does not compare the services on cost, performance or limits at any particular scale, and it does not cover how to evaluate whether retrieved passages are the right ones.