The Missing Foreign Key of Vector Databases: The Model Version Consistency Crisis

Vector databases allow embeddings from different model versions to coexist within the same index, because they are completely type-valid even though their geometric meanings have become mutually contradictory. At data warehouse scale, re-embedding billions of rows after a model upgrade is a long and expensive batch job—meaning mixed-version indexes are not an edge case, but the default state during every migration.

The Schema Is Lying

Embeddings are not ordinary data—they are coordinates in a geometric space defined by a specific model. The cosine similarity between two vectors is only meaningful if they were mapped into the same space by the same function. Change the model—a new checkpoint, a new tokenizer, or even just a change in the normalization step—and you produce an embedding of the same shape but a different space. A 1536-dimensional float array from one model version is structurally identical to an array produced by the next version. The data warehouse's type system cannot tell them apart, because it was never designed to.

The problem: relational schemas enforce structural constraints—types, nullability, foreign keys between tables—but they have no notion of "generated by model X at checkpoint Y with preprocessing Z." When an embedding column is partially regenerated, the warehouse sees a column of valid, clean vectors, and the vector database sees a clean index. Nearest-neighbor search raises no error. The only symptom is a slow decline in retrieval quality, which looks like model drift or data quality rot but is in fact two incompatible coordinate systems being compared as if they were one.

Embedding vectors are dense vectors produced by mapping discrete objects (text, images, audio) into a high-dimensional real space via a deep neural network. The core assumption is that semantically similar objects are also close in vector space, so cosine similarity or Euclidean distance can serve as a proxy for semantic relatedness. But this assumption carries an implicit premise: all vectors being compared must be produced by the same mapping function. An embedding model typically consists of three parts—a tokenizer, encoder weights, and a normalization step—and changing any one of them changes the entire mapping function, producing a new space with completely different semantic coordinates at the same dimensionality. This is why consistent vector dimensions do not equal compatible spaces: dimensions are only the shape of the container; the meaning of the coordinates is what determines geometric relationships.

Why This Is Not a Small-Scale Problem

At small scale, this problem barely exists. Re-embed ten million rows, swap the table, and it is done in an afternoon. The transition is nearly atomic, and nobody notices the seam.

But at warehouse scale—billions of rows accumulated over years, with embedding columns hanging off historical fact tables, feature tables, and document archives—re-embedding is not an afternoon's work but a batch load lasting days or longer, depending on throughput and cost constraints. Throughout that window, the production index mixes rows re-embedded with the new model and rows still carrying old vectors, because no one can afford to take the index offline before the backfill completes.

This means mixed-version indexes are not a rare migration mishap but the default operating state every time a warehouse-scale system upgrades its embedding model. The larger the warehouse, the longer this window, and the longer retrieval quality silently degrades with no one able to point to the cause—because every vector in the index is, in isolation, perfectly valid.

Backfill refers to the process of recomputing embeddings for historical data with the new model and writing them back to the index. Its key difference from ordinary batch processing is that backfill's input scale equals the entire historical dataset, whereas online inference's input scale equals only the current query volume. Their cost curves are entirely different—inference cost grows linearly with traffic and scales elastically, while backfill cost increases monotonically with total data volume and cannot be compressed by adding concurrency. In real systems, backfill is typically bounded by throughput ceilings (GPU queues, API rate limits) and cost budgets, making it difficult to complete within hours and inevitably overlapping with online queries. This is the physical reason the mixed-version window arises.

Re-embedding Is a Hidden Line Item in the Compute Budget

Here is a cost dimension most capacity planning ignores. Inference serving cost scales with query volume and can be predicted, capped, and autoscaled. Re-embedding cost scales with total historical data volume, which only grows. Every time you adopt a better embedding model, you pay not just the marginal cost for new data but the cost of reprocessing all prior data from scratch, back to the furthest point your retention policy allows.

For a warehouse holding years of documents, support tickets, logs, or transcripts, this backfill can dwarf the ongoing inference bill. Teams that treat re-embedding as a one-off script handed to whoever happens to own the vector database will ultimately rediscover this cost the hard way—mid-migration, after the budget was set on the assumption that "embedding is a solved, cheap preprocessing step."

