Research-backed calculator guide

Zero-Downtime Vector Index Refresh Cost: Dual-Write, Shadow-Read and Cutover

Estimate the temporary storage, embedding, backfill, dual-write, shadow-read, validation, and rollback cost of refreshing a vector index without taking production retrieval offline.

What creates the cost in a zero-downtime refresh?

A refresh is not one operation. It is a period in which the system must preserve serving continuity while the replacement becomes trustworthy.

Re-embedding is the cost of producing new vectors from the source text. It applies when the embedding model, dimensions, normalization, chunking, or source representation changes. If the model is unchanged and only the index structure is being rebuilt, set re-embedding cost to zero and retain the backfill or index-build term.

Backfill compute and writes cover reading source records, generating or loading vectors, batching them, and writing them into the new index. A provider may meter requests, compute, write units, provisioned capacity, or a combination. Use the provider’s actual billing unit in your workbook. Do not multiply a quoted hourly rate by wall-clock hours unless that rate really applies to the resources used.

Dual-write overhead starts when new or changed source records must reach both generations. Without it, the replacement can finish with a stale tail and cut over to an index that is missing recent documents. Some systems may offer a source-of-truth sync or a managed refresh instead. Treat dual-write as an application and capacity decision, not a universal vendor feature.

Overlap storage is the temporary capacity for the replacement index, its metadata, and any staging files. For sizing, you need the old and new copies at once. For incremental cost, the old copy is often baseline spend and the new copy is the temporary addition. If your service bills the old copy differently during migration, model both explicitly.

Shadow reads send a sample of production queries to the candidate without using its result for the user response. They can reveal recall, filter, latency, or ranking regressions. They also consume query capacity and can increase embedding-query cost if the candidate needs separately generated query vectors.

Rollback reserve is the cost of retaining the old index after cutover. Deleting it immediately lowers storage, but it turns a quality or consistency regression into a rebuild. A short retention window is a risk decision, not a fixed technical requirement.

A provider-neutral cost model

Let the following inputs be measured for one refresh:

• N: source chunks or records that must be re-embedded or backfilled.
• T: average input tokens per record for the embedding call.
• P_e: assumed embedding price per 1,000 input tokens, or the equivalent internal unit cost.
• C_b: backfill compute and write cost.
• W_d: new or changed records arriving during the refresh.
• P_w: incremental cost per dual-written record, including any embedding or write meter that is not already in C_b.
• S_n: estimated storage footprint of the replacement index in GB, including index overhead and metadata.
• P_s: storage price per GB-month.
• H_o: hours that old and new indexes overlap.
• C_sh: extra shadow-read or candidate-query cost.
• C_rb: storage and capacity reserved for rollback after cutover.

A practical estimate is:

C_refresh = (N × T ÷ 1,000 × P_e) + C_b + (W_d × P_w) + (S_n × H_o ÷ 720 × P_s) + C_sh + C_rb.

The 720-hour month is an assumption for a 30-day month. Replace it with the period your finance model uses. If a provider bills storage in GiB-month, use GiB and that unit instead of silently converting to decimal GB. If embedding prices are per million tokens, change the denominator to 1,000,000. Keep units visible so a plausible-looking answer does not hide a 1,000× error.

For capacity, use a different equation:

peak refresh capacity = old serving footprint + new build footprint + dual-write headroom + shadow-read headroom + safety margin.

Cost and capacity are related but not interchangeable. A managed service can charge little incremental storage while still throttling the build because its indexing pool is busy. BigQuery’s documentation, for example, exposes index readiness through last_refresh_time and coverage_percentage, and explains that indexing is asynchronous ^[1]. Those are operational signals to put beside cost, not dollar inputs by themselves.

Worked cost example

Assume a production RAG corpus with 12,000,000 chunks. The refresh changes the embedding model, so every chunk gets a replacement vector. The team wants the candidate ready within an 18-hour overlap window and retains the previous index for another 24 hours after cutover.

The following table is an original estimate. Every price is an assumption for demonstrating the method, not a provider quote. Replace each rate with the rate on your invoice or contract.

The total above is $87.10, not $94, because the dual-write line is shown separately at its measured tail volume. If your migration also incurs a separate $6.72 candidate-query-vector generation charge—say, 500,000 queries at an assumed $0.00001344 per query—the all-in planning estimate becomes $93.82, which rounds to $94. Keeping that optional line visible is better than burying it in a vague “shadow read” multiplier.

The raw vector footprint check is also useful. A 1,536-dimensional float32 vector uses 1,536 × 4 = 6,144 bytes before metadata, graph structures, replicas, and service overhead. For 12 million vectors, that is about 73.7 GB using decimal bytes. The example’s 118 GB replacement estimate therefore implies roughly 1.6× overhead. That factor is a planning assumption, not a universal vector-database constant. If the system keeps two replicas, uses larger storage types, or stores substantial metadata, the replacement footprint can be materially higher.

To extend this estimate, start with the RAG, embedding and vector database cost calculator for corpus and retrieval inputs. Use the model pricing comparison when the refresh changes the embedding model or adds a reranker, and use the AI API invoice reconciliation calculator to compare the estimate with billed usage after the migration. If the refresh also changes a self-hosted embedding service, the self-hosted GPU inference cost calculator can model that separate capacity decision.

