Research-backed calculator guide

Embedding Model Migration Cost Calculator: Dual-Index Backfill and Cutover

Estimate embedding migration cost, overlap days, backfill time, dual-write overhead, rollback reserve, and the safe point to delete the old vector index.

Changing an embedding model is not a one-line configuration change when vectors are already serving production search. It is a data migration: the new model creates a different vector space, the corpus must be embedded again, and the old index usually remains live until the replacement passes quality and freshness checks.

migration cost = embedding backfill
               + new-index build/write cost
               + dual-index overlap cost
               + dual-write and replay cost
               + evaluation and rollback reserve

Do not mix old and new vectors in one search space merely because the dimensions happen to match. OpenAI describes an embedding as a vector whose distance measures relatedness and bills embedding requests by input tokens; its documentation also gives model-specific default dimensions, such as 1,536 for text-embedding-3-small and 3,072 for text-embedding-3-large ^[1]. A changed model or dimension therefore changes both the embedding bill and the storage/index shape.

What a dual-index migration includes

A safe migration has an old production index and a new candidate index. The old index continues to answer user queries while the new one is created with the new model’s dimensions, distance metric, metadata schema, and permissions. New creates, updates, and deletes then need a deliberate synchronization policy. That may be dual writes, a change log replay, incremental sync from a checkpoint, or a short write pause. The choice changes cost and risk, so record it as an input rather than hiding it in a general “reindex” line.

The backfill should read the original text or another source of truth, not try to convert old vectors into new ones. For every chunk, retain a stable source ID, chunk ID, model version, token count, and migration generation. Make the job resumable and idempotent. If a worker retries a chunk, the second upsert should replace the same candidate record rather than create a duplicate.

A production cutover has at least four gates:

• Completeness: every expected source record has a current candidate vector, with failed and skipped records accounted for.
• Freshness: changes that arrived during backfill have been applied to the candidate index.
• Quality: a held-out query set compares recall, precision, MRR, nDCG, answer grounding, or the metric that represents your search job.
• Rollback: the old index is still queryable, and routing can move back without rebuilding the corpus.

Qdrant’s migration tutorial, for example, describes blue-green collections with dual writes and background re-embedding, while also noting duplicated payload storage and extra logic for deletes or partial updates. That product-specific procedure is useful evidence for the work involved, but its resource model is not a universal price quote. Treat your own vector service’s storage, write, read, and egress meters as separate lines.

Worked cost example: 12 million chunks and a 21-day overlap

Assume a US production RAG system has 12,000,000 chunks. Each chunk averages 420 input tokens, so the backfill contains:

5,040,000,000 input tokens
= 12,000,000 × 420

For this planning scenario, use an illustrative embedding rate of $0.10 per million input tokens. This is an assumption, not a current vendor quote. The arithmetic is:

standard backfill = 5,040 × $0.10 = $504

Suppose the team qualifies an asynchronous batch path at a 50% discount. OpenAI’s official Batch API documentation says its Batch API supports embedding repositories, has 50% lower costs than synchronous APIs, uses a separate rate-limit pool, and has a 24-hour completion window ^[2]. The scenario’s batch embedding line is therefore:

batch backfill = $504 × 0.50 = $252

That discount does not make the migration instantaneous. It also does not cover your vector database writes, storage, application compute, failed requests, evaluation, or the old index kept for rollback.

The table deliberately separates vendor billing rules from planning inputs. The 50% Batch adjustment is the documented product rule in the cited source, subject to model and account eligibility. The $0.10 per million embedding rate, 18,000 chunks/hour, $180/day old-index estimate, $240/day new-index estimate, and $350 evaluation reserve are scenario assumptions. Replace each with a measured or quoted value before approval.

The 27.8-day backfill exceeds the assumed 21-day overlap. That is a useful result, not a rounding problem: the team either needs more throughput, a longer overlap reserve, a smaller change window, or a different migration plan. If the backfill finishes in 28 days and the rollback grace period is seven days, the costed overlap is 35 days, not 21. In that case, the same storage assumptions produce $35 × ($180 + $240) = $14,700 of overlap rather than $8,820.

You can estimate vector bytes before database overhead with:

raw vector bytes = chunks × dimensions × bytes per component

If the new model outputs 1,536 dimensions and stores 32-bit floating-point values, the raw candidate vectors are:

12,000,000 × 1,536 × 4 bytes = 73,728,000,000 bytes
≈ 68.7 GiB before index graph, metadata, replicas, and provider overhead

That is not a bill. It is a lower-level footprint check. Index graphs, payloads, replicas, compression, replicas, and provider minimums can move the charged amount substantially. Google BigQuery’s vector-index documentation illustrates the same separation: index build and refresh use compute pricing in the applicable setup, while active index bytes incur active-storage cost and partially covered indexes are still charged for what has been indexed ^[3].

