Fixed-length vs. Variable-length embeddings

Why fixed length is the norm

Transformer-based text and image models output a fixed-size vector per input (sentence or image), so the resulting embeddings are naturally fixed-length. That fits VDBs: the index is built for one dimension, and every point has the same number of components. Distance and similarity are defined only between vectors of the same length, and ANN structures (e.g. HNSW, IVF) assume a fixed D. So a collection declares its dimension (e.g. 768), and all inserts and queries must use that dimension.

Pipeline impact: when you choose an embedding model, its output dimension is fixed (e.g. 384, 768, 1536). You create a collection with that dimension and all upserts and queries must supply vectors of that size. When to use which dimension: higher dimension often means more expressive embeddings but more memory and slower distance computation; see impact of embedding model dimensionality on VDB performance and choosing the right embedding model for trade-offs.

Variable-length and multi-vector options

Variable-length representations (e.g. multiple vectors per document, or token-level vectors) require either aggregating to one vector per document (e.g. mean pooling), storing multiple vectors per document and using multi-vector search, or maintaining separate structures—each with different trade-offs. Multi-vector search lets you store several vectors per item and query against all of them (e.g. max or aggregate score per document); the per-vector dimension is still fixed.

Truly variable dimension per point is not supported by typical VDB interfaces. Practical tip: for long documents, use chunking to get one fixed-length vector per chunk rather than trying to use variable-length vectors; for multiple aspects per item (e.g. title + body), either concatenate and project to one vector or use multi-vector search if your VDB supports it. Trade-off: mean pooling loses some nuance; multi-vector increases storage and query cost but can improve recall.

Dimension and performance

The dimension is determined by your embedding model and affects memory and performance. Once chosen, all vectors in that collection must match; mixing lengths in one index is not supported by standard VDB interfaces. When you switch embedding models, if the new model has a different dimension you must create a new collection and re-embed and re-index; you cannot mix dimensions in one index. See choosing the right embedding model for quality vs. dimension trade-offs and handling updates to the embedding model for version drift.