DynamoDB vector search vs pgvector vs OpenSearch: the 2026 cost call

Summary. AWS made vector search in Amazon DynamoDB generally available on 5 August 2026, in all commercial AWS Regions plus the AWS GovCloud (US) Regions. It bills across three dimensions, and AWS's own published example prices a 1 million item RAG index at $55.54 a month in US East (N. Virginia): $51.42 for vector writes at $0.52 per GB written, $3.17 for search at $0.002 per GB processed, and $0.95 for index storage at $0.25 per GB-month. The number that decides most architectures is not on that list. DynamoDB vector indexes have no idle floor, while a minimum Aurora Serverless v2 configuration at 0.5 ACU costs $43.80 a month before a single query, and a classic OpenSearch Serverless collection bills a minimum of 2 OCUs, which is $350.40 a month at $0.24 per OCU-hour. Three constraints will still send you elsewhere: on-demand capacity mode only, a maximum of 5 vector indexes per table, and inline filters that support equality only.

What actually shipped on 5 August 2026

Vector search in DynamoDB is a new index type created on an attribute that holds a vector embedding. You generate embeddings with a model of your choice, store them as a DynamoDB List of Number values through a normal PutItem or UpdateItem call, then create a vector index on that attribute. No new data type, no schema migration.

"DynamoDB supports native vector search with single-digit millisecond latency at 99%+ recall, and is designed for any scale, even trillions of vectors," wrote Esra Kayabali, Principal Solutions Architect at AWS, in the launch post on 5 August 2026.

The mechanics are worth stating precisely because the limits drive the decision:

• Up to 4096 dimensions per vector.

• Three distance functions: COSINE, EUCLIDEAN and DOT_PRODUCT, chosen at index creation and not changeable afterwards.

• The SearchVectors API takes a query vector, a top-K value of up to 100 results, and optional filter conditions.

• A maximum of 5 vector indexes per table, against 20 global secondary indexes and 5 local secondary indexes.

• On-demand capacity mode only. Provisioned capacity is not supported.

• Search is approximate nearest neighbor, not exact.

Two schema choices in the optional SearchSchema do most of the work. A vector index partition key scopes every SearchVectors call to a single partition key value, which is how the index scales horizontally; AWS recommends low-to-medium cardinality attributes such as Category or Country, and you may define at most one. Inline filter attributes are projected into the index so DynamoDB filters at the storage layer during the search rather than after it.

The inline filter limit catches teams out. Filters support the equality operator only. Comparison, range and set-membership operators, <>, <, <=, >, >= and IN, are not available. A price-range filter or a "published after" filter cannot run inside the index, which means you either over-fetch and filter in your application or you keep that query path somewhere else.

The billing model, dimension by dimension

DynamoDB prices vector search on three meters, all separate from and additional to the standard charges on the underlying table.

Two rules shape the bill more than the rates do. Billing is per byte with a 1 KB minimum on both writes and searches, so a 32-dimension vector with a key-only projection is charged as 1 KB; AWS notes a single 768-dimension vector runs about 3 KB, so most real payloads bill purely per byte. And search cost scales with index size, because a larger index means more data scanned to find the nearest matches. That is the line to watch in a growing knowledge base: writes and storage grow linearly with your corpus, search cost grows with it too.

AWS's worked example is the cleanest reference point available. Take 1 million items, each with a 768-dimension vector at 3,072 bytes plus 1 KB of projected attributes, running 10 writes per second and 10 searches per second across a 30-day month:

Reading that table properly matters. Writes are 93% of the vector index bill and search is 6%. For a RAG corpus that is embedded once and queried continuously, the write cost is a one-off backfill rather than a monthly line, and the steady state is close to the search and storage numbers. For agent memory, where every conversation turn writes a new embedding, writes are the recurring cost and the arithmetic reverses.

The idle floor is the real comparison

Rate cards invite a per-unit comparison. That is the wrong lens for vector search, because the three services have completely different behaviour at low utilisation, and most vector workloads outside a handful of large products are low utilisation.

All prices are US East (N. Virginia) and taken from AWS's own published pricing examples as of 14 August 2026. AWS's regional rate tables render client-side and are not readable as text, so treat these as the documented example rates for that region and re-check the console for ap-south-1 or any other region before you build a business case on them.