If your vector service provisions read capacity, price the overlap using its actual formula. Pinecone’s dedicated-read documentation gives an example structure of (node rate × shards × replicas) + storage + writes + egress, and explains that shards and replicas represent different capacity dimensions ^[4]. The migration implication is simple: two indexes can double more than just raw vector bytes if both need read capacity, write units, payloads, or egress.

Backfill time is a cost input

A cheap embedding pass can still be an expensive migration if it blocks a model retirement or forces a long period of duplicated serving infrastructure. Measure sustainable throughput under the same chunk size, request batch size, token mix, retry policy, and provider quota that production will use. Record both chunks per hour and tokens per minute. A chunk-rate-only estimate can be misleading when chunk lengths vary sharply.

Use a conservative completion formula:

backfill hours = total chunks ÷ sustainable chunks/hour × (1 + retry reserve)

For example, 12 million chunks at 18,000 per hour and a 12% retry reserve is approximately 12,000,000 ÷ 18,000 × 1.12 = 746.7 hours, or 31.1 days. Add a separate change-replay window if the source changes during the run. Do not count a provider’s maximum quota as sustainable throughput until a controlled test confirms it.

OpenAI’s Batch API can help with asynchronous embedding repositories and separate rate limits, but its documentation also states that a batch can contain up to 50,000 requests and that embedding batches are restricted to 50,000 embedding inputs across requests ^[2]. A large corpus therefore needs orchestration, checkpoints, error files, and reconciliation. Those operational rows belong in the migration ledger even when their direct API cost is small.

How to decide when the old index is safe to delete

Deletion is a release gate, not a calendar event. Keep the old index while any of these are unresolved:

• candidate coverage is below the source-of-truth count;
• dual writes or replay have an unprocessed backlog;
• query and document model versions do not match;
• quality has not cleared the agreed threshold across important query segments;
• latency, filter, permission, or empty-result checks are unstable;
• an incident cannot be rolled back by changing one route, alias, or feature flag; or
• the rollback grace period has not ended.

The old index’s deletion date should be the later of cutover + rollback days and last unresolved change + replay safety days. Record the reason for deletion and retain a snapshot or rebuild manifest if your recovery policy requires one. A smaller footprint after deletion is an outcome to verify, not an assumption to put into the initial forecast.

For a broader RAG estimate that includes ingestion, query embeddings, vector storage, reranking, and generation, use the RAG, embedding and vector database cost calculator. If the migration also changes an inference service, separate that scenario with the self-hosted GPU inference cost calculator. After cutover, compare forecast rows with actual provider usage through the AI API invoice reconciliation calculator, keeping model version, billing unit, region, and migration generation in each ledger row.

FAQ

Do I need a dual index when changing embedding models?

For production search, a dual index or an equivalent isolated vector space is the safer default because the candidate can be built and evaluated while the old index serves users. An in-place rewrite may be reasonable for a disposable prototype or a tiny index that can be rebuilt quickly. Make the choice based on downtime tolerance, rollback requirements, storage headroom, and the cost of a bad retrieval result.

Can old and new embeddings share one index if their dimensions match?

Matching dimensions do not make the vector spaces compatible. The query embedding and the document embeddings need to come from the same model and configuration for similarity scores to mean what your search assumes. If you intentionally store multiple representations, isolate them as named vectors or separate fields and select one representation per query path.

How do I calculate embedding reindex overlap cost?

Multiply the daily incremental cost of keeping the old and new footprints live by the number of overlap days, then add incremental writes, egress, dual-write embeddings, evaluation, and rollback reserves. Use actual provider meters where possible. A 21-day overlap at an estimated combined $420/day is $8,820, but that result changes if the backfill or rollback window extends.

Should I use Batch for a migration backfill?

Batch is a candidate for work that does not need immediate responses. The official documentation describes embedding repositories as a use case, a 50% cost discount relative to synchronous APIs, separate rate limits, and a 24-hour completion window ^[2]. Confirm that your model and account qualify, and still budget file creation, orchestration, retries, result reconciliation, and the time required to refresh the vector index.

What quality tests should block cutover?

Use a labeled or otherwise trusted query set and compare the old and new indexes on retrieval quality, not only final answer fluency. Segment by exact identifiers, long questions, languages, filters, tenants, and high-value workflows. Add shadow traffic where feasible. Block cutover when the candidate misses a required relevance, permission, latency, or grounding threshold even if the backfill is technically complete.

When can I delete the old vector index?

Delete it only after candidate completeness, change replay, quality, latency, permissions, and rollback checks pass and the agreed grace period ends. Keep the old index queryable for the period your incident response plan requires. The calculator should show this grace period as a costed input so a “safe to delete” decision is auditable.