Research-backed calculator guide

Hot, Warm and Cold Vector Storage: Tiering Cost Without Breaking Retrieval SLOs

Learn how to model tiered vector storage cost across hot, warm and cold tiers, including vector bytes, index overhead, replicas, migration and retrieval SLO trade-offs.

What tiered vector storage cost includes

The first mistake in vector-cost planning is multiplying a provider’s storage rate by the size of the embedding array and stopping there. A vector database may also retain an approximate-nearest-neighbor index, payload or metadata fields, tombstones, snapshots, replicas, and temporary copies. Different products account for those meters differently, so normalize them into capacity assumptions before comparing providers.

For an uncompressed float32 vector, the raw payload is:

raw vector bytes = vector count × dimensions × 4

A 768-dimensional float32 vector therefore consumes 3,072 bytes before metadata and indexing. If the application stores a document ID, timestamps, filters, ACL fields, and source references, the payload can be materially larger. HNSW-style indexes may add substantial graph overhead, while disk-based or quantized indexes change both storage and recall behavior. Measure the representation your engine actually uses instead of assuming that raw bytes equal billed bytes.

The second mistake is treating hot, warm, and cold as universal product labels. In one system, hot may mean an in-memory HNSW index. In another, it may be fast NVMe with a cache. Warm may mean an on-disk index that remains queryable, while cold may mean object storage that requires reactivation or a separate query path. Weaviate’s documentation, for example, distinguishes hot memory, warm SSD, and inactive cold cloud storage, and explicitly notes that offloaded tenants require reactivation.^[7] Those semantics matter when you map a price to a retrieval SLO.

The third mistake is ignoring the access distribution. “Keep 20% hot” is not a design rule until it is supported by access logs. Export query counts by collection, tenant, time window, and result freshness. Then choose a policy such as “keep the newest 90 days hot unless its p95 exceeds the hot-tier budget” or “demote a collection after 30 days below a measured query threshold.” A time rule is easy to automate, but a query-frequency rule better captures seasonal content.

A practical tiering model

Start with four capacity layers:

1. Raw vectors. Count vectors, dimensions, numeric type, and whether vectors are dense or sparse.
2. Search representation. Add metadata, ANN graph or inverted-index overhead, compression, and tombstone headroom.
3. Durability copies. Add replicas, backups, snapshots, and any source-of-truth copy retained outside the search tier.
4. Transition capacity. Add the overlap required while a vector is copied, validated, and deleted from its previous tier.

Then attach workload constraints. For each tier, record expected p50, p95, and p99 latency; query throughput; freshness; supported filters; update behavior; and recall target. A warm or cold tier that is cheap but cannot support the required filter or recall should not be counted as a drop-in replacement.

AWS’s cost guidance illustrates why this normalized view matters: OpenSearch charges can include instance hours, storage, data transfer, and optional UltraWarm, while S3 Vectors uses storage and request-oriented pricing and can also incur index-management and data-transfer costs.^[4] S3 pricing likewise lists storage, requests, retrieval, transfer, management, replication, and query or transform features as separate cost components.^[3]

For a multi-service design, keep a copy ledger. An export from S3 Vectors to OpenSearch Serverless is a copy rather than a move; AWS says the data remains in S3 Vectors, so both services are charged during that period. The export is point-in-time and does not stay synchronized automatically.^[2] That makes dual-copy duration and re-export frequency first-class inputs in a tiered vector storage cost model.

Worked cost example

Assume a RAG corpus has 100 million vectors at 768 dimensions. The following table is an original planning example. The rates are deliberately labeled illustrative assumptions; they are not vendor quotes and should be replaced with region-specific price sheets or invoices.

Under these assumptions, keeping all 995.328 GB in the hot tier would cost about $597.20/month for storage alone. The 20/30/50 split costs about $194.09/month, a storage-only reduction of $403.11, or roughly 67.5%. That percentage is an output of the chosen assumptions, not a general promise about tiering savings.

Now add the workload instead of hiding it. Suppose one million vector searches occur each month: 800,000 hot, 150,000 warm, and 50,000 cold. For a simple planning sensitivity, assume request-equivalent costs of $0.04, $0.06, and $0.10 per 1,000 queries respectively. The request estimate is $32 + $9 + $5 = $46/month. Add an illustrative $20 migration and reheat allowance and $30 for a month with dual-copy overlap. The tiered planning total is then $194.09 + $46 + $20 + $30 = $290.09/month before application compute, egress, backups, and support.

An all-hot comparison with the same illustrative hot request rate is $597.20 + $40 = $637.20/month. The modeled difference is $347.11/month, or about 54.5%. It is lower than the storage-only percentage because cold queries, migration, and overlap add cost. If the cold tier causes retries or fan-out, the request line can grow quickly and erase the modeled benefit.

