A vector database stores embeddings and finds the ones closest to a query. Instead of asking which rows match exactly, you ask which are nearest in meaning.
A normal database is built for exact answers: this ID, that date range. A vector database is built for approximate ones, and it is fast because it accepts approximate rather than perfect results.
Think of it like this. Think of a librarian who has never read the catalogue but knows where every book sits by subject. Ask for something about grief and they walk you to the right shelf, including books whose titles never use the word.
How it works
- You bring the vectors. The database stores embeddings; another model produces them.
- It builds an index. Structures such as HNSW organise vectors so search does not have to compare against every one.
- Queries become vectors too. Your search text is embedded with the same model, then compared.
- It returns the top matches. The nearest k results, ranked by distance, usually with metadata attached.
Trade-offs
- Approximate by design. Nearest-neighbour search trades a little accuracy for a lot of speed. That is the deal, not a defect.
- Extra moving part. It sits alongside your main database rather than replacing it, so now you have two stores to keep in sync.
- Embedding lock-in. Changing embedding model means re-embedding and re-indexing everything.
Common mistakes
- "It replaces my database." It complements one. Your relational database still owns the actual records.
- "I need a dedicated one." For modest volumes, pgvector adds vector search to Postgres you already run.
- "Results are exact." Approximate nearest neighbour can miss a true best match, by design.
- "More dimensions means better search." Higher dimensions raise storage and query cost and can add noise.
