Research-backed calculator guide

Incremental RAG Ingestion Cost: Full Refresh vs CDC vs Event-Driven Sync

Model incremental RAG ingestion cost across full refreshes, polling, CDC, and event-driven sync with a worked example for embeddings, vector writes, retries, and reconciliation.

What counts as RAG ingestion cost?

Separate the pipeline into meters before comparing architectures. The first meter is change detection. A polling job may scan a table, list files, call a source API, or compare modified timestamps. CDC uses a database log or change feed. Event-driven systems pay for publishing, delivery, queue retention, and consumers. The source system may also charge for reads or request units.

The second meter is changed-content processing. A changed document may be downloaded, parsed, cleaned, split into chunks, enriched with metadata, and sent to an embedding model. If a document update changes only one of 20 chunks, the ideal incremental path embeds one chunk, not all 20. That requires stable document and chunk identifiers plus a comparison method such as a content hash.

The third meter is index mutation. New chunks are inserted. Rewritten chunks are upserted or updated. Removed chunks need deletes or tombstones. Pinecone’s API documentation describes upsert as writing vectors and overwriting the previous value when the vector ID already exists. That means a stable ID can make an update idempotent, but the write still belongs in the cost model.^[3] Its update guide also notes that updates consume write units, so a metadata-only change and a new embedding should not be treated as the same operation.^[4]

The fourth meter is operations. Include the worker or container time, queue or stream retention, checkpoint storage, logs, metrics, dead-letter handling, and replay. Incremental RAG indexing cost is often understated when only embedding-token spend is counted. A low-volume event pipeline can have a higher fixed operating cost than a scheduled batch job.

Finally, include reconciliation. A source event can be delayed, duplicated, malformed, filtered incorrectly, or lost after an offset mistake. A periodic scan or source-to-index count comparison is the insurance premium for finding drift. It is not proof of perfect consistency, but it makes the estimate honest.

Full refresh vs. polling, CDC, and events

Full refresh

A full refresh reads and processes the complete corpus on every run. It is simple to reason about and useful after changing the embedding model, chunking rules, access-control metadata, or parser. Its monthly processed volume is approximately:

total documents × average chunks per document × refreshes per month.

The downside is predictable over-processing. If 1% of chunks changed, a monthly full rebuild still pays to process 100% unless the system has a separate unchanged-content cache. A full refresh also creates a large write burst and may require a dual-index or cutover plan.

Scheduled polling

Polling checks a source at fixed intervals and processes items whose timestamp, version, or hash changed. It is often the easiest starting point for file stores and APIs. Its cost is:

poll count × cost per scan + changed-content processing + reconciliation.

Polling can waste source reads when the change rate is low. It can also miss changes when timestamps are coarse, records are deleted without a visible marker, or the source API paginates inconsistently. Use a lookback window and a durable high-water mark, then make the worker idempotent.

CDC for RAG

CDC reads inserts, updates, and deletes from a database log or source change feed. AWS describes ongoing replication as collecting changes from database logs, and it distinguishes full-load-plus-CDC from CDC-only tasks.^[1] That distinction matters for budgeting: the initial corpus load is still a full-load cost, even if later changes are cheap.

CDC is not synonymous with zero-latency ingestion. AWS explicitly notes that CDC latency varies with source workload, network, replication resources, target capacity, and data characteristics, with no CDC latency SLA.^[1] Budget a lag monitor and a replay or backfill path. A row-level change may also require a wider document reconstruction before you can determine which chunks changed.

Event-driven sync

Event-driven ingestion publishes a document or record event as soon as the source changes. It can reduce freshness lag and avoid repeated scans, but it introduces delivery, ordering, retry, deduplication, and dead-letter costs. The event should carry an immutable source ID, version, operation type, modified time, and enough location information to fetch the authoritative content.