Use binary units consistently when a provider bills in GiB. AWS notes that S3 usage is calculated in binary gigabytes, where 1 GB is 2³⁰ bytes, so a spreadsheet that mixes decimal GB with GiB can create a roughly 7.4% capacity mismatch before any index overhead is considered.^[3]

Protect retrieval SLOs while demoting data

A tier policy should be expressed as a routing policy, not just a storage ratio. For a user-facing RAG request, query hot first only if the product can tolerate reduced recall. Otherwise query hot and warm in parallel, merge candidates, and reserve cold search for a fallback or explicitly archival intent. Record the extra latency and result count from each path.

Set an admission test before moving a collection. Run a representative query set against the target tier and compare recall@k, empty-result rate, filter correctness, freshness, p95, and p99. Include updates and deletes if the corpus is mutable. AWS’s S3 Vectors integration documentation warns that an OpenSearch export is point-in-time and not automatically synchronized, so a mutable corpus needs an explicit refresh or reconciliation process.^[2]

Warm and cold are also operational states. A cold index may need activation, cache warming, or rehydration. A vector that becomes popular again should not bounce between tiers every few hours. Add a minimum dwell time, a promotion threshold, and a cooldown period. Keep a migration ledger with the source tier, destination, batch ID, checksum or count validation, start and completion time, and deletion confirmation.

Compression can lower memory and disk use, but it can change recall. If the hot tier uses product or scalar quantization while the cold tier retains float32, compare result quality across tiers rather than assuming the same top-k order. If you use disk-based vector search, price the I/O and cache behavior as part of the warm-tier test. The relevant question is not “which tier is cheapest per GB?” but “what is the lowest fully loaded cost per successful retrieval at the required SLO?”

For a fuller RAG budget, pair this guide with the model pricing comparison when embedding, reranking, or generation charges are part of the same request. Use the AI API invoice reconciliation calculator when the deployment is live and actual provider rows need to be compared with the model. If the retrieval tier changes the number of tokens sent to the model, include that downstream effect rather than treating vector storage as isolated.

What to exclude or label separately

Do not hide embedding generation, ingestion workers, index builds, backup retention, observability, network transfer, or incident capacity inside a storage-only number. S3 pricing explicitly separates storage from requests, retrieval, transfer, replication, and management features.^[3] For managed vector services, include minimum commitments and provisioned capacity where applicable. For self-hosted tiers, include nodes, disks, replicas, cross-zone transfer, upgrades, on-call time, and the opportunity cost of reserved capacity.

Do not use a vendor’s “up to” savings claim as your forecast. The S3 Vectors product page describes up to 90% reductions in some vector-storage scenarios, but the result depends on workload, query frequency, representation, and the comparison baseline.^[1] Your model should show the baseline, units, region, date checked, and every omitted meter. Re-run it after a pricing change, a vector-model migration, or a large shift in query concentration.

FAQ

Is hot, warm, and cold vector storage always cheaper than one hot index?

No. Tiering adds migration logic, routing, validation, possible dual copies, and sometimes extra query work. It tends to be attractive when a material share of vectors is retained but rarely queried. If nearly every vector is part of a low-latency request, the operational and query penalties can outweigh storage savings.

How do I choose the hot percentage?

Start with query traces rather than a fixed percentage. For each collection or tenant, calculate the share of vectors receiving queries and the share of total queries they represent over several representative windows. Select the smallest hot set that meets recall and p95/p99 targets, then test seasonal and worst-case traffic. Keep headroom for new documents and popularity spikes.

Should cold vectors be deleted from the hot index immediately after copying?

Only after validation and after the dual-copy window is acceptable for your recovery plan. Verify vector counts, IDs, dimensions, metadata filters, and representative search results. Record the deletion boundary. For systems with point-in-time exports, plan how updates made during export will be reconciled before treating the cold copy as complete.^[2]

Does vector compression reduce tiered storage cost?

Usually it reduces the stored representation or memory footprint, but it can add training, CPU, or quality costs. Measure recall@k and latency on the same evaluation set. A lower byte count is not a saving if compression causes extra reranking, more candidates, or repeated queries.

What should I put in a monthly tiering review?

Review capacity by tier, hot-hit rate, warm and cold query share, p95 and p99 by route, recall or empty-result rate, migration volume, dual-copy days, reheat events, transfer, request cost, and cost per successful retrieval. If cold usage rises or tail latency breaches the SLO, promote the affected collection and revisit the rule rather than defending the original ratio.