Cosine, Euclidean or Dot: Picking a Vector Distance Metric

The distance metric you pick decides what “closest” means in a vector search. Cosine looks at direction, Euclidean looks at plain separation, and dot also cares about length. Change the metric and the same data can rank in a different order.

Three metrics, three ideas of close

Picture a junior DBA asking why two documents that look identical to the model rank differently after someone switches the metric. Fair question. The metrics answer three different questions.

Cosine asks: do these two vectors point the same way? Euclidean asks: how far apart are the two points? Dot asks: how much do they agree, and how long are they? SQL Server returns the negative dot product for dot, so a smaller number still means closer.

Real embeddings have hundreds of numbers, which nobody can eyeball. So I use two numbers per vector. You can check every result by hand.

Same direction, different length

The query points along the first axis. Candidate 1 is the same vector. Candidate 2 is the same direction but twice as long. Candidate 3 points at a right angle.

DECLARE @q vector(2) = '[1,0]';
DECLARE @v TABLE (Id int PRIMARY KEY, Value vector(2));
INSERT @v VALUES (1,'[1,0]'), (2,'[2,0]'), (3,'[0,1]');

SELECT Id,
       VECTOR_DISTANCE('cosine', @q, Value) AS CosineDistance,
       VECTOR_DISTANCE('euclidean', @q, Value) AS EuclideanDistance,
       VECTOR_DISTANCE('dot', @q, Value) AS DotDistance
FROM @v
ORDER BY CosineDistance, Id;

Read the first result in the screenshot further down. Cosine gives 0, 0 and 1. Candidates 1 and 2 tie, because they point the same way. Euclidean gives 0, 1 and about 1.414, so it prefers candidate 1, the exact copy.

Dot gives -1, -2 and 0. Here candidate 2 wins, because its extra length counts as extra agreement. Three metrics, and the top answer is candidate 1 or candidate 2 depending on which one you ask.

When every vector has length one

Many embedding models return vectors scaled to length one. Then length cannot matter, and dot and cosine should agree. Let me show it with three unit-length candidates.

DECLARE @q vector(2) = '[1,0]';
DECLARE @u TABLE (Id int PRIMARY KEY, Value vector(2));
INSERT @u VALUES (1,'[1,0]'), (2,'[0.6,0.8]'), (3,'[0,1]');

SELECT Id,
       VECTOR_DISTANCE('cosine', @q, Value) AS CosineDistance,
       VECTOR_DISTANCE('dot', @q, Value) AS DotDistance
FROM @u
ORDER BY DotDistance, Id;

The second result is the bottom grid. Cosine gives 0, 0.4 and 1. Dot gives -1, -0.6 and 0. The order is 1, 2, 3 for both. The numbers differ, but the ranking does not.

One small trap: you see 0.399999976158142 and not 0.4. Vectors store single-precision numbers, so tiny rounding is normal. Never build an equality rule on an exact decimal distance.

Normalize first, then dot behaves like cosine

What if your vectors are not unit length? You can scale them yourself. VECTOR_NORM returns the length, and VECTOR_NORMALIZE scales a vector to length one.

DECLARE @q vector(2) = '[1,0]';
DECLARE @v TABLE (Id int PRIMARY KEY, Value vector(2));
INSERT @v VALUES (1,'[1,0]'), (2,'[2,0]'), (3,'[0,1]');

SELECT Id,
       VECTOR_NORM(Value, 'norm2') AS VectorLength,
       VECTOR_DISTANCE('dot', @q, VECTOR_NORMALIZE(Value, 'norm2')) AS DotAfterNormalize
FROM @v
ORDER BY DotAfterNormalize, Id;

The lengths are 1, 2 and 1. After normalizing, candidates 1 and 2 both score -1. The tie is back, exactly like cosine. The extra length of candidate 2 no longer buys it anything.

How I would choose on a real project

Start with the model that made your embeddings. Use the metric it was trained for, and use the same one for every query. If the model returns unit-length vectors, cosine and dot rank the same, so pick either.

Then check your own data. Run VECTOR_NORM over a sample of stored embeddings. If the lengths are all about 1, you are in the unit-length case. If they vary a lot, decide on purpose whether length should count.

Keep one more thing in mind. Two vectors with the same number of dimensions can still come from different models. Their distances mean nothing together. Store the model name next to each embedding, and compare only like with like.

Write the model, the scaling rule and the metric down next to your table, and future you will say thanks.

The metric is not a detail, it is the definition of closest.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.