When AWS announced DynamoDB Vector Search last week, my first thought was... didn't AWS just launch S3 Vectors?
I mean, S3 Vectors went GA back in December. It's been less than a year, and now we have another service that stores vectors and does similarity search. I'll be honest, I was a bit puzzled. So I decided to dig in and figure out what's going on.
Before we get into DynamoDB Vector Search specifically, let's acknowledge the elephant in the room. AWS already has vector capabilities in a lot of places:
That's seven services! While listing these out the question became even louder in my head: why is AWS giving us another one?
My first instinct was to compare DynamoDB Vector Search and S3 Vectors head-to-head. They both store vectors, perform similarity search, support AI workloads, and are serverless. On paper, they sound like the same thing.
I started going through the documentation for both services trying to figure out which one was "better." I was looking at dimensions supported, distance functions, query limits, the typical comparison stuff.
And then I realized I was asking the wrong question. The question isn't which vector store is better?, the question is: what kind of data do these vectors represent?
That distinction changes everything, it's not about the vectors themselves, it's about what the vectors are attached to.
Think about the data that lives in your application's hot path:
These are all operational, data that changes frequently, is queried with low latency requirements, lives alongside other application data that your code already reads and writes, and represents your application's state.
This is where DynamoDB Vector Search makes sense. If your product catalog already lives in DynamoDB, why would you copy those embeddings to a separate vector database? You'd have to build a synchronization pipeline, handle eventual consistency, manage another service, and pay for data movement. With native vector search, you store the embedding right next to the item and query it in the same place with a single write within the same service.
Now think about a different category of data:
These are knowledge assets, they don't change very frequently, they are typically large collections that get ingested in bulk, and power RAG pipelines where an AI retrieves context before generating a response. They don't belong in your application's transactional database because they're used as reference material instead of for the application state.
This is where S3 Vectors shines. It's purpose-built for storing massive collections of embeddings at the lowest possible cost. It's optimized for the pattern where you embed a ton of documents and then query against them. AWS claims up to 90% cost savings compared to specialized vector databases for these workloads, and for large knowledge bases that makes a big difference.
The first thing most people do when two services overlap is compare pricing. And yes, the cost profiles are different. But I think the architectural decision is more important than the price per query.
Data locality: Your operational vectors should live where your operational data lives. If a user's embedding is stored in DynamoDB alongside their profile, you can update both in a single write avoiding stale data from a syncing pipeline.
Data ownership: Knowledge vectors often come from content that lives in S3 already. Keeping the embeddings close to the source material in S3 Vectors means one fewer system to reason about.
Simplicity: Every time you add a synchronization pipeline between two services, you add a failure mode, latency, cost, and operational burden. Choosing the right vector store based on what the data represents lets you avoid that complexity entirely.
Latency: DynamoDB Vector Search delivers single-digit millisecond latency. This is really impactful when you're doing real-time recommendations or fraud detection in the hot path of a user request. S3 Vectors optimizes for throughput and cost on large collections, where a few extra milliseconds won't hurt.
Let me be specific about what makes this valuable for operational workloads:
If you're already using DynamoDB and want to add semantic search to your application, you no longer need to maintain a separate vector database and the pipeline that feeds it.
On the other side, S3 Vectors is built for a different set of problems:
If you're building a knowledge base for your agents or a documentation search system, S3 Vectors is the natural fit. Here's how I think about it now:
| If your vectors represent... | Consider |
|---|---|
| Users | DynamoDB Vector Search |
| Products | DynamoDB Vector Search |
| Recommendations | DynamoDB Vector Search |
| Session memory | DynamoDB Vector Search |
| Fraud signals | DynamoDB Vector Search |
| PDFs | S3 Vectors |
| Documentation | S3 Vectors |
| Knowledge bases | S3 Vectors |
| Support articles | S3 Vectors |
The simplest way I can put it: if the data is something your application actively mutates and queries in real-time, it's operational and DynamoDB vector search is the perfect fit. If the data is something you embed once and retrieve many times as context, it's knowledge and you should use S3 Vectors.
Going back to the question I started with: why did AWS release another vector store?
The answer is that AWS isn't just adding more vector databases to the catalog, they're bringing vector capabilities to the storage engines developers already use. DynamoDB users shouldn't have to leave DynamoDB to do similarity search on their operational data, and S3 users shouldn't have to spin up a separate database to search their document embeddings.
It's not about which service is better, it's about which data model matches your vectors.
Let me know what you think about this distinction! I'd love to hear how others are thinking about where to put their vectors. Andres Moreno