The 16.22% Reindex Break-Even Is Not Your Number

Before you build an incremental indexing pipeline, price one full reindex. That number gives you a threshold. If the chunks you rewrite in a single run exceed it, incremental indexing costs more than reindexing everything.

The 16.22% in the title belongs to an organization that has a parse cache and bulk import but no embedding cache. Drop either of the first two and the threshold climbs into the 50% or 90% range; add an embedding cache and it falls into the 3% range. Change the embedding price and it moves again. This post closes that value into three ratios and shows you how to read all three off a vendor price list.

Card drawers cost nothing to search, but a vector database bills for queries too. This post covers indexing cost only, not query cost.

Parsing Costs 656× Bulk Import, and It Is the One Step You Can Skip

The unit of calculation is one million chunks. Multiply by your chunk count to get your corpus’s usage. Parsing splits its rate at one million pages per month, though, and your invoice carries a plan minimum on top of that.

Fix the assumptions first.

Of these, T, C, V, and metadata size are assumptions. When you have a parse cache and no embedding cache, the two that move the threshold are C and metadata size; T and V cancel between numerator and denominator and do not shift it by a single digit. Without a parse cache, parsing attaches per page, so T and V enter the threshold too. With both a parse cache and an embedding cache, the threshold collapses to c alone and none of the four move it.

All four always move the total when you count your corpus in pages.

Three values derive from the assumptions.

net gain per chunk      = C − V = 448 tokens
chunks per page         = T ÷ (C − V) = 500 / 448 = 1.116071
pages per chunk         = (C − V) ÷ T = 448 / 500 = 0.896
embedding tokens / page = T ÷ (C − V) × C = 1.116071 × 512 = 571.4286

Overlap means you embed 1.1429× more tokens than the source contains. Push overlap to 128 and it becomes 1.3333×. Overlap inflates the per-page invoice but leaves the per-chunk rate untouched.

Here is what each operation costs per million chunks.

Parsing is the expensive one. That rate covers the first million pages per month; past that it is $0.60/1,000, so the parsing row converges toward $537.60 as the excess volume grows. In either band, parsing exceeds the $110.592 of everything else combined.

Parsing can be skipped whenever the source document has not changed. If the chunk text is unchanged, embedding can be skipped the same way; chunking and writing cannot. The embedding-skipping path is carried all the way to the threshold by the closed-form callout below.

Take out the scribe, and take out the free scissors work, and four bars remain.

Embedding rates span 10×, from $0.02 to $0.20 (OpenAI $0.02, Gemini $0.20, both accessed 2026-08-24). This post uses the low end, which shrinks the embedding term and lowers the threshold — a direction that favors full reindexing. The high-end result is in the sensitivity table.

At the Same Change Rate, the Parse Cache and the Load Path Flip the Answer

Pinecone’s docs state, “You can’t import data into an existing namespace” (import docs, accessed 2026-08-24). Bulk import only goes into an empty namespace. A full reindex that loads everything into a new namespace and then repoints the application can use that path; incremental indexing, which swaps some records inside an existing namespace, cannot.

The two methods are not the same work at different volumes. They pay different rates. What incremental saves is volume; what full reindexing saves is rate.

Let q be the share of chunks rewritten in a single run. That gives three cases.

Units are dollars per million chunks. The incremental coefficient is the number you multiply by q to get one incremental run. At the same corpus and the same change rate, three organizations scatter across these three rows and the threshold spreads 5.89×. An organization with an embedding cache is off this table entirely, because its one full reindex depends on q; the next section derives that threshold.

The case 3 threshold moves with the parsing rate band and the chunking assumptions. Under one million pages per month, swinging T between 300 and 1,200 gives 90.01% to 97.26%; in the $0.60/1,000 band it gives 78.82% to 93.47%. Raising V to 128 gives 94.83% at T = 500, and combining T = 1,200 with the excess band brings it down to 76.29%. If your q sits below that floor of 76.29%, the conclusion that incremental wins holds at any of these values; above it, you have to rerun the number with your own T and V.

All Ten Sensitivity Rows Close Into One Formula of Three Ratios

Move the card size, the drawer price, and the coordinate price one at a time. The baseline is case 1’s 16.22%.

The $4.50 WU top rate is on Pinecone pricing and the 3-large $0.13/1M is on OpenAI pricing, both accessed 2026-08-24.

