A vector database stores information as embeddings, which are long lists of numbers that capture the meaning of a piece of text, an image, or audio. Similar items end up with similar numbers, so the database can answer questions like find the passages most related to this one, even when they share no exact words. Search stops being about matching characters and becomes about matching intent.
This is the storage layer behind most retrieval-augmented generation. You convert your documents into embeddings once, keep them in the vector store, and at query time convert the user's question the same way and pull the nearest matches. Keyword search would miss a question about time off when the document says vacation policy; meaning-based search does not.
Options range from dedicated services like Pinecone and Weaviate to extensions that add vector search to a database you already run, such as Postgres with pgvector. For an early product, reusing your existing database often beats adding a new piece of infrastructure to operate and pay for.
The details that decide performance are the embedding model you choose, the similarity measure, and how you filter results by metadata like date or category. Getting these right matters more as your document count climbs into the millions, where naive search slows down and index tuning starts to earn its keep. Most teams tune this only once scale forces the issue.