Azure Cosmos DB’s change feed documentation describes a persistent ordered record of container changes that can be processed asynchronously and incrementally, distributed across consumers, and checkpointed by clients or a processor.^[2] It also distinguishes modes: the default latest-version mode does not capture deletes, while an all-versions-and-deletes mode does. That is a direct cost and correctness concern for RAG because stale vectors can remain searchable if delete events are not represented.

A cost model you can reuse

Define these inputs for one month:

• D: documents in the corpus.
• C: average chunks per document.
• F: full refreshes per month.
• U: changed documents per month.
• K: average chunks affected by one changed document.
• E: embedding cost per processed chunk.
• W: vector write, update, or delete cost per affected chunk.
• P: cost of one polling scan, including source reads.
• S: scheduled scans per month.
• X: fixed monthly delivery, worker, and monitoring cost.
• R: chunks processed by a reconciliation backstop.

Full refresh processing is D × C × F. Incremental changed-content processing is U × K. A simplified full-refresh estimate is:

(D × C × F) × (E + W) + fixed operations.

A polling estimate is:

(S × P) + (U × K × (E + W)) + reconciliation cost + fixed operations.

For CDC or events, replace polling scans with capture or delivery cost, then add retry and checkpoint overhead. Keep source capture cost separate from embedding cost. If your provider bills embeddings by tokens rather than chunks, replace E with the token-based formula and use the same architecture model.

Worked cost example

Assume a 100,000-document knowledge base with 20 chunks per document. It contains 2,000,000 indexed chunks. Each month, 8,000 documents change, and an average change affects three chunks. Therefore, the incremental path processes 24,000 chunks, not 2,000,000.

For illustration only, use these dated planning assumptions as of 2026-11-02: $0.00012 per processed chunk for embedding, $0.00004 per affected chunk for vector mutation, and $0.00002 per processed chunk for parsing and worker time. These are internal scenario rates, not vendor quotes. Assume a $0.25 polling scan, $30 per month for a CDC or event delivery layer, and $15 to $45 per month for monitoring, retries, and checkpoint operations. Replace every rate with measured usage or a current invoice before approving a budget.

The table shows why the cheapest design depends on the workload. Under these assumptions, full refresh is expensive because the changed fraction is small. Polling and events are close because their fixed costs were chosen to be close. CDC is not automatically the lowest-cost option because its durable capture and checkpoint layer costs more in this scenario. If changes rise to 40% of chunks, the incremental advantage narrows. If source scans are expensive or freshness must be measured in seconds, event or CDC delivery may be worth the premium.

Do not interpret the totals as a promise of savings. They exclude the initial full load, vector storage capacity, query-time retrieval, reranking, backups, source licensing, on-call labor, and the cost of a full rebuild after a parser or embedding-model change. They also assume that three chunks really are affected. A re-chunking change can turn one document edit into 20 new chunks.

You can use the RAG, embedding and vector database cost calculator to organize model, retrieval, and vector assumptions, then reconcile actual provider usage with the AI API invoice reconciliation calculator. For model-unit assumptions, see the model pricing comparison rather than mixing list prices from different billing units.

How to choose a sync pattern

Choose polling when the source has a reliable modified timestamp or version, freshness can tolerate minutes or hours, and the source API is inexpensive to scan. Add a lookback window so late-arriving changes are not excluded. Polling is also a sensible first implementation because it exposes the actual changed-document distribution before you commit to streaming infrastructure.

Choose CDC when the source is a database with usable transaction logs and you need a durable sequence of row changes. Verify log retention, schema evolution, transaction ordering, initial-load handoff, and the process for reconstructing a complete RAG document from a row-level event. Price the capture service and source impact, not just the embedding calls.

Choose event-driven sync when the source already emits trustworthy versioned events or when freshness is part of the product requirement. Design for at-least-once delivery: duplicate events must be safe, out-of-order versions must not overwrite newer content, and a dead-letter queue must have an owner. A practical event envelope is {source_id, version, operation, emitted_at, content_uri}.

Keep a full refresh path even after incremental ingestion works. It is the recovery route after an embedding-model migration, chunking change, ACL policy change, index corruption, or a long outage that exceeds the source’s retention window. A dual-run period can compare counts, hashes, and retrieval samples before removing the old path.

