AI & Machine Learning

Vector Database

A vector database stores high-dimensional embeddings: numerical representations of text, images, or other data, and finds the nearest matches by similarity at scale. It's the retrieval layer in most production AI systems, powering semantic search, RAG, recommendation engines, deduplication, and any application that needs to ask 'what's most similar to this?'

Also known as: Vector DB · Vector Store · Embedding Store
Last reviewed: 2026-05-13

At a glance

Category: AI & Machine Learning
Sections: 5 + closing
Related terms: 3
Reviewed: 2026-05-13

Definition

A vector database is purpose-built storage and retrieval for high-dimensional embeddings: numerical representations of text, images, code, audio, or other data that capture semantic content rather than literal tokens. Unlike a traditional row-store, it answers one question well. Given a query embedding, return the closest items by some similarity metric (cosine, dot product, Euclidean) at scale, in milliseconds. The data inside isn't documents or rows in the conventional sense. It's arrays of floating-point numbers, typically 384 to 4096 dimensions, that locate each item in a continuous semantic space where nearby points are conceptually related.

§01

How it works

A vector database has three stages: ingestion, indexing, and query. Ingestion takes the source content, embeds it through a model (OpenAI text-embedding-3-large, Cohere, BGE, or a fine-tuned encoder for domain corpora), and stores the resulting vector alongside the original document and metadata. Indexing builds an approximate-nearest-neighbor structure over those vectors so lookup is tractable at scale. HNSW (Hierarchical Navigable Small World) is the dominant choice for in-memory speed, IVF (Inverted File Index) with product quantization is the standard for memory-constrained or disk-resident workloads, and DiskANN is the emerging choice for billion-vector corpora. Query embeds the incoming question, walks the index for candidate matches, applies metadata filters (tenant ID, date range, document type), and optionally reranks the top-k with a cross-encoder before returning results.

§02

Why it's a separate database category

Traditional databases optimize for exact match, range queries, and indexed joins on structured columns. Vector similarity over millions or billions of high-dimensional points is a fundamentally different problem. Approximate-nearest-neighbor at sub-second latency requires specialized index structures, cache-aware memory layouts, and tradeoff knobs (recall vs latency, build time vs query time, in-memory vs on-disk) that row-stores don't expose. Bolting vector support onto Postgres works for small to mid-size corpora. pgvector handles tens of millions of vectors well, especially with HNSW indexes, and stays inside the team's existing operational surface. But at hundreds of millions of vectors, a dedicated store is materially faster, cheaper per query, and far easier to operate at the indexing and rebuild boundaries.

§03

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, deduplication, anomaly detection, or any 'find similar' operation that exceeds what a row-store can do. You don't need one if you're calling an LLM with prompts but have no corpus to retrieve from. Most generative AI applications without proprietary data don't need a vector store at all. You also don't need one if keyword search performs well enough on your data and you're not handling synonym-heavy or paraphrased queries. Pure vector search is rarely the right answer in production. Hybrid retrieval (BM25 + dense vectors + reranker) consistently outperforms pure vector on tail queries by 15 to 30 points of recall, so the right budget is for both retrieval modes plus the reranker, not for vector alone.

§04

Production options

The pragmatic shortlist breaks into three groups. Managed services: Pinecone (simple API, scales transparently, expensive at high vector counts and large dimensions), Weaviate Cloud, Qdrant Cloud, MongoDB Atlas Vector Search. Self-hosted open-source: Weaviate (full-text plus vector built in, GraphQL API, hybrid retrieval out of the box), Qdrant (Rust core, strong filtering performance, predictable latency), Milvus (highest scale, more complex operations), Chroma (lightweight, fits prototypes and small production cases). Extensions on existing stores: pgvector (Postgres extension, lowest operational overhead when the team already runs Postgres), Elasticsearch with dense vector support (best when Elasticsearch is already the system of record). Selection comes down to four dimensions: vector count and projected growth, latency budget, filtering and tenant-isolation complexity, and how much operational work the team can absorb. There's no universal best.

§05

Common pitfalls

Naive vector-database implementations fail in predictable ways. Choosing the store before measuring retrieval quality on real data leads to two migrations: first to the wrong store, then to the right one once production traffic exposes the gap. Skipping hybrid retrieval and assuming 'just use embeddings' costs 15 to 30 points of recall on the queries that matter most: short, ambiguous, or rare-term inputs. Indexing the wrong chunk granularity (whole documents instead of meaningful sections) collapses retrieval precision because the top match becomes a long document whose relevant passage is buried. Not measuring against a ground-truth eval set means accuracy regressions ship silently. And under-budgeting the reranker stage, on the theory that embeddings already rank well, drops final-answer accuracy below acceptable thresholds for regulated workloads.

Approach

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 or semantic-search engagement isn't which vector DB. It's which retrieval strategy: dense alone, sparse alone, hybrid, or hybrid plus a reranker, tested against a ground-truth eval set built from the corpus itself. Most teams over-invest in vector DB choice and under-invest in retrieval-quality measurement. We flip that ratio. The CORTEX department leads the eval-harness work, FOUNDATION (data engineering) handles ingestion pipelines and embedding-refresh cadence, and CITADEL covers data sovereignty for regulated corpora where the embeddings themselves carry confidentiality risk.

Talk to a senior engineer See the AI/ML practice

← All glossary entries

Vector Database

Also known as

Vector DB · Vector Store · Embedding Store

Last reviewed

2026-05-13