Embeddings are a build artifact, like a compiled binary. Change the embedding model and every vector you stored is invalid. The durable assets are the raw corpus and a reproducible pipeline—not the index.

• An embedding is derived data: a function of the source document, chunking strategy, embedding model, and model version.
• Upgrade the embedding model and every stored vector becomes stale. Different models define incompatible coordinate spaces.
• You cannot safely “normalize” old vectors into a new model. That creates silent retrieval drift, not a clean migration.
• The durable assets are the raw corpus and reproducible ingestion pipeline.
• The vector database should be treated as a rebuildable cache in front of that pipeline.

The Upgrade That Quietly Torched the Index

A model upgrade landed in an embedding stack. New version, better benchmark numbers, and a drop-in replacement on paper. Someone enabled it for ingestion and shipped.

Retrieval quality did not crash immediately. That was the trap. It drifted.

New queries were embedded with the new model, but much of the index still contained vectors produced by the old model. Nearest-neighbor search kept returning plausible results, but the results were subtly wrong. No exception. No alert. Just retrieval that became less trustworthy over time.

The fix was not a small patch. The fix was to re-embed the entire corpus and rebuild the index.

That is the architecture lesson: a vector database is not the durable source of truth. It is a derived index. If the raw documents and pipeline are preserved, the index can be rebuilt. If the vector store is treated as the only source, the system is trapped inside a coordinate space it may no longer understand.

Embeddings Are Derived Data

A vector is not meaningful by itself.

You take a chunk of text, run it through a specific embedding model at a specific version, and get a list of numbers. Those numbers only make sense relative to other vectors created by the same model and preprocessing pipeline.

Think of an embedding like a compiled artifact.

The source code is the original text plus the chunking strategy plus the embedding model. Change the compiler, and the old binary may no longer be valid.

An embedding does not encode meaning in a universal space. It encodes meaning in the coordinate system defined by one specific model.

Even if two models produce vectors with the same number of dimensions, those vectors are not interchangeable. A 1536-dimensional vector from one model is not automatically compatible with a 1536-dimensional vector from another model.

Cosine similarity will still return a number. That is the dangerous part. The system will not crash. It will simply return low-quality results that look mathematically valid.

A Model Swap Is a Schema Change

A model upgrade is not only a data refresh. It can also become a schema change.

If a system moves from a 1536-dimensional embedding model to a 3072-dimensional model, the storage layer must support the new shape. Indexing strategy, memory footprint, approximate-nearest-neighbor settings, and database column definitions may all need to change.

For example, some vector stores have limits or different performance characteristics depending on vector dimension and index type. A dimension change may force a migration, not just a configuration update.

This is why every vector record should carry its own build instructions.

At minimum, store:

record = {
    "id": f"{source_doc_id}:{chunk_idx}:{model_version}",
    "vector": embedding,
    "metadata": {
        "source_doc_id": "s3://corpus/contracts/2026/doc_8842.md",
        "chunk_idx": 3,
        "content_hash": "sha256:9f2c...",
        "embedding_model": "openai/text-embedding-3-large",
        "model_version": "2024-01-25",
        "dim": 3072,
        "pipeline_rev": "git:7af19c2",
        "embedded_at": "2026-06-29T00:00Z"
    }
}

Each field has a purpose.

source_doc_id points to the durable asset.

content_hash makes re-embedding idempotent. If the chunk text and model version have already produced a vector, the pipeline can skip it.

embedding_model and model_version make staleness detectable.

pipeline_rev captures the chunking and preprocessing logic, which is often as important as the model itself.

The vector is disposable. The provenance is what makes the index rebuildable.

Store Truth Durably. Index Meaning Separately.

The source of truth should be a durable system: object storage, a document repository, a database, a ticketing system, or another governed record store.

The vector database should index meaning, not own truth.

A good architecture separates the two:

Durable layer: raw documents, metadata, access policy, document versions, ownership, and audit history.

Derived layer: chunks, embeddings, vector index, and retrieval metadata.

Pipeline layer: chunking logic, embedding model version, validation, ingestion jobs, and rebuild scripts.

If the vector database disappears, the system should be able to regenerate it from the durable layer.

That is the test.

Could you delete the entire vector store and rebuild it from object storage and versioned pipeline code?

If yes, you have a cache.

If no, your cache has quietly become your database.

Snapshot Recovery Is Not Rebuild Recovery

A snapshot is useful when the same vector database must be restored after failure. It can recover the same index, with the same vectors, under the same model version.

That is disaster recovery.

But a snapshot does not solve model migration.

If you restore a snapshot after an embedding-model change, you have restored the old coordinate space. That may be exactly what you are trying to leave.

A rebuild is different. A rebuild recomputes vectors from the raw source using the target model and current pipeline.

Both operations are important, but they solve different incidents:

The safest production pattern is to build the new index beside the old one, validate retrieval quality, then switch traffic using an alias or routing layer.

Rebuilds Need to Be Practiced

Rebuilding a vector index can be expensive. It may require re-reading the corpus, re-chunking documents, calling an embedding model, writing millions of vectors, and rebuilding an approximate-nearest-neighbor index.

That cost is exactly why teams should practice rebuilds before they are forced into one.

A rebuild runbook should answer:

• Where is the raw corpus stored?
• Which pipeline revision produced the current index?
• Which embedding model and version are active?
• How is staleness detected?
• How long does a full rebuild take?
• Can rebuilds resume after failure?
• How is retrieval quality validated before cutover?
• How is the old index retained or rolled back?

If these questions cannot be answered quickly, the vector database is already carrying more responsibility than it should.

When the Cache Framing Breaks

There is one case where the vector database does become the source of truth: when the raw corpus is gone.

If documents were embedded, stored only as vectors, and then deleted from the original system, the vector database becomes the only remaining record. That is not a good architecture. It is an accident.

The problem is that vectors are lossy. They cannot reliably recreate the original text, the document structure, the access policy, or the business context. They are optimized for retrieval, not preservation.

That is why the raw corpus must remain durable.

The vector store earns the right to be disposable only when the source behind it is durable, and the pipeline that produced it is reproducible.

Takeaways

• Embeddings are build artifacts. Treat them like compiled outputs, not canonical data.
• A model upgrade requires a rebuild. Old vectors are not safely reusable across embedding models.
• Same dimension does not mean same space. Similarity math can still run while retrieval quality silently degrades.
• Every vector needs provenance. Store source document ID, content hash, embedding model, model version, dimension, and pipeline revision.
• Snapshots and rebuilds solve different problems. Snapshots restore the same cache. Rebuilds recompute a new one.
• The raw corpus is the source of truth. The vector database is only safe to delete if the corpus and pipeline can regenerate it.

Stop backing up your vector index like it is irreplaceable.

Back up the corpus. Version the pipeline. Store provenance. Practice rebuilds.

If you can throw the vector database away and rebuild it cleanly, you have a cache.

If you cannot, the vector store is not just infrastructure. It is your single point of failure wearing an embedding-model version you may never get back.