What is a vector database for?
Ordinary search matches words. A vector database matches meaning. It works on embeddings, which are lists of numbers that an embedding model produces to represent a piece of text, so that passages with similar meaning end up close together in that numeric space. Ask it a question and it turns the question into a vector too, then finds the stored vectors nearest to it. The source passages behind those vectors come back as your results.
That is why it is the engine behind retrieval-augmented generation (RAG): the step where a system pulls relevant context out of a document pile before the model answers is a nearest-neighbour search, and that is exactly what a vector database does. Some people call it a vector store. Same idea.
Where does it fit, and where does it fall short?
The vector database is one stage in a pipeline, not the whole thing. Before it, documents are split into passages (chunking) and turned into embeddings. The store searches those embeddings. After it, a reranker often reorders the hits, because nearest in vector space is not always the most relevant to the question.
So its quality is borrowed. Feed it good chunks and good embeddings and it returns useful passages fast. Feed it badly split text or a weak embedding model and it returns near-misses with full confidence. It finds what is closest, not what is correct. The surrounding steps are what make closest worth having.