The practical consequence is that re-embedding needs to be budgeted and scheduled like any large backfill: with its own SLA, compute allocation, and owner—not treated as an incidental side effect of a model upgrade.

Blue-green deployment is a release strategy that maintains two environments in parallel and switches traffic only after validation passes. In vector retrieval, blue-green means that while the old index continues serving, a complete set of vectors is built in a separate index under the new model identity; once metrics such as recall and latency meet targets, query routing is switched atomically, with fallback to the old index if problems arise. The alternative is in-place update—replacing vectors row by row in the same index—which produces the long mixed-state window described earlier. Blue-green switching costs temporary double storage and double backfill compute, but it converts "invisible quality degradation" into "a controllable switching instant" and brings rollback capability into the architecture.

Provenance as a Constraint, Not a Metadata Field

The solution is not novel. It is the same move relational databases made decades ago when they decided referential integrity should not be optional: make the dependency explicit and enforce it structurally, rather than relying on people to remember.

Concretely, every embedding column should carry a composite identity alongside the vectors—model identifier, checkpoint or version hash, preprocessing hash—and this identity should be a first-class citizen of how the vector index is partitioned and queried, not an optional tag in a side table. Similarity search across two different identities should not silently succeed; the system should reject it by default or flag it loudly, just as a type-mismatched join is rejected rather than silently coerced.

Operationally, this translates into a few concrete habits:

• Treat re-embedding as a first-class ETL pipeline with lineage, monitoring, and an explicit completion state, not a script someone runs once and forgets.
• Before switching, build the new index entirely under the new model identity—a blue-green swap for vector indexes, the same standard discipline already adopted for schema migrations.
• During the transition window, filter or partition retrieval by model identity, so queries never silently mix two incompatible spaces even while backfill is still running.
• Record model identity as part of each embedding's provenance record, queryable like column-level lineage, so quality regressions can be traced back to "which model wrote this vector" in minutes rather than days.

None of this requires new infrastructure. It requires a decision: model identity is a dependency the schema should enforce, not a fact that lives in a changelog that no one reads during an incident.

Referential integrity is the constraint mechanism by which a relational database guarantees that a foreign key points to a valid primary key record. Its value lies not in what is recorded but in the fact that the database rejects writes that violate the constraint, making errors unable to pass silently. Modeling model identity as a foreign key essentially turns the semantic rule "which vectors belong to the same space" into a hard constraint the database can enforce. In implementation, you can introduce a model identity table as a parent table in the embeddings table, with the embedding column's foreign key pointing to it; partition the vector index by model identity; and determine the model identity first at query time before hitting the corresponding partition. This makes cross-model comparison physically impossible, rather than merely discouraged by documentation or code review.

The Real Lesson

Vector databases inherited the warehouse's belief that if the type check passes, the data is trustworthy. That belief does not hold for embeddings. Model versions should not be metadata noted after the fact, but a structural foreign key on the embedding column. Only when the system refuses similarity search across model versions—or at least warns loudly—will retrieval quality stop silently collapsing.

One-line Summary

Model versions should be a structural foreign key on embedding columns, not optional metadata—otherwise retrieval quality silently collapses.

Paragraph Summary

A vector database's type system validates only dimensions and types; it cannot distinguish the geometric-space differences produced by different model versions, so cosine similarity loses meaning when mixed comparisons occur within one index. At warehouse scale, re-embedding billions of rows is a batch load lasting days or longer, which makes mixed-version indexes the default state of every model upgrade rather than a rare accident. The cost is slow, hard-to-attribute retrieval degradation, plus re-embedding costs that inflate monotonically with total historical data—often ignored by capacity planning. The author argues for treating model identity (model ID, checkpoint hash, preprocessing hash) as a structural foreign-key constraint on embedding columns, combined with blue-green index switching, model-identity-partitioned retrieval, and full lineage records, so cross-model similarity searches are rejected or flagged rather than silently succeeding.