Embeddings as a data type: fixed-length vectors, a distance function and what a column of them needs

What it is

An embedding model maps an input (text, image, code) to a vector of fixed length. The vector has no meaning on its own; it is useful because the distance between two vectors from the same model approximates a similarity the model was trained on. The scikit-learn pairwise-metrics guide defines cosine similarity as the normalised dot product of two vectors. The pgvector README shows the data-type view concretely: a column declared vector(3) has a fixed dimension, queries order rows by a distance operator (among them L2 distance, negative inner product and cosine distance), and by default the extension performs exact nearest neighbour search with perfect recall, while an HNSW or IVFFlat index switches to approximate search that trades some recall for speed and can return different results.

Why it matters

Teams store embeddings as opaque float arrays and later cannot say which model produced them, whether two tables are comparable, or why search quality dropped after a model upgrade. Treating the vector as a typed value with provenance avoids all three.

How to apply

• Store next to each vector, or per table, the embedding model identifier and version, the dimension, the distance function the model expects, and any preprocessing (truncation, normalisation, chunking) applied to the input.
• Never compare vectors from different models or versions; a model upgrade is a re-embedding of the whole corpus, ideally into a new column or table with a cut-over.
• Normalise vectors if the model expects cosine similarity and the store uses dot product, and document which one is in use.
• Decide exact versus approximate search by corpus size and recall requirement; when using an approximate index, measure recall against exact search on a sample of queries.
• Keep the original input (or a reference to it) that produced the vector, so that re-embedding and debugging are possible.

Pitfalls

Storing vectors as JSON text costs space, loses the fixed dimension and cannot use a vector index. A vector column without a recorded model version is unusable after the first upgrade. Similarity scores are not calibrated probabilities and are not comparable across models.