Two caveats belong next to that table. AWS states the OpenSearch Serverless minimum "varies based on your data size and collections type in use," and NextGen collections carry no minimum OCU requirement, scaling to zero after 10 minutes of inactivity, so the $350.40 figure is the classic-collection floor rather than a universal one. Dev-test mode halves it to 0.5 OCU for indexing and 0.5 for search. The Aurora floor assumes the documented 0.5 ACU minimum held continuously; Aurora Serverless v2 bills ACU-hours pro rata by the minute, and AWS documents scale-down from 5 ACUs to 0.5 ACUs in roughly 3 minutes.

The pattern that falls out of this is simple enough to state as a rule. If your vector workload is spiky, small, or attached to data that already lives in DynamoDB, the idle floor dominates and DynamoDB wins on cost by a wide margin. If your workload is continuously busy at scale, per-unit efficiency starts to matter again and a provisioned OpenSearch cluster or a right-sized Aurora instance can catch up.

When DynamoDB vector search is the right answer

The strongest case is the one AWS built it for: your operational data is already in DynamoDB and you want similarity search on it without a second datastore. Before this launch, that meant copying items into a dedicated vector database and running a synchronisation pipeline between the two, which adds data movement cost, licensing cost, and the ongoing problem of keeping latency predictable across two systems.

Removing that pipeline is worth more than the line item suggests. A synchronisation pipeline is a stateful component that fails at 3am, drifts silently, and needs its own monitoring and backfill tooling. With a vector index, DynamoDB maintains the index from the base table itself, and Time to Live deletions propagate to the index the same way a manual delete does.

Agent memory is the second strong case. Storing conversation embeddings alongside session state in the same table, in the same request path, removes a network hop and a consistency question from every turn. Teams weighing that design against a persistent memory layer will find the trade-offs in our always-on agent memory versus RAG vector database decision guide.

The third case is any workload with long idle stretches. Internal search over a document corpus that gets a few hundred queries a day costs storage plus per-request charges on DynamoDB, and costs an OCU or ACU floor everywhere else.

When to stay on pgvector or OpenSearch

Stay on Postgres when your retrieval query is not purely a similarity search. Anything that needs a range predicate, a join against another table, an aggregation, or a transactional read alongside the vector lookup is a poor fit for an index whose filters do equality only. pgvector runs inside the database that already holds your relational data, and the query planner handles the rest; our pgvector versus a dedicated vector database decision guide covers where that boundary sits, and the Postgres vector search comparison across pgvector, pgvectorscale, ParadeDB and Lantern covers the extensions.

Stay on OpenSearch when you need hybrid retrieval. Combining BM25 lexical scoring with vector similarity, faceting, aggregations and relevance tuning is what a search engine does, and a vector index in a key-value store does not attempt it. The same applies if you need more than 5 vector indexes on one logical dataset, or richer filtering than equality.

Reach for a managed retrieval layer instead of either when the differentiator is not retrieval. Our comparison of Bedrock managed knowledge bases versus self-managed RAG sets out when owning the index stops being worth the engineering time, and agentic RAG versus classic RAG with adaptive routing covers the query-side costs that usually dwarf the index bill.

The operational limits that will bite you

Several constraints are not obvious from the launch material and are expensive to discover after you have written the migration.

DAX does not support SearchVectors. If your application currently reads through DynamoDB Accelerator, similarity searches have to go directly to DynamoDB, so a workload built around a DAX hit rate does not inherit that benefit for vector queries.

The distance function is immutable. You choose COSINE, EUCLIDEAN or DOT_PRODUCT at index creation and cannot change it later, so validate the choice against a representative dataset first. AWS's guidance is that COSINE is the safe default for text embeddings from models such as Amazon Titan Text Embeddings and Cohere Embed, DOT_PRODUCT when magnitude carries signal, and EUCLIDEAN for image or audio embeddings and near-duplicate detection. AWS also recommends normalising embeddings to unit length, at which point DOT_PRODUCT ranks identically to COSINE.

Projections are set at creation too. With an INCLUDE projection you cannot change the set of included attributes afterwards; you delete the index and re-create it. Anything not projected cannot be returned by SearchVectors, and anything you do project is billed on every vector write, which is the single largest meter.

Global tables replicate vector indexes automatically, including dimensions, distance function, SearchSchema and projection, so you do not create the index separately in each replica Region. Replication and indexing are asynchronous even for multi-Region strong consistency global tables, so a vector written in one Region may not appear in SearchVectors results in another until it propagates. Because search is approximate nearest neighbor, AWS also warns that separate searches in different Regions may return slightly different ordering over identical data. Any test that asserts an exact result order across Regions will be flaky by design.

