Definition: A vector database finds the items closest in meaning to whatever you ask, instead of matching exact words. It stores, indexes, and searches high-dimensional numeric vectors, typically embeddings produced by a neural network. Where a relational database answers "give me rows where status = 'active'," a vector database answers "give me the 10 items whose meaning is most similar to this one." That single primitive, approximate nearest-neighbor (ANN) search over dense vectors, powers semantic search, RAG, agentic RAG, recommendation systems, and every AI feature where "similar" matters more than "exact match."
The category grew from a handful of research prototypes in 2018 to a crowded $2B+ infrastructure market by 2026. Pinecone, Weaviate, Qdrant, Milvus, Chroma, pgvector, MongoDB Atlas Vector Search, Redis Vector, and OpenSearch all compete for the same job: turn embeddings into retrievable memory for AI systems.
TL;DR: A vector database stores embeddings and runs approximate nearest-neighbor search to return items by meaning, not keyword match. It is the memory layer behind semantic search, RAG, and agent memory. In Taskade Genesis, it runs automatically. Build an app free →
Why Vector Databases Exist
Vector databases exist because finding the most similar item among millions of high-dimensional vectors is too slow for a regular database. They build an approximate nearest-neighbor index that skips most candidates and scores only a shortlist, so queries return in milliseconds instead of seconds. No relational, graph, or keyword index can do this.
Embeddings represent meaning as a list of numbers. A 1,536-dimensional OpenAI embedding places the sentence "cat sat on the mat" at a specific coordinate in a 1,536-dimensional space where semantically similar sentences are nearby. The trouble is finding the nearest neighbors in 1,536 dimensions when you have 100 million vectors. A naive linear scan costs 100 million dot products per query: slow, expensive, and impossible in real time.
Vector databases solve this with approximate nearest neighbor indexes. Instead of checking every vector, they build a structure that eliminates most candidates cheaply and only computes distances on a small shortlist. The tradeoff is recall (you might miss the absolute best match) for speed (queries land in milliseconds instead of seconds).
This tradeoff is the entire reason vector databases are a category. A relational database cannot do it. A graph database cannot do it. Even a full-text index (BM25) cannot, because semantic similarity is not keyword overlap. You need an index that respects geometry in continuous space.
How a Vector DB Fits in the Stack
The vector DB is the memory layer. Embeddings go in, nearest-neighbor results come out. Everything else is plumbing around that single primitive.
How Semantic Search Finds the Right Answer
Semantic search works by turning your question and every stored item into coordinates in the same meaning-space, then returning the items sitting closest to your question. "Cancel my plan" lands near "how do I end my subscription" even though they share zero keywords, because both describe the same intent. Distance equals relevance.
You already rely on this instinct. When you skim a folder for "the contract with the pricing change" and grab the right file without reading every word, you are matching meaning, not text. A vector database does that at scale, in milliseconds, across millions of items.
The result is a search that forgives paraphrase, typos, and synonyms. Ask in your own words and the right answer surfaces, even when the source document said it differently.
Core Algorithms
Three index families dominate:
HNSW (Hierarchical Navigable Small World). A layered graph where each node is connected to its nearest neighbors. Search starts at the top layer (few nodes, long edges) and descends to the bottom (many nodes, short edges). Fast, high recall, memory-heavy. The default in Qdrant, Weaviate, pgvector, and most managed offerings. It is the kind of index that lets an AI agent find the right content by meaning, not keywords.
IVF (Inverted File Index). Clusters vectors into partitions using k-means. At query time, search only the nearest k partitions. Memory-light, recall tunable by nprobe. The workhorse in FAISS and Milvus for billion-scale corpora.
Product Quantization (PQ). Compresses each vector into a compact code by splitting dimensions into sub-vectors and quantizing each. Combined with IVF (IVF-PQ) for disk-backed deployments where memory is the bottleneck.
Most production systems blend these: IVF-HNSW, IVF-PQ, HNSW + PQ compression. The knobs trade recall, latency, memory, and index build time against each other.
HNSW graph (simplified)
Layer 2: o─────────o──────────o coarse, long edges
\ / \ /
Layer 1: o─o───o─o───o────o─o mid-grain
\| \ / | \ / \ | |
Layer 0: o─o─o─o─o─o─o─o──o─o─o dense, short edges
^
query enters top, descends, lands near match
What a Vector Database Stores
A vector DB typically holds four things per record:
| Field | Purpose |
|---|---|
| ID | Primary key to look the record up |
| Vector | The dense embedding (e.g. 1,536 floats) |
| Metadata | Structured filters (date, tenant, document ID, category) |
| Payload | Raw text or document pointer for generation |
The metadata is critical. A pure similarity search returns "things most like this." Production systems almost always need "things most like this AND in this tenant AND more recent than Tuesday." Metadata filtering turns a vector DB from a toy into infrastructure.
Distance Metrics
Three distances cover 95% of use cases:
- Cosine similarity. Angle between vectors. Scale-invariant. Default for text embeddings.
- Dot product. Cosine with magnitude baked in. Cheaper and used when embeddings are already normalized.
- Euclidean (L2). Straight-line distance. Used for image embeddings and some clustering tasks.
Match the metric to the embedding model. OpenAI's text-embedding-3-large is normalized; use cosine or dot product. Mismatching the metric silently degrades recall.
Typical Architecture
A production vector DB sits inside a larger retrieval pipeline:
- Ingest. Content is chunked (paragraphs, sentences), embedded by a model, and upserted with metadata.
- Index. The database builds or updates an ANN index in the background.
- Query. The user's question is embedded by the same model family, then used as the query vector.
- Filter. Metadata filters narrow to tenant, date range, document type.
- Search. ANN returns top-k candidates with scores.
- Rerank. A smaller model re-scores candidates for semantic fit.
- Generate. An LLM produces the final answer, grounded in the reranked chunks.
The same architecture underlies every RAG system, every agentic RAG pipeline, and the retrieval half of every AI agent that answers from a private corpus.
Hybrid Search
Pure vector search misses things. Proper nouns, product codes, rare typos are exactly what BM25 nails and what embeddings blur. Production systems run hybrid search: vector and keyword queries in parallel, scores combined by a weighted sum or reciprocal rank fusion, then reranked.
Taskade's workspace search is hybrid by default: semantic similarity for meaning, full-text for precision, OCR for scanned documents. Agents doing agentic RAG inside Taskade call hybrid search as one of their 34 built-in tools and get the best of both worlds. The same retrieval can feed a reliable automation workflow, so an answer triggers an action instead of stopping at the screen.
Scaling Considerations
| Corpus Size | Practical Stack |
|---|---|
| < 100K vectors | pgvector + cosine, single Postgres node |
| 100K–10M | Qdrant, Weaviate, or pgvector with HNSW, single node |
| 10M–1B | Qdrant or Milvus cluster, IVF-HNSW with sharding |
| > 1B | FAISS or Milvus with IVF-PQ, disk-backed, GPU optional |
The right pick is a function of corpus size, query QPS, recall target, latency budget, and ops capacity. Over-engineering for 10M vectors with a Kubernetes cluster is a common 2024 mistake; pgvector with HNSW handles it comfortably.
Vector Databases in Taskade Genesis
Every Taskade workspace has semantic search built in, so you never provision, tune, or manage a vector database yourself. When you search your projects, ask an agent a question, or build a Taskade Genesis app that answers from your knowledge base, retrieval runs through the same hybrid pipeline this article describes: semantic similarity for meaning, full-text for precision, and OCR for scanned documents.
There is no index to provision, no ANN tuning, no reranker to configure. Upload a document, write a project, or connect one of the 100+ integrations, and Taskade embeds and indexes it in the background. Your agents can retrieve it the moment it is indexed. The vector database is part of your workspace DNA, the Memory layer that feeds Intelligence and Execution, not a separate piece of infrastructure to operate.
Build It in Taskade
You already keep a knowledge base somewhere: a folder of SOPs, a shared drive of policies, a wiki nobody can find anything in. The hard part was never storing it. It was getting the right answer back when someone asks in their own words.
In Taskade Genesis, describe it in one sentence and you get a working client or member portal. Your team or your members log in, type a question in plain English, and an agent answers from your indexed documents with the source attached. Behind the glass, semantic search does the matching. They never see a vector, an embedding, or an index. They just get the answer. Drop in a new policy and the portal knows it the next time someone asks. Build one free with a single prompt →
Related Concepts
- Embeddings: the vectors a vector DB stores
- Retrieval-Augmented Generation: the primary use case
- Agentic RAG: agent-driven retrieval
- Knowledge Graph: a symbolic alternative
- Semantic Search: what vector DBs power
- Agent Memory: long-term memory for agents often uses a vector DB
- AI Agents: the main consumers
Frequently Asked Questions About Vector Databases
What is a vector database?
A vector database is a specialized database for storing and searching high-dimensional numeric vectors, usually embeddings from a neural network. Instead of exact matches, it returns items whose vectors are geometrically similar, which approximates semantic similarity.
Why not use a regular database?
A regular database can store vectors but cannot search them efficiently. Finding the 10 nearest vectors out of 100 million in 1,536 dimensions requires an approximate nearest-neighbor index (HNSW, IVF, PQ) that only vector databases implement natively.
What is HNSW?
HNSW (Hierarchical Navigable Small World) is a graph-based approximate nearest-neighbor algorithm that builds a layered graph of vectors. Queries traverse from coarse to fine layers, finding near-matches in logarithmic time. It is the default algorithm in most modern vector databases.
Do I need a vector database to use Taskade Genesis?
No. Vector search is built into every Taskade workspace automatically. Upload a document, write a project, or connect an integration, and Taskade embeds and indexes it in the background. Your agents can search your workspace semantically from day one with no setup.
What is hybrid search?
Hybrid search combines vector (semantic) and keyword (BM25) search, then merges the scores. It catches both paraphrased queries and exact-match proper nouns or codes. Taskade's workspace search is hybrid by default, adding OCR for scanned documents.