DynamoDB Added Native Vector Search: Decide When Operational Data and Embeddings Belong in One Table

A product catalog, customer profile service, or agent-memory application already keeps mutable records in Amazon DynamoDB. A separate pipeline extracts source text, calls an embedding model, and copies the vectors plus selected metadata into another retrieval platform. That design buys a specialized search boundary, but it also creates duplicate state, lag monitoring, deletion propagation, two backup plans, and a reconciliation problem whenever the operational record changes.

DynamoDB vector search makes consolidation plausible because embeddings can live beside operational attributes and be searched through a native approximate-nearest-neighbor index. It does not make consolidation automatically correct. The decision still depends on vector count and dimension, update and search rates, tenant boundaries, filter shapes, recall targets, latency service-level objectives, regional topology, recovery requirements, and how much coupling the organization is prepared to accept.

This guide works backward from that workload record. It defines the data and embedding contracts, partitions and projections, measurable relevance and latency gates, a cost worksheet, security and recovery tests, and a reversible migration from a dual-store design. A nearest-neighbor demo is deliberately not a promotion criterion: it says nothing about embedding drift, candidate starvation under filters, stale vectors after partial failure, backfill economics, regional recovery, or the speed of a rollback.

What DynamoDB Vector Search Changed—and What It Did Not

On August 5, 2026, AWS announced general availability of Amazon DynamoDB vector search. AWS described native approximate-nearest-neighbor retrieval over vectors stored with table attributes and stated design targets of single-digit-millisecond latency at more than 99 percent recall, including datasets reaching trillions of vectors. Those are AWS service claims, not independent results for your dimensions, filters, projections, concurrency, or relevance corpus. Treat them as a reason to test, not as acceptance evidence.

The Amazon DynamoDB vector-index developer guide makes the access boundary explicit. A vector index performs similarity search and is read with SearchVectors; global and local secondary indexes serve exact-match and range access patterns through Query and Scan. The DynamoDB secondary-index comparison reinforces that these index families are not interchangeable. Existing application code, dashboards, retries, and authorization checks built around Query do not become a vector-search contract merely because the data shares a table.

AWS’s requirements and limitations for vector indexes require on-demand capacity for both the table and vector indexes, cap each SearchVectors response at 16 MB without pagination, and, as verified on September 3, 2026, list availability in commercial, GovCloud, and China Regions. The August 5 launch notice listed commercial and GovCloud Regions but not China. Because the documentation scopes differ, deployment teams should use the developer guide and an endpoint probe for the target Region instead of freezing the launch wording into architecture.

AWS’s DynamoDB vector-index quotas set a default of five indexes per table, adjustable through AWS Support. They also set hard limits of 4,096 dimensions, TopK 100, one HASH key, 18 inline filters, and one concurrent index creation or deletion per table. Per-partition-key search and write rates, and the 600 GB threshold for creating an index without allowlisting, are adjustable quotas; teams must check the account and target Region before load testing. Promotion stops if the workload needs unsupported operators, provisioned capacity, more candidates than the response contract permits, or an unverified target-Region endpoint.

Make the One-Table-or-Two-Systems Decision Before Writing Code

Consolidation is an architectural choice, not a feature toggle. A broader cloud-native data engineering strategy may prefer fewer replication paths, but the local decision must score search semantics, tenancy, recovery, portability, and ownership before an index is created.

Choose DynamoDB only when operational coupling removes more failure modes than it creates and every mandatory search fits the documented contract. Keep a separate boundary when search needs hybrid ranking, richer filtering, independent disaster recovery, or faster relevance iteration. The incumbent remains until the selected design passes identical gates.

Keep Operational and Semantic Data Together When the Coupling Is an Advantage

One-table operation fits when one vector represents one mutable item, the same team owns record and retrieval SLOs, every search targets a known domain, and equality filters suffice. The item can then carry its source hash, embedding version, retention state, and deletion lifecycle, eliminating a class of missed-replication failures.

• Operational data and embeddings share retention and residency requirements.

• The application tolerates bounded write-to-search visibility lag.

• TopK at or below 100 is enough for candidate generation.

