Reliable vector search requires more than a matching array length. The query and stored vectors must share model, revision, preprocessing, task mode, dimensions, type, and intended metric. Normalization changes metric behavior; reduced precision changes storage and ranking; zero or null vectors need explicit policy. Encode what you can in schema and validate the rest in ingestion.
vector(768) accepts exactly 768 coordinates. A new 1,024-dimensional model cannot be written into that column, which is a useful failure. A dangerous case is two different models with the same dimension: PostgreSQL sees compatible shapes even though their semantic spaces are unrelated.
Use an explicit model registry and bind embedding rows to it:
If models have different dimensions, separate typed columns, tables, or partitions give PostgreSQL enforceable definitions. An unconstrained vector column can store mixed dimensions, but indexes apply only to rows cast or constrained to a consistent dimensional type; it also moves more validation into application logic.
Normalize only when the embedding model or retrieval design calls for it. A unit vector has L2 norm one. For normalized vectors, inner product can be a fast equivalent ranking to cosine. Store whether normalization occurred as part of preprocessing version. Avoid normalizing a zero vector; define it as an embedding failure or excluded record.
pgvector provides normalization functions for supported types in current versions. Verify the exact function names in your installed extension.
vector stores single-precision floats. halfvec uses half precision, allowing more indexed dimensions and smaller storage at the cost of numeric precision. Binary representations use much less information. The correct choice comes from an evaluation: compare retrieval metrics, size, build time, insert rate, and latency on your data.
Never decide from storage savings alone. A small recall reduction may significantly change rare-query outcomes.
Do not invent a zero vector to satisfy NOT NULL. Keep job state separately:
Only ready rows should enter retrieval. Store sanitized error codes rather than provider responses that may contain sensitive inputs.
Review my embedding schema and pipeline contract [paste]. Build a compatibility matrix covering model name, revision, dimensions, preprocessing, query/document mode, normalization, vector type, metric, and index operator class. Propose database constraints and application guards for every detectable mismatch.
Verification contract: Create one failing test per guard, plus a golden-set comparison for any change that cannot be enforced structurally.