What is Vector Database?

The plain definition

Finding the closest vectors to a query is trivial at small scale — compare against everything and sort. At ten million vectors that brute-force scan is far too slow for a live request. A vector database exists to make that search fast, along with the ordinary database concerns of persistence, updates, filtering, and access control.

The core trick is approximate nearest neighbour search. Exact search is expensive; approximate search accepts a small probability of missing a true nearest neighbour in exchange for orders-of-magnitude speedup. For retrieval applications that trade is almost always correct, because returning the 2nd through 11th best passages instead of the 1st through 10th makes no practical difference to output quality.

The index types you will meet

HNSW (hierarchical navigable small world) builds a layered graph and greedily walks it toward the query. It gives excellent recall and low latency, supports incremental inserts well, and uses a lot of memory. It is the sensible default.

IVF partitions the space into clusters and searches only the nearest few. Cheaper on memory, requires a training step over representative data, and handles updates less gracefully.

Product quantisation compresses vectors into compact codes, cutting memory dramatically at some cost to recall. Usually combined with IVF for very large collections.

Each exposes a recall/latency dial — ef_search in HNSW, number of probes in IVF. That dial is a tuning decision you should make deliberately against measured retrieval quality, not leave at the library default.

You may not need a dedicated one

This is the most useful thing to know before adopting new infrastructure. Under roughly a million vectors, pgvector in PostgreSQL is usually the right answer. You keep one database, transactional consistency, familiar operations, and — importantly — the ability to filter on ordinary SQL columns in the same query as the similarity search. That last point matters more than raw speed: most real queries are 'find similar documents that this user is allowed to see and that are not archived', and combining vector search with structured filters is where naive setups fall apart.

Dedicated systems earn their place at genuine scale, or when you need features they specialise in. Managed options remove operational burden; self-hosted engines give control; and libraries such as FAISS are the right choice when you want an in-process index with no server at all.

Whatever you choose, plan for re-embedding from the start. Embedding models improve, and upgrading means regenerating every vector in the corpus — see embeddings on why vectors from different models cannot be mixed. Keep the source content and the pipeline that produced the vectors reproducible, so a re-index is a scheduled job rather than a crisis.