Skip to content

Learn AI · Foundations

Vector Databases Explained

What vector databases actually do, when you need one, and what the real tradeoffs between Pinecone, Weaviate, Qdrant, and pgvector look like.

7 min readPublished Mar 2025Updated Apr 2026
Vector DBPineconepgvectorRAG
Edited by The AIKnowHub team · Editorial team

Key takeaways

  • 1Vector DBs trade a tiny bit of recall for huge speed via Approximate Nearest Neighbor (HNSW being most common).
  • 2Under ~100K vectors, you don't need one — a NumPy array or SQLite works.
  • 3pgvector is the most under-rated default — you already have Postgres.
  • 4Hybrid search (vectors + BM25 + reranker) almost always beats vectors-only.
  • 5Most RAG quality comes from chunking and reranking, not from picking a fancy DB.

What they actually do

A vector database stores embeddings and answers one question very fast: "Given this vector, find the K most similar vectors in the index."

That's it. Everything else — filters, hybrid search, multi-tenant indexes — is layered on top.

Under the hood, they use Approximate Nearest Neighbor (ANN) algorithms — HNSW is the most common — that trade a tiny bit of accuracy for orders of magnitude more speed.

When you actually need one

You need a vector database when:

  • You have millions of vectors.
  • You need sub-100ms queries.
  • You need metadata filtering alongside vector search.

You probably don't need one if:

  • You have fewer than ~100K vectors → a flat NumPy array in memory works.
  • Your data fits in Postgres → pgvector is excellent up to ~5M vectors.

The landscape

pgvector (Postgres extension) — the pragmatic default. You already have Postgres. It does vector search, joins, transactions, and SQL. Scales to a few million vectors comfortably.

Qdrant — fast, self-hostable, great filtering. Written in Rust. Open source. Best dev experience for self-hosted setups.

Weaviate — built-in vectorization, GraphQL API, modular. More features but more concepts to learn.

Pinecone — fully managed, serverless tier is cheap to start. Closed source. Pay for convenience.

Milvus — designed for scale (billions of vectors). Heavy to operate.

LanceDB — embedded, columnar, great for analytical workloads. New but growing fast.

Picking one

ConstraintPick
You use Postgrespgvector
You want zero opsPinecone
You self-host, need speedQdrant
You want batteries-includedWeaviate
You're embedded / on-deviceLanceDB
You have >100M vectorsMilvus / Vespa

What to actually optimize

People over-index on the DB and under-index on:

  1. Chunking strategy — far more impact than DB choice.
  2. Embedding model quality — switching from a mediocre model to a great one moves recall more than switching DBs.
  3. Hybrid search — dense + BM25 + rerank.
  4. Metadata filters — narrowing by user_id, doc_type, or date often does more than improving similarity scores.

A boring DB with great retrieval engineering beats a fancy DB with naive retrieval every single time.

Common misconceptions

The wrong-but-common takes worth correcting.

Myth

I need a vector database to use embeddings.

Reality

At small scale, brute-force search across an array of vectors works fine. Vector DBs become useful when scale or filtering demands them.

Myth

Pinecone is the production choice.

Reality

Pinecone is *a* production choice — fully managed, easy to start. pgvector, Qdrant, and Weaviate are all production-grade alternatives with different tradeoffs.

Myth

Vector search alone is enough for good retrieval.

Reality

Dense vector search misses exact-term matches and rare tokens. Hybrid retrieval (vectors + keyword + rerank) consistently beats pure vector search on real corpora.

Real-world use cases

Frequently asked questions

pgvector is a Postgres extension — you self-host, you get SQL, joins, and transactions, and it scales well to a few million vectors. Pinecone is a fully managed service — pay them and forget operations, but you lose SQL and pay more at scale.

Related on AIKnowHub