This question generates more forum argument than it deserves, because for the majority of real setups the answer is provably “it makes no difference at all”.
Here is the proof, and then the minority of cases where it makes a large one.
The three definitions Dot product is unnormalised and grows with the magnitude of either vector.
Cosine divides that magnitude out and measures only the angle, giving a value in [-1, 1].
Euclidean is straight-line distance, so smaller is better where the other two have larger as better.
That last difference is a real source of bugs even where the metric choice is irrelevant.
Half the vector libraries return a similarity and half return a distance, some return “cosine distance” defined as , and a filter written as against a distance keeps exactly the results it was meant to exclude.
Before you tune any threshold, print the score for a document against itself.
If it is 1.0 you have a similarity; if it is 0.0 you have a distance.
On unit vectors they are the same ranking Suppose every stored vector has been normalised to unit length, so .
Most modern embedding APIs return unit vectors already; check once with a quick norm computation rather than assuming.
Under that assumption: Line (1) says cosine and dot product are the same number, not merely the same ordering.
Line (2) says squared Euclidean distance is a strictly decreasing linear function of cosine similarity — and a strictly monotone transform cannot reorder anything.
Sorting ascending by Euclidean distance and descending by cosine produces the identical list, in the identical order, for every query.
So if your vectors are normalised, the metric debate is settled before it starts.
Your top-10 is byte-identical whichever of the three you configure.
What differs is the number printed next to each result: cosine 0.94 corresponds to Euclidean , and any threshold you have tuned must be translated through that relation rather than carried over.
When the choice genuinely matters Vectors that are not normalised This is the entire real disagreement.
If magnitudes vary, dot product rewards long vectors and cosine ignores length.
Whether that is a feature depends on what length encodes in your model.
Some retrieval models are trained so that norm carries a notion of confidence or informativeness, and their authors specify inner product as the scoring function; using cosine there discards a signal the model was trained to emit.
Conversely, if length is an artefact — longer chunk, more tokens, bigger norm — dot product turns your search into a popularity contest won by your longest documents.
The rule is not “cosine is safer”.
The rule is: use the function the model card names, because the model was trained against that function.
Non-embedding vectors in the same table Vector columns get reused for things that are not embeddings — counts, TF-IDF rows, feature vectors, user-behaviour tallies.
None of those are normalised and none of the reasoning above applies.
There, magnitude is usually real information and Euclidean or dot product is often correct.
Documents of very different length in one index Even with a model that returns unit vectors, mixing 30-token titles with 2,000-token pages puts two different length regimes in one space, and pooling behaves differently across them.
Cosine does not fix this — the vectors are already normalised, so there is no magnitude left to divide out — which is worth stating because “use cosine” is the usual advice offered for it.
The fix is chunking to a consistent size, not a metric change.
After quantisation Binary quantisation replaces the metric entirely: a 1-bit vector is compared with Hamming distance, which is a popcount over an XOR and bears no arithmetic relation to the cosine of the originals.
Scalar int8 quantisation preserves ordering approximately but not exactly, so a similarity threshold calibrated on float32 will not hold.
Any threshold you set must be re-derived after a quantisation change.
The mismatch