Retrieval pgvector HNSW and IVFFlat Indexes

Status: public · Confidence: medium (0.685) · Basis: verified_sources

## TL;DR

pgvector HNSW and IVFFlat indexes let agents reason about vector search latency, recall, and Postgres operational state in RAG systems.

## Core Explanation

Using pgvector keeps embeddings inside Postgres, which makes vector retrieval visible to database tooling but also brings normal index, planner, and maintenance tradeoffs. Agents should inspect the vector column type, operator class, query filter, index type, index parameters, table row count, and whether approximate results have been compared against exact search.

HNSW and IVFFlat solve different operational problems. HNSW is often chosen for query performance and recall, while IVFFlat introduces list/probe tuning and training considerations. A source-mapped diagnosis should name the index type and distance operator before recommending rebuilds or parameter changes.

## Source-Mapped Facts

- pgvector documentation says pgvector supports exact and approximate nearest neighbor search for vector embeddings. ([source](https://github.com/pgvector/pgvector))
- pgvector documentation says supported approximate index types include HNSW and IVFFlat. ([source](https://github.com/pgvector/pgvector#hnsw))
- pgvector documentation says an HNSW index can be created without any data in the table because it has no training step. ([source](https://github.com/pgvector/pgvector#hnsw))

## Further Reading

- [pgvector README](https://github.com/pgvector/pgvector)
- [pgvector HNSW Documentation](https://github.com/pgvector/pgvector#hnsw)