The short answer
A vector database stores text as numerical embeddings and finds passages by meaning rather than exact keywords. You need one when you are doing semantic search or RAG at a scale where similarity search has to be fast. Below roughly a hundred thousand chunks, a Postgres extension usually does the job without adding a new service to your stack.
What an embedding actually is
An embedding turns a passage into a list of numbers positioned so that similar meanings sit close together. "How do I reset my password?" and "I forgot my login" land near each other even though they share almost no words. That is the whole trick, and it is why semantic search finds things keyword search misses.
When you need a dedicated vector database
Millions of chunks where brute-force similarity search becomes too slow.
You need approximate nearest-neighbour indexing with tunable recall/latency tradeoffs.
Filtered vector search across large metadata sets is a core query pattern.
Under that, pgvector inside the Postgres you already run avoids an extra service, an extra backup story, and an extra failure mode.
The part that matters more than the database
Teams argue about which vector database to use and then lose all the quality they gained to bad chunking and no re-ranking. The index is rarely the bottleneck. Retrieval quality is.