Why an index rebuild can create downtime

A corporate RAG index needs updating for more than a new embedding model. Instructions, prices, policies, product records, access rights, and source documents all change. If the live collection is cleared and rebuilt in place, queries during the rebuild may return incomplete results, and a failed load becomes an incident.

A safer pattern keeps the current version available while a new one is built separately. Qdrant supports collection aliases: the application queries a stable name, and the alias can be switched atomically from the old collection to the new one. Qdrant’s documentation explicitly describes building a second collection in the background and atomically changing the alias. OpenSearch documents a similar pattern for indexes. This is not a magic “refresh RAG” button; it separates preparation of a new version from traffic cutover.

The pattern: an index version and a stable name

Call the collections `manuals_v17` and `manuals_v18`, and the application alias `manuals_current`. The retrieval service always queries `manuals_current`; it does not need to know which physical collection the name currently targets.

Build the new version in parallel:

1. Create the target collection with the required schema, vector fields, filters, and settings.
2. Normalize and chunk the documents, then load them with stable identifiers.
3. Verify ingestion completeness and run test searches against a set of known questions.
4. Once the version passes its gate, switch the alias in one request: remove its link to the old collection and add a link to the new one.
5. Keep the previous version briefly for a quick rollback, then remove it under a defined retention procedure.

The main benefit is that preparation and testing do not change the route used by live queries. But an atomic alias switch does not make index construction error-free, verify document content, or resolve races with new source changes.

The critical part: capturing changes during the build

If loading the new version takes an hour, new documents, edits, and deletions may occur in the source CRM or knowledge base during that hour. A full copy taken at the beginning may already be stale at cutover. This matters especially for price lists, access policies, inventory, and safety instructions.

For a small deployment, choose one of three approaches:

  • **Brief write pause.** Temporarily stop source changes during final reconciliation, load the remainder, run checks, and switch the alias. This is simple if the window lasts minutes and the business accepts it.
  • **Change log.** Record a snapshot version or timestamp, build the new collection, then apply events after that point: inserts, updates, and deletions. Before cutover, process the log until the remaining lag is within an agreed limit.
  • **Temporary dual writes.** Send new changes to both the active and building versions for a limited period. This reduces the final backlog but makes error and retry handling more complex.

The right option depends on the source. For a file share, a queue of events with checksums and modification times may work; a CRM may offer an audit log or CDC; a custom database can use an outbox table. Do not claim exact synchronization if the source cannot report deletions: otherwise removed documents can remain as “ghosts” in the new version.

How not to switch to a lower-quality version

Before cutover, compare more than the number of points in each collection. Equal chunk counts do not prove that all current documents made it into the index: one long PDF can produce hundreds of chunks while an important short instruction produces none.

For a small pilot, define a set of real questions whose answers staff already know. Include an exact part number, a return deadline, an exception to a policy, an approval route, and a question about a recently changed document. For each query, record the expected source and what a good answer must contain.

Check before switching:

  • **Source coverage:** how many documents were read, skipped, or failed.
  • **Freshness:** whether new versions are present and deleted materials are absent.
  • **Retrieval:** whether the required passage appears near the top, especially for exact codes and dates.
  • **Permissions:** whether a test user can see another department’s documents.
  • **Answers:** whether the model cites the right passage and abstains when it has no support.
  • **Operations:** search latency, ingestion errors, memory use, and free disk space.

You can run a shadow comparison: send a copy of queries to the new collection while users continue receiving answers from the old one. Do not send unnecessary personal data into this test; use anonymized queries or first assess access and log retention. Shadow retrieval shows differences in results, but does not replace evaluation of the end-to-end answer in the application.

Cutover and rollback are separate operations

During cutover, the application should use only the stable alias, not a version name in configuration. In Qdrant, deleting the old alias link and creating the new one can be sent in one list of alias actions; the documentation says alias changes are atomic. OpenSearch also documents index-alias changes as atomic. This means the route should not briefly point “nowhere” during that update.

However, route atomicity is not the same as readiness of the new version. Before cutover, confirm that ingestion finished, the delta was applied, baseline queries passed, and the new collection is reachable by the application. After cutover, monitor the rate of answers without sources, empty results, filter errors, latency, and user feedback. Define a simple rollback trigger in advance, such as a regression in the test set or an increase in empty results beyond an agreed threshold.

Rollback means switching the alias back to the retained version, not rebuilding a collection under incident pressure. Yet new changes may have gone only to the current version after cutover. Before switching back, either replay the change log into the old collection or explicitly accept and assess the freshness loss. Do not automatically delete the old collection immediately after a successful cutover.

Requirements and cost

Parallel construction needs temporary resource headroom. While both versions exist, you need space for two collections, compute for embeddings in the new version, ingestion bandwidth, and time to run the test set. In a local deployment, disk, RAM, GPU/CPU, and background workload may matter more than the model’s price; they are part of total cost of ownership.

The footprint is not always exactly double. It depends on vector size, payload, compression, HNSW, replicas, and storage format. Measure the current collection and load on a representative pilot corpus. For a small corpus updated infrequently, a short reindexing window or targeted updates may be simpler. A second full version is worthwhile when in-place updates create meaningful downtime, partial-index risk, or a difficult rollback.

A practical pilot estimate includes:

  • how many documents and chunks a full rebuild recomputes;
  • how long the initial load and delta catch-up take;
  • how much temporary disk is required;
  • what share of test questions finds the expected source;
  • the cost of one indexing cycle and manual review;
  • how many minutes of downtime or manual recovery the pattern can avoid.

This is an operating model, not a promise that every RAG deployment will cut over without latency. External calls, application caches, replicas, and long-running requests may behave differently and need testing in your environment.

A minimum implementation plan

1. Choose one corpus with a clear owner and low risk—for example, internal instructions without personal data.
2. Introduce a stable alias in the application and record the source-document version.
3. Build a new collection beside the current one; preserve document IDs, versions, timestamps, and access metadata.
4. Configure a change log or another way to apply edits made during the full load.
5. Prepare 20–50 representative questions and acceptance criteria: correct source, current version, correct permission filter, and acceptable latency.
6. Switch the alias, monitor the metrics, and retain the previous collection for rollback.
7. After an observation period, remove the old version only through a controlled procedure with a backup or a proven way to rebuild it.

You do not need an orchestrator made of five services to start. A corpus version, repeatable loader, test set, stable retrieval name, and a clear owner who can stop the cutover are enough. The robot intern can pull the lever with great enthusiasm; a person still decides whether the new index is actually better.

Bottom line

An atomic alias is useful when a business needs to build a new RAG version alongside the current one and switch only after validation. It reduces cutover downtime risk, but does not replace change synchronization, permission checks, quality evaluation, or a rollback plan. Start with one corpus and a measurable query set. If build time, temporary storage, and stale-data risk are acceptable, expand the pattern to other sources.