• At least two index slots remain available during migration and rollback.

Retain a Dedicated Vector Platform When Search Has Its Own Operating Model

A dedicated vector platform is safer when semantic search has its own release cadence: global corpus search without one routing key, tenant-specific ranking, hybrid keyword/vector retrieval, range-heavy filters, rapid algorithm experiments, or recovery independent from the operational store. A search engine is especially strong when exact terms, analyzers, facets, and vectors belong in one query plan.

Inventory the Workload, Data Contract, and Retrieval SLO

Begin with a signed workload inventory covering steady state and change events: normal updates, model migrations, deletes, seasonal peaks, new tenants, and regional failover. The application owner supplies demand and user behavior; platform and ML owners validate data shape, evaluation coverage, and operational limits.

The application contract must distinguish ordinary reads from semantic retrieval. The official SearchVectors API reference requires table, index, query vector, and TopK, and returns ranked items plus scores. Extend sound database integration strategies with model version, partition scope, filter policy, score interpretation, dedicated errors, and vector-capacity telemetry.

• Request: query or validated vector, tenant context, retrieval partition, approved filters, TopK, contract version, and deadline.

• Response: item IDs, score and function, source hash, embedding version, Region, index, and retrieval time.

• Telemetry: request ID, partition, filters, TopK, latency percentiles, search bytes, result count, fallback, and error class.

• Fallback: old store, exact/keyword path, safe cache, or explicit semantic-unavailable state.

Unknown filter cardinality, dominant-tenant traffic, deletion SLO, or regional endpoint is a promotion blocker, not a neutral blank.

Define the Embedding Contract Before Creating an Index

An embedding is derived data, but ranking depends on its exact source text, model/version, preprocessing, dimension, normalization, and distance function. Creating an index before this contract stabilizes turns every correction into a backfill. ML publishes the contract; the platform enforces it at write time.

AWS’s vector-index best-practices guidance recommends fixing model/dimensions first, matching distance to the model, synchronizing embeddings, limiting projections, and comparing versions with parallel indexes. Encode those choices in a versioned, reviewable contract.

Version Models, Dimensions, Normalization, and Source Text Together

Use one contract ID for every ranking-affecting choice. For example, catalog-text-v3 can bind a model version, 768 dimensions, unit normalization, locale assembly rules, source schema, and cosine distance. Hash the canonical post-redaction text; any input change makes the vector stale even when keys remain unchanged.

• Idempotency key: tenant + item key + source hash + contract ID.

• Conditional write: accept a vector only while the stored source hash still matches.

• Compatibility: query only an index built for the same contract.

• Rollback: retain the previous vector attribute and index through the approval window.

An embedding version migration is expand-and-contract: add an attribute and index, backfill only that version, compare, canary, and retire later. In-place overwrite destroys comparison evidence and the fastest rollback.

Choose a Distance Function With a Reproducible Relevance Test

DynamoDB supports cosine, dot product, and Euclidean distance. Cosine and Euclidean rank smaller scores as closer; dot product ranks larger scores as closer. Cosine ignores magnitude, while the other two are magnitude-sensitive. Normalization can align cosine and dot-product ordering but removes intentional magnitude signal.

Compare candidate functions on the same labeled corpus and exact baseline. Record recall@K, top-K overlap, critical-slice rank movement, and product quality. Product and engineering choose the function jointly; a change requires a new index because distance is immutable.

Design Items and Vector Indexes for Independent Evolution

A vector-aware item must preserve operational truth, derivation evidence, and version state. “Vector exists” is insufficient: an item may be pending, failed, stale, written but not yet visible, or current. Store explicit state and hashes so the application can reject stale hits after fetching the authoritative item.

The following illustrative item assumes a validated 768-dimensional contract. The vector is abbreviated here, but the stored DynamoDB attribute must be a List of Number values with the complete dimension count.

