Vector database overview

A vector database stores high-dimensional vectors and finds nearest neighbors at query time, fast. Traditional databases store rows and look up by exact match or range. Vector databases store embeddings and look up by similarity. Both have their place, and serious RAG systems usually involve both.

What a vector database does

  1. Ingests vectors with associated metadata
  2. Indexes them in a structure optimized for nearest-neighbor queries
  3. Queries: given a query vector, returns the top-k nearest
  4. Filters: combine vector similarity with metadata predicates
  5. Updates: handles upserts, deletes, partial metadata updates

Why you can't just use Postgres

You can, actually, pgvector is a perfectly good choice for many workloads. But dedicated vector databases offer:

The decision: use pgvector until you're constrained by it. Move to a dedicated vector DB when you actually hit its limits.

The major players (2026)

Pinecone

Fully managed, serverless pricing model. Easiest to get started. Strong multi-tenancy. More expensive at scale than self-hosted alternatives. Namespaces are powerful.

Weaviate

Open-source with managed option. Strong hybrid search (native BM25 + vector). Rich filtering. Good for production.

Qdrant

Open-source, Rust-based, extremely fast. Strong quantization support (scalar, binary). Excellent filtering performance. Easy self-hosting.

Milvus

Open-source, enterprise-grade. Scales to billions of vectors. Complex to operate. Best for very large deployments.

Chroma

Open-source, embeddable. Great for prototyping and small-to-medium workloads. Not battle-tested at massive scale (yet).

pgvector

Postgres extension. Free, familiar, integrates with existing databases. Good for hundreds of thousands to low millions of vectors. Less purpose-built indexes than dedicated vector DBs.

Turbopuffer

Newer serverless vector DB designed for cost. S3-backed storage with caching. Very cheap per stored vector.

Vespa

Yahoo's battle-tested search engine, now open-source. Handles vector search alongside full-text, filtering, ranking. Complex but powerful.

Elasticsearch / OpenSearch

Full-text search platforms with vector support. Natural fit if you already run them for BM25.

LanceDB

Open-source embedded vector DB built on Apache Arrow. Good for local-first and notebook workflows.

FAISS (not a database)

Facebook's library for vector similarity search. Not a database, no persistence, no filtering, no API. But the underlying algorithms of many vector DBs. Use directly for research, not production.

Comparison dimensions

Managed vs self-hosted

Pinecone and Weaviate Cloud vs Qdrant, Milvus, pgvector on your own infra. The tradeoff is standard: cost vs ops burden.

Scale

Hybrid search

Weaviate, Qdrant, OpenSearch, and Vespa have the best native hybrid search. Pinecone now supports sparse vectors. See hybrid search.

Filtering performance

Qdrant and Weaviate have excellent filtered search. Pinecone's filtering is adequate. pgvector with proper indexes can be very fast on structured filters.

Multi-tenancy

Pinecone's namespaces are clean. Weaviate has per-tenant shards. For multi-tenant RAG, these features matter a lot. See multi-tenant RAG.

The decision framework

  1. Starting out, low volume: pgvector or Chroma. Cheap, simple.
  2. Growing, managed preference: Pinecone. Fast to scale, costs predictable.
  3. Growing, self-hosted preference: Qdrant or Weaviate. Full control.
  4. Very large scale: Milvus or Vespa.
  5. Need full-text + vectors in one system: Elasticsearch / OpenSearch / Vespa.
  6. Already running Postgres heavily: pgvector, unless you hit limits.

Most vector DB decisions are reversible with some migration effort. Don't over-optimize this choice early.

Next: HNSW, IVF, PQ.