What splits this table top from bottom is one thing: how expensive embedding is relative to writing. That is the ρ in the closed-form callout below, and all ten rows are the result of holding π at 0 and moving only ρ and c. The three rows that change the WU rate or the new-write share, plus the KB convention row, change the normalizing denominator itself, so ρ and c move together.

Add an embedding cache and ρ drops out of the formula, folding this table from 10.14–62.20% into 2.78–6.25% (the closed-form callout below derives it). Six of the ten rows collapse onto the single point 3.125%, and the four that remain are the ones that change c itself. The no-metadata row changes the denominator but bulk import falls by the same proportion, so c is unchanged and it stays with the six.

The Batch API applies equally to full reindexing and incremental. OpenAI’s batch docs (accessed 2026-08-25) state that /v1/embeddings supports batch and that the discount is a “50% cost discount compared to synchronous APIs.” There is no batch rate row for embedding models on the price list, so that phrase is the only basis for this row.

The completion window is fixed at 24 hours, so neither side can use it if your freshness requirement is shorter than a day.

The sensitivity table moves one lever at a time. Stack them and you leave the table. Batch together with C = 256 gives 6.77%.

If what raises the threshold is the embedding rate, the prize rises with it. One full reindex is the ceiling on per-run savings, so an organization paying $0.20 for embedding has a high threshold at 62.20% but a ceiling of $104.448 per million chunks, 8.5× the baseline. Easy to sit below the threshold, and a large prize when you do. An organization that lightened its records to raise the threshold gets the opposite: a lower ceiling.

Add an embedding cache and this prize collapses too. The ceiling on per-run savings falls from (c + ρ) to c, one sixth of it at baseline, and the path of growing the prize through the embedding rate disappears.

q* = (π + c + ρ) / (π + 1 + ρ)
incremental write cost = actual incremental write cost   $0.000065536/record at baseline (all overwrites)
π = parsing ÷ incremental write     0 with a cache, 20.51 at baseline without one
c = full-reindex write ÷ incremental write   bulk import 0.03125, new write 0.5, in-place only 1
ρ = embedding ÷ incremental write   (chunk tokens × embedding rate) ÷ incremental write, baseline 0.15625

Measure the Rewritten-Chunk Share, Not the Document Change Rate

Insert one sentence at the front of a book and every card behind it shifts. Under fixed-size chunking, identical text still gets re-embedded and rewritten because the chunk boundaries moved. Changing a single character turning half a document into new chunks is normal behavior. So r and q are not the same number.

The parenthetical on the second row and the third row use P = 10, and the third row’s k is 2. r is the share of documents that change between runs, P is chunks per document, and k is the number of chunks rewritten on each side of an edit point. The same organization at the same change rate sees r* spread 5× depending on which pipeline it runs. r* is your own q* times 1, times 2P/(P+1), and times P/k respectively, so for any combination other than the two right-hand columns, put your own q* through those multipliers.

Changing the chunking method moves every boundary, so price one full re-embedding of the corpus — one full reindex — plus the implementation effort before you do it.

P determines the order of the three rows. Content-defined’s r × k/P only falls below fixed-size’s r(P+1)/(2P) when P > 2k − 1. On the content-defined row, incremental wins when P > k × r ÷ q*, so in case 1 with k = 2 and r = 35%, chunks per document must exceed 4.32 — and 22.4 if you have an embedding cache. Set r to 100% and the condition reduces to P > k ÷ q*, so in case 1 without a cache and k = 2, an organization with more than 12.33 chunks per document wins with incremental at any document change rate. That organization measures neither q nor r.

On the fixed-size row, q cannot go below r/2, so once r exceeds the table’s 32.43% (6.25% with an embedding cache), q stays above the threshold no matter what P is. Since k and P are set by your chunking implementation, put your values into both q formulas — r(P+1)/(2P) from the table and r × k/P from the paragraph above — and use the lower result.

In a DB That Can Only Write In Place, the Threshold Rises to 100%

Everything so far sits on Pinecone’s price list. Even without bulk import, a full reindex can still use new writes into an empty namespace, which leaves case 2’s threshold of 56.76%. The threshold only truly disappears in a DB where wheeling in a fresh empty cabinet is impossible and you must write in place. There the two values converge at $75.776.