{
  "pk": "TENANT#t-42",
  "sk": "PRODUCT#p-913",
  "tenant_id": "t-42",
  "retrieval_partition": "t-42#catalog-en",
  "locale": "en",
  "record_status": "ACTIVE",
  "title": "Noise-reducing headset",
  "source_text": "Noise-reducing headset | ...",
  "source_content_hash": "sha256:6cc9...e82a",
  "embedding_v3": [0.0123, -0.0441, 0.0088, "... 765 values ..."],
  "embedding_contract_id": "catalog-text-v3",
  "embedding_model": "approved-text-embedding-model",
  "embedding_model_version": "model-release-3",
  "embedding_dimension": 768,
  "embedding_normalization": "unit-l2-v1",
  "embedding_generated_at": "2026-09-03T09:15:22Z",
  "vector_state": "VECTOR_WRITTEN",
  "vector_failure_reason": null
}

The AWS guide for creating and searching vector indexes documents critical tests: wrong dimensions reject writes; a missing vector partition key lets the base write succeed but silently excludes the item; deleting the vector removes the index entry; higher precision is reduced to f32 in the index. The DynamoDB 400 KB item limit includes names and values, so measure serialized items rather than raw float bytes alone.

Use a compact INCLUDE projection for keys, authorization metadata, source hash/version, title/snippet, and freshness time, then BatchGet authoritative items. Stop if item size lacks headroom, no index slot remains for rollback, or a follow-up read cannot meet the SLO.

Partition the Vector Search Space Without Creating Hot Boundaries

The vector index partition key is a routing and throughput choice. When SearchSchema has a HASH element, each SearchVectors call supplies exactly one value. That narrows work and distributes load, but prevents one request from searching all values. Choose from measured query domains, not by copying the table key.

Map VectorSearchRequestBytes and VectorWriteRequestBytes to routing values and model the largest partition, not the average. Balanced tenant counts do not offset a single dominant traffic value.

Test Tenant, Locale, Catalog, and Time-Based Partition Strategies

Replay real queries against candidate scopes. A composed tenant#locale#catalog key improves locality when callers always know all values, but can starve small slices. Time buckets require fan-out and score merging for multi-window retrieval because filtering is equality-only.

For a dominant tenant, prefer a dedicated table or index for clean capacity and IAM boundaries. If sharding is unavoidable, use stable tenant#shard-N assignment, query every shard, merge comparable scores, and rerank. This application fan-out raises cost and tail latency and must beat an exact baseline.

• Reject a key if more than 20 percent of queries require fan-out; this is a recommended gate, not an AWS limit.

• Reject it if critical slices lack the minimum eligible-neighbor count.

• Load test the largest value at 1.5× peak and keep p99 within 80 percent of the SLO.

Use Filters and Projections Without Hiding Candidate-Starvation Risk

SearchSchema allows one HASH and up to 18 INLINE_FILTER fields. SearchConditionExpression supports equality only; range, comparison, set membership, and arbitrary fields are unavailable. A valid filter can still leave too few candidates for useful ANN retrieval.

KEYS_ONLY is smallest; INCLUDE adds immutable named fields; ALL copies every attribute and expands storage, writes, and response size. SearchVectors returns only projected attributes and omits the vector by default. Prefer compact candidates and fetch authoritative data afterward.

For each production HASH/filter tuple, record eligible count, returned count, filtered exact recall@K, and fallback frequency. The application must define whether sparse results broaden scope, use lexical retrieval, return fewer items, or report no safe match.

• Every mandatory filter combination appears in relevance and load tests.

• Maximum TopK response has internal headroom below 16 MB.

• Authorization is rechecked against the current base item.

• A critical result-count or recall drop triggers fallback.

Build a Write Path That Survives Partial Embedding Failure

Operational writes and embedding writes have different dependencies. A model timeout must not block a customer update, and a successful transaction must not be labeled searchable before asynchronous indexing catches up. Use explicit state, idempotent workers, and the prior verified vector or store as fallback.

Use real-time streaming and integration techniques only where they preserve the vector contract. A stream or outbox event carries item key, source hash, and contract ID. The worker generates a vector and conditionally writes it only if the source hash is unchanged.

1. Write the authoritative record, canonical hash, and PENDING state.

2. Emit an idempotent event keyed by item, hash, and contract.

3. Call the model with bounded timeout/retry and safe diagnostics.

