Re-indexing: The Fresh Start

In the world of standard databases, you can add a column to a table while it's running. In the world of vector databases, Changing the Model = Re-indexing everything.

If you built your support bot using OpenAI v2 embeddings (1536D) and you want to switch to the cheaper, faster v3 embeddings, you cannot simply "update" the vectors. You have to create a new index and start from scratch.

In this lesson, we will explore the "Re-index Trigger," the "Blue-Green" deployment pattern for vector search, and how to manage the hardware costs of running two databases during a migration.

1. When do you need to Re-index?

There are four common triggers for a full re-index:

Model Upgrade: Moving from 768D (SBERT) to 1536D (OpenAI) or vice-versa.
Dimension Change: Even within the same model family (e.g., using "Matryoshka" embeddings to reduce size).
Graph Corruption: If you have performed too many deletes/updates and the ANN Recall has dropped significantly.
Distance Metric Swap: Realizing you used L2 and you actually need Cosine.

2. The Blue-Green Re-indexing Pattern

You should never delete your production index until the new one is tested and ready. We follow the "Blue-Green" pattern:

The Blue Index (Current): Your app is searching here.
The Green Index (New): You create this index with the new model/settings.
Ingestion: You read your source data (from SQL/S3) and push it into the Green Index.
Validation: You run "Evaluation Queries" (Module 11) to ensure the search quality is good.
The Switch: You update your app's Environment Variable VECTOR_DB_NAME from "Blue" to "Green."
Grace Period: Keep Blue running for 24 hours just in case.
Cleanup: Delete the Blue Index to stop paying for its hardware.

graph LR
    subgraph Phase_1
    App --> Blue[Current DB]
    end
    subgraph Phase_2_Ingestion
    App_P2 --> Blue
    Worker --> Green[New DB]
    end
    subgraph Phase_3_Switch
    App_P3 --> Green
    Blue_P3[Stale DB]
    end

3. Designing a "Re-indexable" Architecture

To make re-indexing easier, you must separate your Source Data from your Vector Data.

The Golden Rule: Never let your vector database be your "Primary Source of Truth." If you lose your vector database, you should be able to rebuild it completely from your Postgres/S3 records in under an hour.

The Ingestion Worker

Build your ingestion logic as a standalone service (or an AWS Lambda). It should be able to "replay" all your records into a target index name passed as an argument.

4. Hardware Cost and Concurrency

Re-indexing 10 million vectors takes time and CPU.

Chroma: Your laptop might overheat or run out of disk space.
Pinecone: You will pay for "Double Storage" (Blue + Green) during the 2 days of migration.
OpenSearch: Your JVM might hit its CPU limit during the heavy ingestion, potentially slowing down live queries.

Tip: Perform re-indexing during "Off-Peak" hours, or provision temporary, high-power pods during the migration window.

5. Python Example: The Switch-Ready Client

Here is how you can build a class that supports easy index switching via environment variables.

import os
import chromadb

class AISearchApp:
    def __init__(self):
        self.client = chromadb.PersistentClient(path="./db")
        # we read the target index name from an ENV variable
        self.active_index_name = os.getenv("CURRENT_VECTOR_INDEX", "docs_v1")
        self.collection = self.client.get_collection(self.active_index_name)
        
    def query(self, text):
        return self.collection.query(query_texts=[text], n_results=5)

# To Switch:
# 1. Start your new server with CURRENT_VECTOR_INDEX="docs_v2"
# 2. The app automatically connects to the new index.

6. Cold Start and Cache Warmup

When you switch from Blue to Green, your search might feel "Slow" for the first few users. This is because the Operating System hasn't cached the new index files in RAM yet.

Solution: After the "Green" ingestion is complete, run 1,000 random "Warmup Queries" against the Green index before you point your real users to it. This forces the index into the server's RAM.

Summary and Key Takeaways

Re-indexing is a fact of life in AI engineering.

Expect Change: Assume you will re-index your whole database at least twice a year as AI models improve.
Blue-Green is Mandatory: Never perform destructive updates on your live index.
Protect your Source Truth: Your vector database is a cache of your knowledge base; your SQL/S3 is the source.
Warm up the Index: Don't let your first 100 users suffer from "Cold Start" latency.

Module 8 Wrap-up

You have mastered the CRUD Lifecycle. You understand how to Create with the future in mind, Insert with batch efficiency, Update with metadata filters, and Re-index with professional Blue-Green deployments.

In Module 9: Multi-Modal Vector Databases, we go beyond text. We will explore how to search images, audio, and video in the same coordinate system.

Exercise: Migration Timeline

You have 5 million documents.

Ingestion speed (with batching): 1,000 docs per second.
Your Pinecone pod costs $200 per month.

How long will it take to build the "Green" index?
If you keep both the "Blue" and "Green" indexes running for 48 hours to ensure a safe switch, what is the "Migration Tax" (extra hardware cost) in dollars?
Designing his migration, why would you not want to delete the Blue index the exact second you start the Green ingestion?

Re-indexing Strategies: The Infrastructure Migration