Four names, four fingerprints. Retrieval Augmented Generation is what needs the store; a worked scenario shows the estate deciding it. Index types and distance metrics sit deeper than this level needs. This card stays at the naming level.
Flash card
Vector storage on AWS: the four services that hold embeddings and answer a similarity query, and the fingerprint phrase in a scenario that points at each one.
- Amazon OpenSearch Service is the general-purpose default, and it is what a scenario picks when nothing in the estate argues for anything else. A managed domain runs vector search through the k-NN plugin, so the cluster is yours to size; a serverless vector collection does the same retrieval with no capacity planning and no nodes to choose. It also does ordinary keyword search on the same documents. A scenario that wants keyword matching and semantic matching together lands here.
- Amazon Aurora PostgreSQL holds embeddings through the pgvector extension, which adds a vector column type and nearest-neighbour search to ordinary SQL. The give-away phrase is that the operational data is already in Postgres and the team wants one database rather than two: the vectors sit in a column beside the rows they describe, share the same backups and grants, and a similarity query can carry a normal WHERE clause on price, stock or tenant.
- Amazon RDS for PostgreSQL runs the same pgvector extension on the standard PostgreSQL engine, so it stores and searches vectors the same way. Choosing between it and Amazon Aurora is the ordinary database decision about scale, cost shape and failover, not a decision about AI. Treat the two as one answer whenever a scenario is asking “keep it in Postgres or move it out”, and split them only when the scenario also wants the ingestion managed, because Amazon Bedrock Knowledge Bases writes into Amazon Aurora PostgreSQL and not into Amazon RDS.
- Amazon Neptune stores vectors next to a graph, through Neptune Analytics, so one query can measure similarity and follow relationships between entities in the same pass. It is the named answer only when the scenario says something about connections: who supplied what to whom, which papers cite which, how components depend on each other. Absent that, Neptune is a distractor and the general-purpose store wins.
- Amazon Bedrock Knowledge Bases chunks the source documents, calls an embedding model, writes the vectors into a store you nominate and keeps them in step as the source changes, so picking your own database does not mean hand-building the ingestion pipeline. It writes only into the stores it supports: Amazon OpenSearch Service, as a serverless vector collection or a managed cluster; Amazon Aurora PostgreSQL Serverless v2, reached through the RDS Data API; and Amazon Neptune Analytics. Amazon RDS for PostgreSQL is not among them, so a scenario that asks for managed ingestion alongside Postgres names Amazon Aurora.
Pick it when
Pick the store the workload already runs. Data in PostgreSQL means pgvector on Amazon Aurora or Amazon RDS for PostgreSQL, with Amazon Aurora the one to name when the ingestion has to be managed as well; nothing already in place, or a need for keyword search alongside, means Amazon OpenSearch Service; relationships in the retrieval means Amazon Neptune. Then check who owns the embedding pipeline, and whether Amazon Bedrock Knowledge Bases supports the store you picked.
It's the wrong answer when
Amazon DynamoDB and Amazon S3 are not vector databases. Both will happily hold an embedding, as an item attribute or an object, and neither can answer “which of these is nearest”, so a scenario offering either as the similarity-search answer is a distractor. Reading every object in a prefix to compare vectors is a scan, not an index.