Amazon S3 Vectors GA Scales to 2 Billion Vectors per Index

What AWS shipped

Amazon S3 Vectors became generally available at re:Invent on December 2, 2025. With GA, the vector-native storage tier moved from a capped preview into a production service, and AWS argued it can replace dedicated vector databases for a large share of AI retrieval workloads. AWS calls it the first cloud object store that can store and query vectors natively. The company says it can cut the cost of uploading, storing and querying embeddings by up to 90% compared with specialized vector databases.21 Ten months on, that claim is still the headline. The independent work published since then makes clear that the 90% figure only holds for certain workloads.

The GA numbers were a large jump. One index can now hold up to two billion vectors, 40 times the 50-million cap from the July preview. A vector bucket can hold 10,000 indexes, for up to 20 trillion vectors per bucket.22 AWS says infrequent queries still return in under a second, while frequently queried indexes now answer in about 100 milliseconds or less.21 Each query can now return up to 100 results instead of 30, and each vector can carry up to 50 metadata keys for filtering.2221

AWS also pointed to strong preview adoption. In just over four months, customers created more than 250,000 vector indexes, ingested more than 40 billion vectors and ran more than a billion queries, counted as of November 28, 2025.22 Availability grew from five regions to 14 at launch.22 One later cost analysis reports that AWS added 17 more regions in March 2026.3

Where the coverage agrees, and where it slips

On the core specs, the reporting mostly matches. InfoQ, BigDATAwire and Blocks & Files all repeat the two-billion-per-index ceiling, the 40x jump and the 90% cost claim.2326 Blocks & Files adds that frequent queries run two to three times faster than in preview. It also places S3 Vectors in a wider set of S3 changes at the same show, including a maximum object size raised from 5 TB to 50 TB and Intelligent-Tiering for S3 Tables.

The details are less consistent. The summary line on AWS's own launch blog says one billion vectors per index, while the body of the same post says two billion.22 InfoQ describes the latency as "sub-100ms."23 AWS itself says "around 100 milliseconds or less" for frequent queries and keeps the sub-second wording for cold ones.21 That gap matters. One detailed design guide points out that AWS describes latency qualitatively and tied to how often an index is queried, not as a guaranteed number. The best reading is that S3 Vectors is roughly a 100 ms service once an index is warm. It is not a sub-100 ms engine.

AWS was also careful about positioning in a way the 90% headline doesn't show. Mai-Lan Tomsen Bukovec, AWS's VP of technology, told VentureBeat that customers choose between S3 Vectors and a vector database based on how much latency their application can tolerate. She framed the choice as "performance tiering" rather than replacement.10 An analyst quoted in the same coverage said the service would not remove the need for vector databases where low latency and high performance matter.10

The streaming-ingest angle

For teams that feed embeddings from event streams, the most important GA change may be write throughput. AWS now supports up to 1,000 PUT transactions per second for single-vector updates. It says this is aimed at workloads where new data has to be searchable right away, or where many sources write to the same index at once.22 AWS also says writes are strongly consistent, so a new vector can be queried immediately without rebuilding the index.

That makes S3 Vectors workable as the destination of a change-data or event pipeline, but only within limits. One design guide lists the per-index caps as 1,000 combined put and delete requests per second and 2,500 vectors per second. For sustained ingestion above that, it recommends a streaming-oriented engine or sharding at the application layer.9 Another practitioner guide puts write throughput at about 2,500 vectors per second per index and query throughput in the hundreds of requests per second. It concludes the service is a poor fit for real-time, high-QPS applications.7 So for streaming, S3 Vectors fits moderate, steady flows of fresh embeddings, such as documents, tickets or agent memories. It does not fit firehose-scale ingestion.

The cost math is the real story

Price is where independent analysis has added the most. Published rates include $0.06 per GB-month for storage, $0.20 per GB uploaded and $2.50 per million query calls. On top of that is a per-terabyte data-processing charge that falls once an index passes 100,000 vectors.35 Pinecone's comparison page says the per-TB rate drops again above 10 million vectors. It also notes that data processed is the average vector size multiplied by the number of vectors in the index, so every query is priced against the size of the whole index.16

That design produces a sharp crossover. One benchmark modeled 100 million vectors at 10,000 queries a month at $38 for S3 Vectors, against more than $2,000 for OpenSearch Serverless NextGen. At 10 million queries a month on the same index, S3 Vectors rose to about $9,405, while Aurora pgvector came in near $1,578. At a billion vectors and 10 million monthly queries, the modeled S3 Vectors bill was about $93,746.11 The author found S3 Vectors cheapest between roughly 1,000 and 300,000 queries a month. Above that, Pinecone and then Aurora pgvector win.11

Pinecone, which has an obvious interest, makes the same structural point. Its pitch is that sustained reads favor its Dedicated Read Nodes, which charge a flat monthly rate, while S3 Vectors wins for large corpora that are rarely queried.16 An AWS community guide modeled a 10-million-vector workload at a million queries a month at about $11.5 The same guide puts S3 Vectors' p95 latency at 100–300 ms and says it lacks BM25, full-text fusion and hybrid search.5

On latency, results vary but the trend is consistent. One test measured a warm p50 of 68 ms and a p99 of 107 ms, with no visible cold-start penalty.11 A team that migrated from Pinecone reported cutting a $420 monthly bill to $42. Their P50 latency went from 6 ms to 95 ms, and their P99 rose to 450 ms.14 Read together, S3 Vectors is predictable at around 100 ms, but it is not in the same latency range as in-memory engines.

What it means for Postgres and pgvector

The Postgres question is where positioning becomes practical. AWS's own guidance describes pgvector on RDS as a relational database with vector support. It lists 10–100 ms latency, ACID transactions and capacity in the millions of vectors, depending on instance size. It lists S3 Vectors as low-cost long-term storage, suited to queries that come minutes or hours apart.12 One AWS community guide puts Aurora pgvector's sweet spot at about one to five million vectors, with p95 latency around 1.5 ms when tuned.5

That makes S3 Vectors less a pgvector competitor than a release valve for it. Teams that kept embeddings next to relational data in Postgres no longer have to scale up instances or build sharding when the corpus grows into the hundreds of millions. They can move the long tail to object storage. One cost analysis notes that S3 Vectors doesn't attempt cross-index joins or transactions, and that Aurora pgvector is still the better fit when those matter.11 Ecosystem guides still recommend pgvector for teams already on Postgres, valuing one database with SQL filters.17 S3 Vectors does not change that advice for transactional apps. It changes the advice for archival-scale retrieval.

The broader vector database landscape

The pattern emerging in vector databases is tiering. A detailed design guide argues the interesting choice is S3 Vectors and OpenSearch together, not one or the other. It describes two official integration paths that reached GA alongside S3 Vectors, with OpenSearch handling hybrid search and consistently low latency while S3 holds the cold tier. Pinecone suggests a similar split, with the archive in S3 Vectors and the actively queried working set in Pinecone.16

The service has real limits. Dimension, distance metric and non-filterable metadata keys are fixed when an index is created, so a change of embedding model means a new index.9 Only cosine and Euclidean distance are supported.7 There are no query-tuning settings, and the service runs only on AWS.16

Our view is that S3 Vectors has done to vector storage what S3 Tables did to analytics. It has made object storage the default resting place for the data, and left specialized engines to compete for the hot path. The 90% savings are real for large, rarely queried indexes. Applied to a busy production index, the same pricing that makes the service cheap at rest can make it the most expensive option available.