DynamoDB Vector Search GA (Aug 2026): When to Drop the Sync Pipeline

On August 5, 2026, AWS announced general availability of vector search for Amazon DynamoDB — native approximate nearest neighbor (ANN) indexes so you can store embeddings next to operational attributes and call SearchVectors without replicating into a separate vector database. The companion AWS News Blog walkthrough positions single-digit millisecond latency at 99%+ recall, up to 4,096 dimensions, and design for any scale (including trillions of vectors), available in all commercial Regions and AWS GovCloud (US).

If your product catalog, session store, or agent memory already lives in DynamoDB, this is the moment to ask whether the OpenSearch / Pinecone / S3 Vectors sync pipeline is still earning its keep. If your workload is corpus-scale RAG with wide recall and hybrid lexical search, it is not — keep S3 Vectors or OpenSearch Serverless for that lane.

Modeled comparison (not a cited client) — Same product-catalog shape as the AWS News Blog sporting-goods example: 1M items × 4 KB, embeddings on descriptionEmbedding, 10 vector writes/s + 10 SearchVectors/s. Per the DynamoDB pricing on-demand vector example, AWS sketches ~$121.29/mo total (~$65.75 underlying table + ~$55.54 vector write/search/index storage at the published $0.52/GB write, $0.002/GB search, $0.25/GB-mo index rates). Architecture A keeps vectors in DynamoDB (no sync). Architecture B keeps ops in DynamoDB and mirrors embeddings to S3 Vectors or OpenSearch — you still pay DDB writes plus second-store ingest, drift monitoring, and dual failure modes. Architecture C uses Bedrock Knowledge Bases for document RAG and leaves DynamoDB for transactional keys only. The quantified outcome here is the AWS published bill sketch and the removed sync pipeline, not a FactualMinds engagement savings number.

What shipped on August 5, 2026

Embeddings come from your model path — Bedrock Titan Text Embeddings, Cohere Embed, OpenAI, or anything else. DynamoDB stores the floats; it does not embed for you. Create the index via console, CLI, SDK, or CloudFormation after the attribute exists on items.

Developer reference: Using vector indexes in DynamoDB.

Opinionated take: when DynamoDB wins vs when it does not

Prefer DynamoDB vector search when:

• Operational data already lives in DynamoDB (products, users, agent memory, recommendations state)
• You need single-digit ms semantic retrieval colocated with attributes in one response
• Candidate sets fit topK ≤ 100
• Filters are equality checks (marketplace = US, category = footwear)
• You will run the table on-demand and want to delete the sync pipeline

Prefer another store when:

Trade-off we accept: DynamoDB vector search optimizes for colocated ops + ANN and serverless ops simplicity. You give up hybrid search, wide topK, and provisioned-mode vector indexes. That is the correct trade for agent memory and product similarity; it is the wrong trade for enterprise document RAG with cross-encoder rerank pools.

Reproduce this — Score your workload with examples/architecture-blog-2026/dynamodb-vector-search/vector-store-decision-matrix.md. Sum ≥ 14 → pilot DynamoDB vector search this sprint; 8–13 → split ops vs corpus stores; < 8 → keep the current vector path.

Pricing dimensions (read the invoice correctly)

Vector search is not free with base table traffic. Per AWS pricing docs:

1. Vector write requests — GB written into the vector index (vector + projected attributes)
2. Vector search — GB processed to answer similarity search + data returned
3. Vector index storage — GB-month

Plus normal on-demand WRU/RRU and table storage. Operations bill per byte with a 1 KB minimum. Global table replicated vector writes meter as vector write requests in the destination Region.

Re-check rates on the DynamoDB pricing page for your Region. For broader on-demand vs provisioned context (without vector), see DynamoDB pricing: on-demand vs provisioned.

Getting started shape (minimal)

Assumes: AWS CLI v2, on-demand table ProductCatalog, Titan Embeddings v2 (1,024 dims), Cosine distance, partition key marketplace, filter category.

1. Backfill descriptionEmbedding as a List of numbers via UpdateItem (or embed on write going forward).
2. Create vector index — name, vector attribute, dimensions 1024, Cosine, optional PK marketplace, filter attributes, projection.
3. Wait until index status is Active.
4. Embed the query with the same model, then call SearchVectors with topK (≤ 100), partition key value, and filters.

Similarity score semantics: for Cosine and Euclidean, lower is closer (0 = identical). For Dot product, higher is closer. Wire your UI and thresholds accordingly.

For single-table key design around the non-vector access patterns, see DynamoDB single-table patterns for SaaS.

What broke — Day one of a multi-marketplace catalog: team created a vector index without a partition key, then ran US and EU semantic searches against the full index under peak traffic. Latency stayed “fine” in the console demo on thousands of vectors and degraded as the catalog grew — every search examined one shared partition. Detection: rising SearchVectors latency and hot-partition CloudWatch metrics after backfill completed. Fix: recreate the index with marketplace as the vector index partition key and pass the marketplace on every search. Same week, a second team used Euclidean with a model trained for Cosine and watched recall collapse until the distance function matched the embedding training metric.

Agent memory and RAG — do not force one store

DynamoDB already shows up as agent memory storage. Vector search adds semantic retrieval over that memory for grounding — short, hot, attribute-rich items with strict latency. That is different from document RAG over PDFs and wikis.

Recommended split:

• Agent turns / tool results / user prefs → DynamoDB + vector index
• Knowledge corpus → S3 + Bedrock Knowledge Bases (S3 Vectors or OpenSearch backend)
• Fraud / graph neighborhood + similarity → Neptune Analytics when structure matters

Fine-tuning vs RAG routing still applies: Fine-tuning vs RAG on Bedrock.

What This Post Doesn’t Cover

• First-party latency benchmarks in a FactualMinds account — numbers above are AWS-published claims and the pricing-page example, not our harness.
• Full SDK samples for every language — see the developer guide and AWS MCP plugins for live API shapes.
• Exact Regional rate tables — use the pricing calculator / pricing page for your account; example dollars are illustrative US rates from AWS.
• Migrating an existing Pinecone/OpenSearch corpus into DynamoDB — usually a re-embed + dual-write cutover, not a dump/restore.

What to Do This Week

1. Score the vector store decision matrix — pilot if sum ≥ 14.
2. Confirm the candidate table is on-demand (or plan the capacity-mode change).
3. Lock embedding model, dimensions, and distance function before creating the index.
4. Backfill one attribute; create one vector index with a partition key and one exact-match filter; smoke SearchVectors with topK 5.
5. Compare monthly cost of Architecture A (DDB-only) vs B (DDB + second vector store) using the AWS pricing example shape — if sync + dual store still exists only for ≤100-neighbor lookups, schedule decommission.

Need help choosing DynamoDB vs S3 Vectors vs OpenSearch for GenAI retrieval? FactualMinds is an AWS Select Tier Consulting Partner — contact us.

Related reading

• S3 Vectors: 10,000 Results per Query (June 2026)
• Amazon DynamoDB Pricing: On-Demand vs Provisioned
• DynamoDB Single-Table Design Patterns for SaaS
• How to Build a RAG Pipeline with Amazon Bedrock Knowledge Bases
• Amazon Neptune Analytics: Graph + Vector
• Fine-Tuning vs RAG on Bedrock