Restores rebuild rather than copy. After a point-in-time recovery or a backup restore, DynamoDB rebuilds the vector index from the restored base table data, so wait until IndexStatus is ACTIVE and Backfilling is false before running searches. Build that wait into your recovery runbook, because a restore that looks complete will return empty search results while backfill is still running.

Estimating your own bill in ten minutes

The arithmetic is straightforward once you fix four numbers: vector dimensions, projected attribute size, write rate and search rate.

Start with bytes per write. A 768-dimension float vector is roughly 3 KB. Add the size of every attribute you project into the index. AWS's example uses 1 KB of projected attributes, giving about 4 KB per item written. Multiply by your monthly write count, convert to GB, and multiply by $0.52.

Then storage. Multiply the same per-item byte count by your item count for index size, and multiply the GB figure by $0.25 a month. AWS's 1 million item example lands at 3.82 GB, which tells you the index is materially smaller than a naive 4 KB times 1 million calculation suggests.

Then search. This is the one people get wrong, because it is data processed rather than a per-query fee. AWS's example processes 1,586 GB across 25.92 million searches, roughly 61 KB per search on a 1 million item index, and that per-search figure rises as the index grows. Multiply by $0.002.

Finally, add the underlying table. Vector index charges are additional to the standard on-demand write request units at $0.625 per million and read request units at $0.125 per million, plus table storage at $0.25 per GB-month.

Two levers matter more than any other. Cutting projected attributes cuts the write meter and the storage meter together, so project keys only unless you genuinely need the attributes in search results. And defining a vector index partition key scopes each search to one partition key value, which reduces the data each search examines, cutting latency and the search meter at the same time.

India-specific considerations

For Indian teams the calculus tilts further towards DynamoDB, for a reason that has nothing to do with the rate card. Most India-market RAG and semantic search workloads we see are attached to modest corpora, a few hundred thousand documents rather than hundreds of millions, with query volumes concentrated in business hours. That is exactly the shape where an OCU or ACU floor is paid around the clock for utilisation that exists eight hours a day.

Two practical notes. The prices in this article are US East (N. Virginia); Asia Pacific (Mumbai) prices differently, so pull the ap-south-1 figures from the console before committing a number to a budget. And where the embedded content includes personal data, remember that embeddings derived from personal data are still processing under the Digital Personal Data Protection Act 2023, and a vector index is another copy of that data with its own retention behaviour. TTL on the base table does propagate deletions to the vector index, which makes retention enforcement simpler than a separate vector store with its own lifecycle.

Teams building the wider cost discipline around this will find the framework in our cloud FinOps guide for Indian teams and the multi-cloud comparison in FinOps for AI cloud cost across AWS, Azure and GCP.

The decision in one paragraph

If your data is in DynamoDB and your queries are similarity plus equality filters, use the vector index; the pipeline you delete is worth more than the rate difference. If your queries need ranges, joins or aggregations, keep them in Postgres with pgvector. If you need hybrid lexical and vector relevance, keep OpenSearch. And if you are choosing on price alone at low volume, the idle floor decides it before the per-unit rates get a vote.

How eCorpIT can help

eCorpIT designs and costs retrieval architectures for teams running RAG, semantic search and agent memory on AWS, including index design, embedding and projection sizing, and the migration path off a synchronisation pipeline into a native vector index. Our senior engineering teams work to CMMI Level 5 process discipline and ISO 27001:2022 controls, and we design applications aligned with DPDP requirements where personal data is embedded. For a costed comparison against your own write and query volumes, contact us.

FAQ

References

1. Amazon DynamoDB now supports real-time vector search at any scale, AWS News Blog, 5 August 2026

1. Using vector indexes in DynamoDB, AWS Developer Guide

1. Amazon DynamoDB pricing

1. SearchVectors API reference

1. Requirements and limitations for vector indexes

1. Best practices for vector indexes in DynamoDB

1. Using vector indexes with global tables

1. Amazon OpenSearch Service pricing

1. Amazon Aurora pricing

1. Build semantic search with native vector support in Amazon DynamoDB, AWS Database Blog

1. Amazon DynamoDB vector search, AWS What's New

1. Tutorial: your first vector search in DynamoDB

1. Amazon Titan Text Embeddings models

1. Storage considerations for vector indexes

1. Data synchronization between tables and vector indexes

Last updated: 14 August 2026.