OpenSearch Serverless NextGen can sleep after ten idle minutes and takes 10 to 30 seconds to wake
OpenSearch Serverless NextGen, S3 Vectors and DynamoDB vector indexing now all scale to zero on AWS, where OpenSearch's old floor was about $200 a month. A developer who deployed all three from one CDK project says it is hard to look past NextGen.
The Engineer · Build desk

Map: a NextGen collection group can pause with both minimum capacity settings at zero; the first query after idle waits 10 to 30 seconds to cold start, per AWS docs. The author starts from OpenSearch for hybrid search, S3 Vectors for infrequent queries and DynamoDB for low latency.
- What it limits constraint OpenSearch Serverless NextGen A collection group can pause with both minimum capacity settings at zero, claim 2
- What it costs cost First query after an idle period Waits on a cold start of 10 to 30 seconds, AWS documents, claim 4
- Who has to decide decision Keyword and hybrid search apps The author's starting point is OpenSearch when the application needs a broad search engine, claim 12
- Who has to decide decision Infrequent, storage-cost queries The author's starting point is S3 Vectors when storage cost matters most and queries are relatively infrequent, claim 13
- Who has to decide decision Low-latency retrieval beside data The author's starting point is DynamoDB for low-latency semantic retrieval alongside application data, claim 13
| Who | How | Kind | Claim |
|---|---|---|---|
| OpenSearch Serverless NextGen | A collection group can pause with both minimum capacity settings at zero | constraint | 2 |
| First query after an idle period | Waits on a cold start of 10 to 30 seconds, AWS documents | cost | 4 |
| Keyword and hybrid search apps | The author's starting point is OpenSearch when the application needs a broad search engine | decision | 12 |
| Infrequent, storage-cost queries | The author's starting point is S3 Vectors when storage cost matters most and queries are relatively infrequent | decision | 13 |
| Low-latency retrieval beside data | The author's starting point is DynamoDB for low-latency semantic retrieval alongside application data | decision | 13 |
What happened
- The pause is not automatic: both minimum capacity settings on the collection group have to be set to zero before NextGen can scale down.
- The test corpus is a nine-page extract of the UK Aeronautical Information Publication, covering measurement conventions, altimeter procedures and Heathrow information.
- The author describes the work as a feasibility comparison and not a formal benchmark, though the repo includes tools for measuring retrieval.
- The repo prepares one PDF per corpus, and a larger document library would need an ingestion workflow built around it.
Why it matters
- What it limits constraint The first query after an idle spell waits for a cold start, so any path with a person waiting on it needs a timeout or a warm-up request.
- Who has to decide decision Choosing among the three turns on query shape: the author sends infrequent, storage-cost-driven workloads to S3 Vectors and low-latency lookups beside application data to DynamoDB.
- What's now possible capability A small private corpus can use OpenSearch keyword and hybrid search without holding minimum capacity running between queries.
At about $200 a month, the old OpenSearch minimum came to $2,400 a year [18]. The author says the floor applied even in dev-test mode [16]. Their case was a relatively small collection of private documents inside an existing serverless application [14], and their verdict on the arrangement was "@aws, this is not serverless!" [17].
The pick is more interesting because of who made it. The author wrote "I'm a massive DynamoDB advocate" and called DynamoDB vector indexing the option they were most excited about [6]. After trying all three stores, the author still wrote that "it is very hard to look past OpenSearch Serverless NextGen" [5].
The reason visible in the excerpt is query shape. In aviation text, an exact reference such as EGLL AD 2.12 can matter as much as the meaning of the surrounding text, and hybrid search combines keyword matching with vector similarity [11]. We think a corpus with few exact identifiers loses the main reason the author gives for choosing OpenSearch.
The test is small. The author concedes that nine pages is not a lot and that the whole document could go into a context window [9]. The stated point was the retrieval pattern once an application grows to hundreds or thousands of documents, including private material the model has not seen [9]. The excerpt does not include per-service prices, retrieval scores, or results from a corpus at that size.
In our view the verdict transfers to another workload only if its documents carry identifiers that keyword matching can catch and its traffic can absorb a cold start after idle periods [4].
What to watch
- Published cost and retrieval numbers for all three stores on a corpus much larger than nine pages.
- Whether AWS documents cold-start times for S3 Vectors and DynamoDB vector indexing that can be set against NextGen's 10 to 30 seconds.
- Whether the ranking holds once the repo's ingestion step covers a library of hundreds or thousands of documents.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence40
- Adoption
- Insufficient
- Hype gap+10
- Incentives
- Insufficient
- Confidence50
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
AWS went from zero serverless vector stores to three in the space of a year: OpenSearch Serverless NextGen with scale to zero, S3 Vectors, and vector indexing in DynamoDB.
- [2]
With both minimum capacity settings at zero, an OpenSearch Serverless NextGen collection group can pause.
- [3]
The collection group pauses after ten minutes without requests.
- [4]
AWS documents 10 to 30 seconds to cold start on the first search or indexing request, so the first query after an idle period is affected.
- [5]
Having tried all three stores, the author wrote that "it is very hard to look past OpenSearch Serverless NextGen".
- [6]
The author wrote "I'm a massive DynamoDB advocate" and said DynamoDB vector indexing is the option they are most excited about.
- [7]
The author says the comparison is of technical options, not a formal benchmark; the repo includes tools for measuring retrieval, but the work is more about feasibility.
- [8]
The test corpus is a nine-page extract from the Public UK Aeronautical Information Publication covering measurement conventions, altimeter procedures and Heathrow airport information.
- [9]
The author acknowledges nine pages is not a lot and the whole document could go in a context window; the point is the retrieval pattern for applications with hundreds or thousands of documents, including private material the model has not seen.
- [10]
The current repo prepares one PDF per corpus, and a larger document library would need an ingestion workflow around it.
- [11]
In an aviation document an exact reference such as EGLL AD 2.12 can matter just as much as the meaning of the surrounding text, and hybrid search combines keyword matching with vector similarity.
- [12]
The author's starting point is OpenSearch when the application needs a broad search engine, including keyword and hybrid search.
- [13]
The author's starting point is S3 Vectors when storage cost matters most and queries are relatively infrequent, and DynamoDB when low-latency semantic retrieval is wanted alongside application data, particularly data already in DynamoDB.
- [14]
The author needed to make a relatively small collection of private documents searchable within an existing serverless application.
- [15]
The author's CDK TypeScript project deploys OpenSearch Serverless NextGen, S3 Vectors and a DynamoDB on-demand table with a native vector index, and loads the same embeddings and source data into each.
- [16]
Prior to 2026, OpenSearch "Serverless" required a minimum spend of around $200 per month, even in its dev-test mode, according to the author.
- [17]
On the old OpenSearch minimum, the author wrote: "@aws, this is not serverless!"
- [18]
A minimum spend of around $200 a month comes to roughly $2,400 a year.
Get this ledger inside ChatGPT. Ask about any of our stories and the answer brings its figure, each claim’s verdict and the sources. Free, no account.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toServerless Vector Stores on AWS
1 article · October 15, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
Entities
- Amazon DynamoDBFollow
- Amazon Web ServicesFollow
- Amazon OpenSearch ServerlessFollow
- Amazon S3 VectorsFollow
- Amazon BedrockFollow
- AWS Cloud Development KitFollow