For a safe capacity plan, provision for the old 118 GB plus the new 118 GB, then add headroom. At 20% headroom, the temporary storage target is 236 × 1.20 = 283.2 GB. The incremental bill is not necessarily priced on all 283.2 GB, because the old index may already be in baseline spend and headroom may be reserved rather than consumed. The capacity number still matters: an under-sized service can make a supposedly zero-downtime refresh compete with live queries.

How dual-write, shadow-read, and cutover change the estimate

Dual-write. Start dual-writing before the candidate becomes queryable if the backfill is long enough for new source records to arrive. Record a source event ID, source version, or monotonic change token with each write. At cutover, calculate the tail lag rather than assuming the two indexes are equal. Your cost sheet should include both the count of extra writes and the capacity headroom needed to absorb them. If each record is re-embedded twice, separate the second embedding call from the write fee; otherwise the same cost can be counted twice or omitted.

Shadow-read. A shadow sample is not free merely because users receive the old answer. It can double or partially double query work, and the candidate may need a separate query embedding. Choose a sampling rate based on risk and traffic shape. A 1% sample of 50 million monthly queries is 500,000 candidate reads. A 10% sample is 5 million. The difference belongs in the budget. Compare not only top-k overlap but also filter correctness, empty-result rate, p95 latency, and downstream answer quality.

Cutover. The final switch should be small, observable, and reversible. A stable alias, routing key, namespace target, or application configuration can hide the physical index name from callers, but the exact mechanism is provider-specific. Azure’s guidance explicitly recommends a side-by-side replacement and an index alias for production schema changes ^[4]. Pinecone’s documentation shows that index schema characteristics are established at creation and describes namespace aliases for stable namespace naming ^[3]. Do not assume a namespace alias is the same as an index alias.

Before switching, freeze the candidate’s quality report, confirm its coverage, replay changes after the last backfill checkpoint, and verify that reads and writes agree on the same source version. During cutover, monitor error rate, p95 latency, result-count changes, and the percentage of traffic reaching each generation. Keep the old index until the agreed rollback window ends. Google’s BigQuery material describes model rebuilds without index downtime, but its managed behavior should not be generalized into a promise about every vector provider ^[2].

What to exclude from the refresh estimate

Do not present a temporary-index estimate as the total business cost. Add these items only when you can measure them:

• Engineering time for pipeline changes, replay logic, dashboards, and on-call coverage.
• Egress and cross-region transfer when the new index is built in another region or service.
• Provider minimum commitments, reserved capacity, or a new endpoint that remains after cutover.
• Evaluation-set generation, human review, reranker calls, and LLM answer-quality tests.
• Incident cost if the old index must be retained longer than planned.
• Downtime or degraded-retrieval exposure. Zero downtime reduces this risk; it does not make the risk worth zero dollars.

The most defensible article or internal workbook labels each input as measured, quoted, or assumed. A vendor price is a quote only when it came from your dated contract, invoice, or current official pricing page. The table above uses assumptions so the arithmetic can be inspected without pretending to know your provider, tier, region, replication factor, or traffic.

FAQ

What is the cheapest way to refresh a vector index without downtime?

The cheapest safe design depends on what changed. If only the ANN structure needs rebuilding and the provider can maintain it in place, re-embedding may be avoided. If the embedding model or dimensions change, a side-by-side candidate normally requires a second footprint for some period. Reduce cost by shrinking the overlap window without skipping validation, sampling shadow reads intelligently, batching writes, and deleting the old copy only after the rollback decision is explicit. Do not remove the safety copy merely to make the spreadsheet look cheaper.

Does zero-downtime refresh always require dual writes?

No. Dual writes are one way to keep a long-running candidate current while the source continues to change. A provider-managed asynchronous refresh, change-data-capture replay, write pause measured in seconds, or a source snapshot plus final delta replay may be sufficient in another architecture. The requirement is consistency at cutover, not the name of the mechanism. If the candidate is built from a stale snapshot and no tail reconciliation exists, it can miss documents even though the service never stopped serving.

Should I count the old index as a second monthly storage charge?

Count it in peak capacity, but count only incremental dollars in the refresh line when the old index was already part of baseline spend. For a before-versus-after business case, show both views: peak footprint is old plus new plus headroom; incremental refresh cost is the replacement storage during overlap plus any extra rollback retention. This avoids understating the capacity request or overstating the new monthly run rate.

How much shadow traffic is enough?

There is no universal percentage. Start with a sample large enough to cover important tenants, filters, languages, and query classes, then compare candidate and control results. For a simple planning sheet, calculate monthly queries × shadow rate and price that volume separately. Increase the sample when the refresh changes dimensions, chunking, metadata filters, or ranking behavior. Treat p95 latency and error rate as acceptance gates, not merely observations.

When can I delete the old vector index?

Delete it after the candidate has passed coverage, consistency, quality, and latency checks and the rollback window has expired. The window should reflect how quickly you can detect a regression and how costly a rebuild would be. If a provider offers an atomic swap or alias, that can shorten the read cutover, but it does not eliminate the need to decide how long the old generation remains available. Keep a source snapshot or reproducible build inputs even after deleting the old serving copy.