A database optimized for storing and searching high-dimensional vectors (embeddings), enabling semantic search, RAG pipelines, and AI-powered applications.
Five years ago, vector databases were a niche concern. Now, if you're building anything with an LLM, you probably need one — or at least need vector search in whatever database you already use. The category exists for one reason: LLMs have bounded context windows and poor factual recall, so you need a way to retrieve "the right chunks" from your own knowledge and stuff them into the prompt. Vector similarity search is how you do that at scale.
Most teams overthink vector DB selection. The real question in 2026 isn't "Pinecone vs. Weaviate vs. Milvus" — it's "do I need a dedicated vector DB at all, or will my existing database's vector support do the job?" For most teams with <10M vectors: Postgres + pgvector, Snowflake's VECTOR_COSINE_SIMILARITY, or Elasticsearch's kNN search is enough. You skip an entire piece of infrastructure. Dedicated vector DBs start to pay off when you have hundreds of millions of vectors, need sub-50ms p99 at high QPS, or want features like hybrid search (vector + BM25) baked in.
On one project we built a RAG pipeline for internal documentation — ~200K chunks, maybe 50 queries/minute. The team's first instinct was Pinecone ("it's the default!"). Cost estimate: ~$70/month. We ended up using pgvector on the Postgres we already had — index build took 3 minutes, queries returned in 15-30ms, and the incremental cost was zero because the RDS instance was already there. Six months later, nothing has forced us off pgvector. The point isn't that Pinecone is wrong; it's that "you need a vector database" is a much weaker statement than "you need vector search." For a lot of RAG workloads, the latter can be solved inside your existing stack.
A Vector Database is a specialized database designed to store, index, and query high-dimensional vectors (also called embeddings). These vectors are numerical representations of unstructured data — text, images, audio — generated by AI models. Vector databases power the retrieval layer of AI applications like RAG (Retrieval-Augmented Generation), semantic search, and recommendation engines.
1. EMBED: Convert data to vectors using AI models
"Snowflake Architecture" → [0.23, -0.45, 0.78, ...] (768 dimensions)
2. STORE: Index vectors for fast similarity search
Vector DB stores millions of vectors with metadata
3. QUERY: Find similar vectors using distance metrics
"cloud data warehouse" → Find top 10 most similar documentsTraditional databases search by exact match (WHERE name = 'John'). Vector databases search by similarity — finding items that are conceptually close, even if they share no keywords.
| Traditional Search | Vector Search |
|---|---|
| WHERE title LIKE '%snowflake%' | Find articles about cloud data warehousing |
| Exact keyword matching | Semantic meaning matching |
| Misses synonyms and context | Understands intent and relationships |
| Database | Type | Best For |
|---|---|---|
| Pinecone | Managed SaaS | Production RAG, zero-ops |
| Weaviate | Open Source | Hybrid search (vector + keyword) |
| Milvus | Open Source | Massive scale (billions of vectors) |
| Qdrant | Open Source | Rust-based performance |
| Chroma | Open Source | Local development, prototyping |
| pgvector | PostgreSQL Extension | Adding vectors to existing Postgres |
| Snowflake Cortex | Integrated | Snowflake-native RAG |
Hard-won lessons from building RAG in production:
tenant_id or date > X before vector search (pre-filter) is much faster than post-filter, but requires the DB to support it efficiently. Test your filter patterns at scale before committing.ef_search/nprobe to your workload and monitor recall drift as your data grows.A vector database stores data as lists of numbers (vectors) that represent the meaning or features of text, images, or other content, and lets you find items with similar meaning by comparing those vectors mathematically. Instead of searching for exact keyword matches, you search for conceptual closeness — "find me documents that talk about anything similar to this paragraph." This is the core capability that makes retrieval-augmented generation (RAG) and semantic search work: you embed text into vectors with an AI model, store the vectors, and at query time find the nearest neighbors.
Large language models have two problems: a limited context window (they can't read your whole knowledge base) and a tendency to hallucinate (make up facts). Vector databases solve both by acting as long-term memory: you embed your organization's documents, store them, and at query time retrieve only the chunks most relevant to the user's question, then hand those to the LLM. This is the RAG pattern, and it dramatically improves factual accuracy while staying within model context limits. Without a vector store, you either shrink your knowledge base to fit in-context or accept hallucinations.
Regular databases (Postgres, MySQL, Snowflake) excel at exact match and range queries — WHERE id = 5, WHERE date > '2025-01-01'. Vector databases specialize in approximate nearest-neighbor (ANN) search: given a query vector, find the K most similar stored vectors using distance metrics like cosine similarity. They use indexes like HNSW or IVF that are built for high-dimensional similarity rather than the B-trees used by relational databases. In practice, many modern databases (Postgres via pgvector, Snowflake via VECTOR types, MongoDB, Elasticsearch) now support vector search alongside their traditional queries, blurring the category line.
Yes. Snowflake added native VECTOR types, VECTOR_COSINE_SIMILARITY / VECTOR_L2_DISTANCE functions, and Cortex Search — a managed hybrid (vector + keyword) search service. For teams already on Snowflake, this is often the easiest path: your embeddings live next to your other data, you use one governance model, and you avoid a separate vector infrastructure. The tradeoff vs. dedicated vector DBs: Snowflake's query latency is warehouse-scale (~100ms-1s) which is fine for batch and some interactive workloads but not for ultra-low-latency (sub-50ms) real-time serving at high QPS.
Pinecone is the fully managed SaaS option — easiest to operate, no infrastructure to manage, strong at pure vector search; costs can scale up fast. Weaviate is open source with excellent hybrid search (vector + BM25) and built-in modules for common AI workflows; available self-hosted or as Weaviate Cloud. Milvus is open source, built for massive scale (billions of vectors), strongest when you have huge corpora and want to self-host. For most teams starting out, the real decision is whether to use any of them vs. pgvector/Cortex on existing infrastructure. Dedicated vector DBs pay off when scale, latency, or feature needs exceed what a general database can do.
HNSW (Hierarchical Navigable Small World) is the dominant indexing algorithm for vector search. It builds a multi-layer graph where similar vectors are connected, letting queries find approximate nearest neighbors in sub-linear time. Tradeoffs: HNSW is fast and accurate but memory-heavy (often 2-3x the raw vector size) and slow to build. Alternatives: IVF (Inverted File) is cheaper but less accurate; PQ (Product Quantization) compresses vectors aggressively for huge datasets. Most vector DBs default to HNSW because the accuracy/speed profile fits most workloads. Tune parameters `M` (graph connectivity) and `ef_construction`/`ef_search` for your recall and latency needs.
Usually, yes. pgvector is a Postgres extension that adds vector types and HNSW/IVF indexes to standard Postgres. It's production-used at meaningful scale — millions to tens of millions of vectors — and inherits all of Postgres's strengths: transactions, SQL joins, metadata filtering, existing ACL, existing ops. Where it falls short vs. dedicated vector DBs: performance past ~50-100M vectors, built-in hybrid search (you combine with Postgres full-text search yourself), and features like multi-tenancy or namespace isolation. For most teams building their first RAG system, pgvector is the right starting point — add a dedicated vector DB only when you have measured reason to.