Why Did AWS Release Yet Another Vector Store?

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.

The AWS vector landscape

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:

• Amazon OpenSearch
• Aurora PostgreSQL
• Amazon DocumentDB
• Amazon MemoryDB
• Amazon Neptune
• Amazon S3 Vectors
• Amazon DynamoDB Vector Search

That's seven services! While listing these out the question became even louder in my head: why is AWS giving us another one?

My initial assumption

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.

Operational vectors

Think about the data that lives in your application's hot path:

• Users: profile embeddings for personalization
• Products: catalog embeddings for recommendations
• Session memory: conversation context for AI agents
• Recommendations: real-time suggestions based on behavior
• Fraud detection: transaction pattern matching

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.

Knowledge vectors

Now think about a different category of data:

• PDFs: company documents, research papers
• Documentation: internal wikis, product manuals
• Policies: compliance docs, HR handbooks
• Support articles: knowledge base content
• Code: repository embeddings for search

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.

Why this matters more than pricing

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.

Why DynamoDB Vector Search exists

Let me be specific about what makes this valuable for operational workloads:

• Single logical write: Store the embedding alongside the item with a regular PutItem call, without the need for a separate ingestion pipeline.
• Native indexing: Create a vector index on an attribute and DynamoDB handles the rest, the same way you would create a new global secondary index. With the added benefit that it automatically scales horizontally as your data grows.
• Metadata filters: Narrow search results using your existing DynamoDB attributes. For example, you can search products by similarity but filter to a specific category or marketplace.
• Operational workloads: Built for the same access patterns DynamoDB already excels at, that provide high throughput, low latency and predictable performance.
• No infrastructure: Same serverless model DynamoDB users already know.

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.

Where S3 Vectors shines

On the other side, S3 Vectors is built for a different set of problems:

• Massive collections: Billions of vectors at scale without worrying about provisioning
• Enterprise RAG: Power your retrieval-augmented generation pipelines with large knowledge bases
• Cost optimization: When you have millions of documents embedded and sitting mostly idle, the cost model of S3 Vectors is hard to beat
• Long-lived embeddings: Documents that get embedded once and queried many times over months or years

If you're building a knowledge base for your agents or a documentation search system, S3 Vectors is the natural fit.

The mental model

Here's how I think about it now:

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.

Wrap up

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