For broader RAG operating costs, compare this guide with the RAG cost calculator guide. If your indexing job also runs a model for metadata extraction or summarization, the AI token cost calculator guide helps separate input and output token meters from vector-ingestion meters.

What to measure after launch

Track changed documents and changed chunks separately. A rising chunk-to-document ratio may indicate that documents are being re-chunked or that updates are larger than expected. Record embedding calls, vector writes, deletes, retries, duplicate events, dead-letter volume, and reconciliation findings. Measure source-to-index lag at a percentile, not only an average, and separate normal lag from replay lag.

Validate correctness with a small set of known updates and deletes. After a source deletion, verify that its old chunk IDs are no longer retrievable. After two updates arrive out of order, verify that the newer version wins. After a replay, verify that the vector count and metadata state converge without double billing or duplicate records.

Cost attribution is easier when each ingestion run carries a source, tenant, document ID, version, chunk count, embedding model, chunking configuration, and outcome. Those fields let you explain a month’s bill and distinguish a real change-rate increase from a retry storm or accidental full refresh.

FAQ

Is incremental RAG ingestion always cheaper than a full refresh?

No. It is usually cheaper when the changed chunk fraction is small and detection and operations have modest fixed costs. It can be more expensive when nearly the whole corpus changes, when the source requires expensive CDC infrastructure, or when frequent reconciliation scans approach the cost of a rebuild. Run both formulas with the same units and include the initial load and periodic recovery rebuilds.

Is CDC the same as event-driven RAG ingestion?

No. CDC is a change-capture technique, commonly based on database logs or a source change feed. Event-driven ingestion is an orchestration pattern in which a consumer reacts to emitted events. CDC can feed an event bus, and an event-driven system can use application events without CDC. The cost model should identify the actual capture, transport, checkpoint, and consumer meters.

Do unchanged chunks avoid embedding cost after a document update?

They can, if the pipeline can identify stable chunk boundaries and compare content or hashes. If a small edit shifts every downstream chunk, a chunker may report many changed chunks. Treat the average affected-chunk count as a measured input, not an optimistic constant. Store document version, chunk ID, hash, embedding model, and chunking configuration so the decision is auditable.

How should deletes be priced in an incremental index?

Count delete detection, the delete or tombstone operation, retries, and any cleanup scan. Do not assume that an update-only feed captures deletes. Microsoft’s Cosmos DB documentation notes that latest-version change feed mode does not capture deletes, while the all-versions-and-deletes mode does.^[2] If deleted vectors remain searchable, the technical defect can also create a compliance and support cost beyond the API operation itself.

What is the minimum reconciliation backstop?

Use a durable high-water mark or checkpoint, a retryable event or scan window, and a periodic comparison between source versions and indexed versions. The frequency depends on freshness and source retention. A weekly 5% sample is only a planning example, not a universal control. Regulated or high-change systems may need full counts, hash comparisons, or a replayable source log.

Should a model or chunking migration use incremental ingestion?

Usually not as the only path. Changing the embedding model or chunking configuration can make every stored vector incompatible or stale. Keep the incremental path for ordinary content changes, but budget a full backfill or dual-index migration for configuration changes. This is one reason the monthly model should include a separate recovery and migration reserve.

Limitations and assumptions

This article uses a scenario worksheet, not a provider quote. Prices vary by embedding model, tokenization, vector database plan, source API, region, retention, throughput, and negotiated contract. The example rates are deliberately explicit so they can be replaced. They are not current market benchmarks, and no search-volume, ranking, traffic, revenue, or savings outcome is implied.

The model treats a processed chunk as the main unit. Real pipelines may bill embedding tokens, database write units, request units, compute seconds, storage, network egress, or queue operations. Normalize those meters before comparing alternatives. The model also assumes that content retrieval and parsing are measurable. If a document update triggers OCR, table extraction, access-control evaluation, or an LLM summarization step, add separate meters.