That condition splits inside Pinecone too. Bulk import is Standard-plan-and-above only, and Standard requires “$50/month min. usage” (Pinecone pricing, accessed 2026-08-24).

What bulk import earns is $43.008 − $12.288 = $30.720 per million chunks.

The minimum usage is not an extra charge; it is a floor. Two boundaries split the range into three. Below 18.31 million reindexed chunks per year, your invoice is the same whether or not you use bulk import; above 292.97 million, the full $30.720 per million chunks shows up. An organization in between that plugs in the full amount overstates its savings.

This post’s model assumes a managed vector DB that meters writes. On pgvector or a self-hosted Qdrant, where there is no write rate, c is undefined and the comparison axis becomes instance cost and operational effort.

Measure Wall-Clock First, but the Cache Moves the Embedding Wall

The machine that writes coordinates has a throughput ceiling.

OpenAI’s text-embedding-3-small has tokens-per-minute limits by usage tier (model docs, accessed 2026-08-24). At 571.4286 embedding tokens per page, that ceiling converts to pages.

If you embed everything every run, even the highest tier tops out at 1.05 million pages for a corpus that can meet a one-hour freshness requirement by full reindexing. Above that, no budget meets the cycle.

The last column is the full-reindex invoice if you ran the embedding machine nonstop all year. One full reindex scales with chunk count and so does wall-clock time, so multiplying by annual run count cancels the chunk count. That makes this ceiling independent of corpus size, set only by tier and case. Annual savings cannot exceed it even if incremental were free, which makes it the first yardstick for the cost of building an incremental pipeline.

This table assumes the full reindex embeds everything every run. With an embedding cache the ceiling is undefined, because the chunk count no longer cancels: the ceiling becomes proportional to c ÷ q + ρ and diverges as q shrinks.

Hold up the yardstick and one band closes. For a Tier 1·2, case 1 organization with no embedding cache, annual savings cannot exceed $12,614 at any corpus size, and what comes out of that is not a threshold but an effort budget.

allowed build effort M = (ceiling on S − m × W) × target payback years ÷ W

There are two ceilings stacked here. The tier ceiling assumes embedding runs all year, so any corpus’s annual full-reindex cost is below it, and S is below that again. When budgeting your own effort, use the tighter one — your own annual full-reindex cost (step 5 of the decision table below is that value). Use the tier ceiling only for conclusions that hold regardless of corpus. What follows is the latter.

Put maintenance effort m = 12 person-days and labor W = $500/person-day against the Tier 1·2, case 1 tier ceiling and you get 52.9 person-days at a four-year payback, 39.7 at three years. The 12 person-days and $500/person-day, and the 60 person-days of build below, come from example B further down. Tier 1·2 is an assumption made only for this calculation, not taken from example B, which is Tier 5.

A ceiling is a ceiling, so an organization that does not run its embedding machine all year — that is, one whose actual annual full-reindex spend is lower — saves less and gets a stronger version of the conclusion. For a Tier 1·2, case 1 organization with no embedding cache, at example B’s 12 person-days of maintenance and W = $500/person-day, no corpus size and no q, not even q = 0, recovers that 60 person-day build within four years. Raising your tier or cutting build scope inside this budget comes before measuring q.

With a cache, as noted above, this ceiling is undefined, so use your own annual full-reindex cost.

The values themselves use case 1 rates ($12.288 per million chunks). Case 2 is 3.500× that, and case 3 is 44.8× (Tier 5) to 45.6× (Tier 1·2). The reason it is not the 110.375× you get by dividing the case table’s $1,356.288 directly is that this ceiling is the volume of embedding running all year, so parsing exceeds 76.65 million pages per month and at least 98.7% of it lands in the $0.60/1,000 band. The first million pages stay at $1.50, which is why the effective rate differs by tier. Multiply your own case’s one full reindex by (525,600 ÷ wall-clock minutes) to get your own ceiling.

Two of Three Organizations Should Not Build It, for Different Reasons

Whether you clear the threshold and whether you build the pipeline are different questions. The first is about a ratio; the second is about an absolute amount. Not how many cards you save, but whether that money is worth attaching a person to. What to look at first is not the threshold but annual savings.

