---
title: "Comment by Ahmet Özel on \"Choosing a Vector Database: pgvector vs Dedicated Stores\" | Hashnode"
description: "The exact-search baseline should separate approximation loss from representation loss. In your example, both the indexed query and the forced exact scan operate"
url: "https://hashnode.com/posts/choosing-a-vector-database-pgvector-vs-dedicated-stores-gr2u4/6ae560a0e231ee21ec3f6e3c/comment/6ae790cd4a395385cf1ef4c6"
---

[Discussion](https://hashnode.com/posts/choosing-a-vector-database-pgvector-vs-dedicated-stores-gr2u4/6ae560a0e231ee21ec3f6e3c)

Comment [Choosing a Vector Database: pgvector vs Dedicated Stores](https://hashnode.com/posts/choosing-a-vector-database-pgvector-vs-dedicated-stores-gr2u4/6ae560a0e231ee21ec3f6e3c)

[Ahmet Özel](https://hashnode.com/@ahmetozel)

[Nov 1](https://hashnode.com/posts/choosing-a-vector-database-pgvector-vs-dedicated-stores-gr2u4/6ae560a0e231ee21ec3f6e3c/comment/6ae790cd4a395385cf1ef4c6)

The exact-search baseline should separate approximation loss from representation loss. In your example, both the indexed query and the forced exact scan operate on halfvec(1536), so the comparison measures ANN recall within the already quantized space. It does not show whether float16 storage changed the neighbors relative to the original float32 embeddings.

I would report two deltas: original-vector exact search versus halfvec exact search, then halfvec exact search versus its HNSW result. That would make the memory-saving decision independent of the index-tuning decision, particularly for nearly tied neighbors.

[ZyVOP](https://hashnode.com/@zyvop)

[Nov 2](https://hashnode.com/posts/choosing-a-vector-database-pgvector-vs-dedicated-stores-gr2u4/6ae560a0e231ee21ec3f6e3c/comment/6ae790cd4a395385cf1ef4c6#reply-6ae83736fa2e89bfc5ee5b2a)

That’s a really good distinction. You’re right that comparing HNSW against an exact scan on `halfvec` only measures ANN recall within the quantized space, not the loss introduced by converting from float32 to float16. Separating those two deltas would make the trade-off much clearer, especially when nearest neighbors have very similar distances. Would you also recommend tracking ranking changes in addition to recall, since even small distance differences can affect the top-k ordering?

[Ahmet Özel](https://hashnode.com/@ahmetozel)

[Nov 6](https://hashnode.com/posts/choosing-a-vector-database-pgvector-vs-dedicated-stores-gr2u4/6ae560a0e231ee21ec3f6e3c/comment/6ae790cd4a395385cf1ef4c6#reply-6aedf79a9e48a18824c999ad)

Yes. Recall can stay perfect when exactly the same neighbors appear in a different order, so it misses a change that matters if the application consumes only the first few results. I would record rank displacement for the original exact top results and overlap at the smaller cutoff actually used downstream.

Keep the same two comparisons: float32 exact versus halfvec exact, then halfvec exact versus HNSW. Also define tie handling, because swapping almost equal distances should not be interpreted like displacing a clearly better neighbor.