4. Conditionally store vector and metadata only while the hash matches.

5. Measure backlog age and sampled visibility; fall back when freshness exceeds SLO.

The DynamoDB vector synchronization documentation confirms asynchronous index updates and service-managed backfill. Application backfills use DISCOVERED → CLAIMED → EMBEDDED → WRITTEN → VERIFIED, with FAILED/DEAD_LETTER branches. Add deterministic checkpoints, per-contract queues, throttling from measured bytes, and replay-safe idempotency. This extends DataOps automation foundations into an auditable migration.

Poison-record rollback removes only the candidate vector or eligibility key, preserving the operational item, old index, and failure evidence.

Benchmark Recall, Ranking Stability, Latency, and Throughput

A production benchmark needs a relevance corpus and traffic replay. The corpus compares ANN candidates with exact neighbors; the replay tests latency, throughput, freshness, and cost across real partitions and filters. Random vectors and one unfiltered query prove only syntax.

Use ReturnConsumedCapacity and the official vector-index capacity monitoring guidance. Vector search/write bytes are separate from table capacity and have a 1 KB request minimum. Search bytes reflect data examined and returned, so size from representative measurements, not dimensions alone.

Test same- and failover-Region clients, smallest/median/largest partitions, no and selective filters, production TopK, compact/maximum projection, and normal/1.5× peak concurrency. Report p50, p95, and p99 separately; an acceptable average can hide an unacceptable tail.

Separate Index Recall Tests From End-to-End Answer Quality

Index recall asks whether ANN finds exact neighbors in the same eligible vector set. Retrieval relevance asks whether humans judge those neighbors useful. End-to-end quality asks whether the application uses them safely. A high-recall index can still retrieve irrelevant content; a strong language model can hide unstable retrieval.

A defensible starting policy is recall@20 ≥ 0.95 overall and ≥ 0.90 per critical slice; p99 database latency ≤ 80 percent of SLO at 1.5× peak; throttling plus 5xx < 0.1 percent over 24 shadow hours; and no unexplained critical-label regression. These are recommended gates, not AWS guarantees. Any miss keeps traffic on the incumbent.

Model Capacity, Storage, Reindexing, and Regional Cost

Vector pricing adds writes, searches, and index storage to ordinary table charges. On-demand mode removes provisioning, not cost engineering. Model steady and peak traffic, model migrations, global replication, observability, and the interval when both systems and index versions coexist.

The AWS DynamoDB pricing page, checked on September 3, 2026, documents Standard and Standard-IA table classes for vector search, per-byte billing with a 1 KB request minimum, and replicated vector-write charges in destination Regions. Use the regional rate card available at approval time instead of freezing prices in the design.

Combine cost with database performance, security, and scaling controls. Test population, dimensions, TopK, projection, search/update rates, and Region count; fund the full dual-run window. Measure service-managed backfill in rehearsal. The pricing page does not isolate vector-index backfill as a separate line item, so budget from observed write, storage, search, model, and dual-run usage rather than assume the operation is free.

• Run rate fits approved budget and contingency.

• Migration duplication is funded through rollback.

• A 2× traffic case has known cost and throttle behavior.

• Unmeasured search bytes or unpriced Regions block approval.

Apply Security, Privacy, Retention, and Data-Governance Controls

Co-locating vectors with operational data removes one replication boundary but expands table scope. Treat source text, embeddings, query vectors, projected snippets, result IDs, and logs as classified data. Security signs the complete retrieval flow, not only encryption at rest.

The DynamoDB vector-search security documentation requires dynamodb:SearchVectors on the index ARN and says LeadingKeys, Attributes, and Select condition keys do not apply. The index inherits table encryption and has no separate KMS setting. A tenant HASH value improves locality but cannot restrict which values an authorized principal searches.

Do not project full text just to avoid a follow-up read. Return keys and minimal display metadata, fetch the current item under ordinary authorization, compare source and embedding hashes, then pass approved content downstream.

Any cross-tenant hit, deletion miss, prohibited projection, or unsafe query log disables the DynamoDB route immediately.

Design Backup, Restore, Global Deployment, and Failure Recovery