Without an embedding cache, B’s wall-clock time of 171.43 minutes makes three hours the shortest possible full-reindex cycle, while incremental runs hourly as required. Because the two run at different frequencies, the usage multiple of 432.43 does not equal threshold ÷ q. Those two match only when both run on the same cycle.

The last row is the actual invoice. Pinecone’s $600 annual minimum applies only to vector DB spend, not to the embedding bill. For A, both methods fall below it, so the $21.62 difference disappears; for B only the incremental side is below, cutting savings by $359.73; for C only the full-reindex side is below, raising that invoice and shrinking the loss by $266.29.

Payback comes from this formula.

payback days = build effort M × W ÷ (annual savings S − maintenance effort m × W) × 365

M is build effort, m is maintenance effort, and W is the loaded cost of one engineer-day. This is the allowed-build-effort formula from the previous section rewritten as payback days. Lacking primary data on all three, they stay parameters. The values the examples below use are assumptions. The existence condition is S > m × W; fail it and payback days go negative or infinite.

If you have not measured q yet, substitute annual full-reindex cost for S. Incremental cost is at least 0, so that value is the ceiling on S, and if payback fails even at the ceiling you do not need to measure q.

payback = 30,000 ÷ (117,716.73 − 6,000) × 365 =  98.0 days   pre-cache, 3-hour baseline
          30,000 ÷ ( 59,468.34 − 6,000) × 365 = 205 days     cached hourly (best alternative)
          build 60 person-days   savings (incl. weekly full reindex)   maintenance 12 person-days, W = $500/person-day

The objection that “embedding is cheap anyway, so does this calculation matter” is exactly right for example A, and that is one of this post’s conclusions.

The embedding rate attaches identically to full reindexing and incremental and cancels, so the rate difference that separates the two methods is $63.488 per million chunks where bulk import is available, or half that, $32.768, in case 2 — entirely writes. That is why which drawer you put the card in, the write path available to the full reindex, sets the threshold’s floor in a parse-cached configuration.

In example A’s full-reindex usage, embedding is 83%, and 93% of the $315.96 usage difference is also the embedding portion. That is not a contradiction. In a configuration with a parse cache and bulk import, the term that dominates the dollar amount is embedding, and the term that dominates the rate difference setting the floor is, in every case, writes.

When the total is small, there is no reason to act on that answer at all. An organization whose annual indexing cost does not exceed its maintenance labor is right not to build an incremental pipeline.

If the First Five Steps Settle It, You Never Measure q

The decision table has seven steps, and the one place judgment ends without q is step 5. Steps 2 and 3 change π and c; step 4 shrinks the full reindex’s embedding term by a factor of q and changes the q* formula itself to (π + c) ÷ (π + 1). Cost settles the question at steps 5, 6, and 7; step 1 renders no verdict at all and routes you through steps 2 and 3 to step 4 or to the wall-clock trap. Example A stops at 5 and example C at 6, while example B moves step 1’s wall with a cache and runs all the way to 7.

Get your own q* by putting π, c, and ρ into the formula in the closed-form callout above. One full reindex and the incremental coefficient come from multiplying the case table’s per-million-chunk values by your chunk count. Wheel in the whole cabinet and it is the import cost; if you cannot, it is the cost of new writes into empty drawers. In example A that difference separates $294.34 in savings from $655.43.

If you attached an embedding cache at step 4, your q* is the same callout’s (π + c) ÷ (π + 1), and one full reindex is not the case table value but full-reindex write cost + embedding cost × q. Step 5 comes before q, so if you do not know q yet, use the case table value as is. The cache only lowers that value, so it remains valid as a ceiling.

Step 4’s gate is the same ceiling treatment as step 5. Annual embedding spend is the ceiling on savings, so failing there means definitely not attaching it, and passing means checking again whether q narrows savings to spend × (1 − q). Even an organization whose judgment ends at step 5 and never reaches step 6 can narrow the cache gate that way. This gate is a necessary condition that looks only at maintenance effort, so whether you actually attach it comes from putting the cache’s build and maintenance effort into the payback formula above.

S is (one full reindex × annual full-reindex runs) − (one incremental run × annual incremental runs). Run both on the same cycle and it reduces to (one full reindex − one incremental run) × annual runs, and the gain multiple is one full reindex ÷ one incremental run. That equals q* ÷ q only without an embedding cache. On different cycles, multiply by the ratio of annual run counts.

