Backups, Migrations and Re-Embedding

You can rebuild an index, not lost text

Decide what is the source of truth. The original documents and their metadata are irreplaceable; vectors and ANN indexes can be rebuilt (at a cost in time and embedding fees), so keep the sources safe and treat the index as a derived, rebuildable artefact, while still backing it up to shorten recovery. Use the engine's mechanism: pg_dump/base backups with point-in-time recovery for PostgreSQL, snapshots for dedicated engines, and test restores regularly. For a new embedding model or dimension, never mix vectors: create a new collection or index, re-embed everything, compare quality on the golden set, switch traffic (alias or config), and keep the old one for rollback. Version your schema and record the model name, version and chunking settings with the data. Plan disaster recovery: how long to restore, how much data you can afford to lose (RPO) and how long you can be down (RTO).

A model-upgrade runbook

Steps for replacing the embedding model without breaking search.

1. create collection/index "docs_v2" (new dimension / metric if the model changed)
2. re-embed all source text with the NEW model; write idempotently by deterministic id
3. build the ANN index; check counts and a recall sample vs exact search
4. run the golden-set evaluation on v1 and v2; compare recall@k and MRR
5. shadow traffic: send real queries to both, compare results and latency
6. switch the alias/config from docs_v1 to docs_v2 (instant, reversible)
7. keep docs_v1 for a rollback window, then delete it (and its backups, per retention policy)

Practise a restore

A backup you have never restored is a hope, not a plan. Rehearse recovery and time it.

Quick check: How should you switch to a new embedding model?

• Replace the model and keep old vectors
• Mix old and new vectors in the same index
• Build a new index, re-embed everything, compare, then switch with a rollback option
• Delete the sources