Cosine Similarity vs Euclidean Distance in Vector Search — When It Matters
Fast recall
Quick revision
Core answer
<#> for negative inner product, <=> for cosine, <-> for L2. Spring AI defaults to cosine via PgVectorStore.Whether the candidate understands the geometric intuition behind each metric and can articulate why text embeddings favour cosine over L2 — and when image or numerical embeddings might prefer L2
Saying 'cosine is always better' without explaining why. The real reason is magnitude invariance: text length affects magnitude but not direction, so cosine ignores a confound that L2 doesn't.
Mention that normalised embeddings (unit vectors) make cosine and dot product equivalent — which is why many vector databases normalise on ingest and then use inner product for speed. Explain the PGVector operator symbols.
Interview-ready guide
Interview answer
Cosine similarity measures the angle between two vectors. Euclidean distance measures the straight-line gap between their tips.
For text, cosine wins because text length affects magnitude but not direction. A short and a long document on the same topic point the same way in embedding space. Cosine ignores the length difference; L2 sees them as far apart and demotes the longer document — that's wrong.
For images or numeric feature vectors where magnitude encodes something meaningful (like intensity), L2 makes more sense.
In PGVector: use <=> for cosine, <-> for L2. Spring AI defaults to cosine in PgVectorStore. The optimisation trick: normalise vectors to unit length on ingest, then use inner product (dot product) instead of cosine. On normalised vectors they're equivalent, but inner product is faster to compute.
Cosine Similarity vs Euclidean Distance in Vector Search — When It Matters
Direct Answer
Cosine similarity measures the angle between two vectors — it's 1.0 for vectors pointing in the same direction, regardless of their magnitude. Euclidean distance (L2) measures the straight-line distance between two vector tips — sensitive to magnitude, not just direction. For text embeddings, cosine similarity is almost always the right choice: a short sentence and a long paragraph on the same topic have vectors pointing in the same direction but at very different magnitudes. Euclidean distance would penalise the long document just for being longer. PGVector supports both: <#> for negative inner product, <=> for cosine, <-> for L2. Spring AI defaults to cosine via PgVectorStore.
Deep Dive & Architecture
PGVector is a Postgres extension — no new infrastructure, vectors live in the same DB as your relational data, supports HNSW and ivfflat.
Best when your team already runs Postgres. Pinecone is a fully managed serverless vector service — zero ops, auto-scales, but vendor-locked and priced per query/storage.
Cosine similarity measures the angle between two vectors — it's 1.0 for vectors pointing in the same direction, regardless of their magnitude. Euclidean distance (L2) measures the straight-line distance between two vector tips — sensitive to magnitude, not just direction. For text embeddings, cosine similarity is almost always the right choice: a short sentence and a long paragraph on the same topic have vectors pointing in the same direction but at very different magnitudes. Euclidean distance would penalise the long document just for being longer.
Describing a vector database as just a key-value store that happens to hold arrays. The key distinction is the approximate nearest-neighbour index — without it you'd do a full table scan on every query.
Common Mistakes & Pitfalls
Saying 'cosine is always better' without explaining why. The real reason is magnitude invariance: text length affects magnitude but not direction, so cosine ignores a confound that L2 doesn't.
Check your understanding
Answer these without looking back at the article.
- What is a vector database and how does it enable semantic search?
- How do you generate and store document embeddings in a Spring Boot application with Spring AI?
- Compare PGVector, Pinecone, and Weaviate for Java backend use — when do you pick each?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.