Even if you choose incremental, the periodic full reindex remains, so S cannot exceed step 5’s ceiling (annual full-reindex cost) times (1 − periodic full-reindex runs ÷ annual full-reindex runs). For an organization that indexed once a day and adds a weekly, 85.8% of that ceiling is the real limit.

If your plan has a minimum usage, one step goes in front of that S formula. Replace each side’s vector DB spend with max(usage, minimum usage), add embedding spend, and use the difference as S. What goes into that max is total vector DB spend, not index writes.

The three examples above were computed on index writes alone, so adding index storage cost moves B and C (A stays put, since both sides are below the floor). For example B, adding $108.62/year (27.429 GB × $0.33/GB/month × 12 months) to the incremental side still leaves $348.89, below the floor, so savings rise to $119,608.21; for example C the incremental side crosses the floor and the loss grows to $2,067.51. Query spend or other indexes move it further in the same direction, and for an organization already above the floor this correction disappears entirely.

When the floor catches the incremental side, S shrinks; when it catches the full-reindex side, S grows. Example C is the latter, so its loss shrinks from $2,319.32 to $2,053.03.

Step 5 produces an answer independent of q, so small organizations finish here. In case 1, indexing once a day with 2 person-days of annual maintenance (W = $400/person-day), a corpus under 178,368 chunks on a usage basis cannot pay for incremental maintenance even at q = 0. If you attached an embedding cache at step 4, one full reindex is import cost only and that boundary rises to about 1.07 million.

With a minimum usage, that no-cache 178,368 boundary rises further. Below 802,654 chunks, the full-reindex vector DB spend sits under the $600 annual floor. If the incremental side is below it too, that difference disappears from both invoices and the savings that remain are the embedding portion. The boundary for that band is 214,041. Example A’s 80,357 is inside it, and for organizations like that, measuring neither the threshold nor q is the right call.

Here is what was left out of the calculation.

Of the four that push up, namespace coexistence and teardown are capped inside the $2.048 per million chunks of import cost. Storage has no rate obtained, but at 8.192 GB per million chunks, anything under $0.25/GB puts that term inside $2.048 as well. Embedding cache storage also comes to $0.07 per run for an organization indexing once a day, inside that cap, but invalidation effort has no ceiling — and that term attaches only to the cached threshold, so it does not enter 16.22%.

There is no ceiling on the side that pushes down. Orphan vectors are actual spend that an organization choosing incremental has to stack a periodic full reindex on top of, and an embedding model change is not an amount but an operation incremental cannot perform.

If the storage rate is under $0.25/GB, putting all three of the up-pushing terms that attach to 16.22% inside $2.048, then the net effect of the excluded items is downward — toward full reindexing — and this post’s threshold is generous to incremental. At the cached threshold, the up-pushing side also carries a term with no ceiling (invalidation effort), so the net effect is undetermined. How often you change model, dimensions, or chunking parameters sets the size of that term.

Swapping the whole cabinet changes the failure mode. Because the index switches over wholesale, an error in the parsing or embedding stage shows up as simultaneous contamination of the entire corpus rather than degradation of a few documents. Incremental keeps the same error local.

This burden does not go into M in the payback formula. Even if you choose incremental you still run periodic full reindexes, so the namespace swap procedure, cutover validation, and rollback procedure are needed either way. It cancels in the payback calculation, and what remains is only that a full-reindex-only configuration experiences it as often as it runs.

The last table row is large too. Change the embedding model and every existing vector becomes meaningless, so the whole corpus has to be re-embedded. An organization with only an incremental pipeline has to build a full-reindex path in a hurry at that moment. That is why you do not discard the full-reindex path even after building incremental.

This post’s threshold sits on Pinecone’s price list and OpenAI’s rates. Change those values and 16.22% changes. What does not change is the structure. The cheapest cabinet price a full reindex can use is below the price of swapping a card, and that gap creates the threshold’s floor; make that path identical to incremental’s and the floor rises to 100% and the threshold disappears.

How far above the floor you land is set by ρ, and π narrows that range. With a parse cache the floor drops to c; with an embedding cache ρ disappears and the threshold is the floor itself. With both, the floor is c and that is the threshold.

All three of π, c, and ρ are on vendor price lists. How often your documents change is the question after that.