What is a vector database?

Traditional databases are excellent at exact matches such as "fetch customer 1042". Searching by meaning is a different job: to answer "how long do I have to return this?" you need the paragraph that says "you may withdraw within 14 days", even though the two share no words.

A vector database does that job. It stores the embedding vectors of your texts and returns the vectors closest to a query vector.

• Documents are split into chunks and each chunk is turned into a vector by an embedding model.
• The vectors are stored together with the text itself and extra fields such as source and date (metadata).
• When a question arrives it is embedded too, and the database returns the nearest records.

Comparing millions of vectors one by one would be slow, so these systems use approximate nearest neighbor (ANN) algorithms. One of the most common, HNSW, links vectors into a layered graph and narrows the search to the right region in a few hops. The trade off is that results are a very good approximation rather than perfectly exact.

Pinecone, Weaviate, Qdrant and Milvus are built specifically for vector search. Teams already on PostgreSQL can keep vectors in their existing database with the pgvector extension, and Elasticsearch and OpenSearch support vector search as well. For small and mid sized projects, adding vectors to the database you already run is often enough.

The best results frequently come from hybrid search, which combines vector search with classic keyword search. Keyword search is better at exact strings such as product codes or names.

The most common use is RAG: assistants that answer from company documents, semantic search in product catalogs and finding similar support tickets. The long term memory of AI agents usually lives in a vector database too.