← Blog
opensearchairag

The capacity floor under your RAG prototype

By , founder of CostPulse ·

The fastest way to stand up a vector store for a RAG prototype is OpenSearch Serverless: no cluster to size, no nodes to patch, working similarity search in an afternoon. The part that surprises teams at the end of the month is that "serverless" here does not mean "scales to zero." Collections are billed in OpenSearch Compute Units, and there is a minimum capacity that keeps billing around the clock — whether your prototype served ten thousand queries or none at all.

A floor, not a meter

Most serverless pricing intuition comes from Lambda: no traffic, no bill. OpenSearch Serverless works the other way — capacity is provisioned in OCUs for indexing and for search, and the service maintains a minimum number of them per account as long as any collection exists. Check AWS's current pricing page for the exact per-OCU rate and minimums (they've changed over time, and dev/test configurations can lower the floor), but the shape of the charge is the point: it's a flat monthly floor that has nothing to do with usage. For a production search workload that floor is noise. Under a weekend experiment someone forgot about, it's typically the largest line item the account has never heard of.

billed capacity (the floor)actual query trafficone month →

A prototype's month with a capacity-floor service: the experiment ended in week one — the billing didn't.

Why RAG prototypes hit this specifically

  • The vector store outlives the experiment. The Lambda and the model calls in a RAG demo cost nothing when idle, so deleting them feels optional. The collection backing them keeps billing its floor until someone explicitly deletes it.
  • Knowledge-base wizards create collections for you. Managed RAG features that "handle the vector store automatically" are creating an OpenSearch Serverless collection under the hood. Convenient on day one; invisible on the bill's day thirty, because nobody remembers creating it.
  • Per-environment duplication. One collection each for dev, staging, and prod triples a floor that was priced with production in mind.

What to check first

  • List your collections (aws opensearchserverless list-collections) in every region you've experimented in — the console only shows the region you're looking at.
  • In Cost Explorer, filter to OpenSearch and group by usage type — OCU-hours for indexing and search show up separately, and a flat daily amount with zero query traffic is the signature of a paid-for floor doing nothing.
  • For prototypes you want to keep, check whether a dev/test capacity configuration or a plain provisioned t-class OpenSearch domain — or a different vector store entirely — fits the workload's actual scale.

Floors like this are also why day-over-day anomaly detection alone isn't sufficient: a flat charge that started three weeks ago never spikes. It shows up when a new service appears in your spend at all, and in week-over-week drift — both worth watching for on any account where someone is allowed to experiment.

CostPulse watches for this automatically — a 7-day rolling baseline per service and region, with the alert in Slack, Teams or email within about a day of it starting. Not on the invoice a month later.

Have an AWS spend commitment? Buy through AWS Marketplace and it may count toward it, depending on your agreement. Want a full teardown instead? Book an audit — $3,500.