A backup is not a ready-to-search index snapshot. Restore rebuilds the vector index from base items. Search waits for ACTIVE, Backfilling not true, and a successful call to the dedicated endpoint. Measure that full path against RTO/RPO.

The DynamoDB global-table guidance for vector indexes says definitions replicate automatically and each Region serves its local index. Propagation stays asynchronous even with multi-Region strong consistency, and ANN ordering can differ slightly. Route freshness-sensitive reads to the write Region when possible and test failover for relevance as well as latency.

The vector-index troubleshooting guide notes that the search endpoint can briefly lag after DescribeTable reports ACTIVE. Readiness therefore requires a real SearchVectors retry probe. Retry the documented activation and backfill readiness cases; schema, comparator, TopK, type, and dimension errors require request or data correction rather than blind retry.

1. Restore/activate the target and reapply IAM, alarms, streams, TTL, tags, and application configuration.

2. Wait for every required index to be ACTIVE with Backfilling not true.

3. Obtain a successful SearchVectors probe per index and Region.

4. Replay relevance, security, deletion, and freshness tests.

5. Canary while the incumbent remains available; roll back on any miss.

Migrate With Dual Writes, Shadow Reads, Acceptance Gates, and Rollback

In the worked migration, DynamoDB owns products, a stream worker generates embeddings, and a separate vector store serves similarity queries. The safe target keeps both derivation paths, shadows DynamoDB reads, and can return to the incumbent through one feature flag.

Offline replay precedes shadow production. Shadow reads then expose real skew, filters, regional distance, and unrepresented text. Log result IDs and scores, not raw vectors or sensitive query text, and cover every critical slice.

These are starting gates, not claimed results. Any miss stops the ring, routes reads to the old store, preserves evidence, and diagnoses by contract, tenant, partition, and Region.

1. Flip the retrieval flag to the incumbent; do not wait for deployment or index change.

2. Pause candidate writes for security, poison-data, or runaway-cost events; otherwise preserve safe evidence.

3. Drain retries and invalidate candidate caches across the rollback boundary.

4. Remove only the defective candidate vector/index after evidence capture; base data remains.

5. Restart in shadow, then the first canary ring—not the prior percentage.

Retirement requires a rollback exercise, restore drill, clean operating windows, owner sign-off, and confirmation that no producer or consumer depends on the old store.

Operate the Platform With Ownership, Evidence, and a 60-Day Plan

The first 60 days should produce a decision and an operated service, not an endless proof of concept. Each phase ends with evidence and a stop condition; product, application, ML, security, FinOps, platform, and operations own their respective gates.

Connect incident evidence to repeatable engineering practice. Broader data-engineering tools and career foundations can guide skills development, while this service’s contracts, index definitions, filters, IAM, alarms, corpus, and costs stay version-controlled and peer-reviewed.

Final acceptance checklist — each owner signs only after reviewing evidence:

Consolidate only when DynamoDB owns the lifecycle, each mandatory search fits one partition value plus equality filters, relevance and tail latency pass, measured bytes fit budget, tenant controls hold, restore/failover meet objectives, and one feature flag returns traffic to the incumbent. Retain a separate platform for richer filters or hybrid ranking, independent tenancy/recovery, cross-partition search, or faster relevance iteration.

Minimum evidence is a versioned item/embedding contract, partition and slot plan, labeled exact-baseline corpus, p50/p95/p99 load report, filter slices, cost worksheet, IAM/deletion tests, restore/failover game days, dual-write reconciliation, shadow results, and rehearsed rollback. Until then, DynamoDB vector search is a capability, not a production decision.

Readers building foundations in pipelines, real-time processing, storage, transformation, security, and governance can review the Refonte Learning Data Engineering Program. Its page lists three months at 12–14 hours weekly for learners engaged in bachelor’s or postgraduate studies, hands-on projects, a potential internship, PhD Matthias Schmidt as mentor, two certificates after successful completion, and a USD 300 one-time price. It does not list DynamoDB, vector indexes, SearchVectors, Bedrock, or a vector-search module, so no product-specific curriculum claim is made.