A vector database is purpose-built for one operation: given a query embedding, return the closest items by some similarity metric (cosine, dot product, Euclidean) at scale. The data inside isn't documents or rows in the traditional sense: it's arrays of floating-point numbers, typically 384 to 4096 dimensions, that capture the semantic content of whatever was embedded.
Why this is a separate database category
Traditional databases excel at exact match and range queries on indexed columns. Vector similarity over millions or billions of high-dimensional points needs different data structures (HNSW, IVF, ScaNN) and different memory layouts. Bolting these onto Postgres works for small corpora (and pgvector is excellent for that), but at scale a dedicated vector store is faster and cheaper per query.
When you need one (and when you don't)
You need a vector database when you're doing semantic search, RAG over a corpus, recommendation, or any 'find similar' operation at scale. You don't need one if you're just calling an LLM with prompts: most generative AI use cases that don't have a corpus don't need a vector store at all. Hybrid search (keyword + vector) often outperforms pure vector search; budget for both.
Production options
The pragmatic shortlist: Pinecone (managed, simple, expensive at scale), Weaviate (open-source, self-hostable, full-text + vector built in), Qdrant (open-source, performant, good filtering), pgvector (Postgres extension, best for teams already on Postgres), Elasticsearch with dense vector support (best when you already have an Elasticsearch deployment). Choice depends on scale, latency budget, filtering requirements, and how much operational work the team can absorb.
How Prosigns approaches vector databases
We pick the store after we've measured retrieval quality on the client's real data: never before. The first decision in a RAG engagement isn't which vector DB but which retrieval strategy: dense alone, sparse alone, hybrid, or hybrid plus a reranker. Most teams over-invest in vector DB choice and under-invest in retrieval quality measurement; we flip that ratio.