Vector Database Comparison Deep Dive

What a vector database actually needs to do well

A vector database's core job sounds simple: given a query vector, return the k nearest stored vectors by some distance metric (cosine similarity, dot product, or Euclidean distance). In practice, doing this well at scale involves several distinct engineering problems: the indexing algorithm (how vectors are organized so search doesn't require comparing against every single stored vector), metadata filtering (restricting search to a subset of vectors matching other criteria, like user_id = 123), hosting and operations (who manages the infrastructure), and hybrid search (combining vector similarity with keyword/BM25 matching).

Different products made different tradeoffs across these dimensions, which is why 'which vector database should I use' doesn't have one universal answer — it depends on your scale, your ops appetite, and whether you're starting from an existing stack.

Indexing approaches: the ANN algorithm underneath

Exact nearest-neighbor search (compare the query against every stored vector) doesn't scale past a small number of vectors. All production vector databases instead use Approximate Nearest Neighbor (ANN) indexing, trading a small amount of recall accuracy for massive speed gains.

The dominant algorithm across most modern vector databases is HNSW (Hierarchical Navigable Small World graphs) — a layered graph structure where search starts at a coarse top layer and descends to progressively finer layers, narrowing in on nearby vectors without visiting most of the dataset. Pinecone, Weaviate, and Qdrant all use HNSW (with their own tuning and extensions) as their primary index. pgvector supports HNSW as well as IVFFlat (inverted file index), an older, simpler approach that partitions vectors into clusters and only searches the most relevant clusters — generally faster to build but somewhat less accurate than a well-tuned HNSW index at the same speed.

Pinecone — fully managed, operationally simplest

Pinecone is a closed-source, fully managed vector database: you don't run any infrastructure, you call an API. It handles scaling, replication, and index maintenance behind the scenes, with metadata filtering built in from the start. This makes it the fastest path to a production deployment when you don't want to own infrastructure.

The tradeoff is cost at scale (you're paying for a managed service, not just raw compute) and less control over the underlying index behavior compared to self-hosted options. It's a strong default when speed-to-production matters more than cost optimization or infrastructure control.

Weaviate — open-source with strong hybrid search

Weaviate is open-source (with a managed cloud option available too) and distinguishes itself with first-class hybrid search: combining dense vector similarity with sparse keyword search (BM25) in a single query, with built-in fusion of the two ranked result sets. It also supports more complex schemas — defining classes/objects with typed properties, similar to a lightweight object database layered on top of vector search.

This makes Weaviate a good fit when your retrieval needs go beyond pure semantic similarity — for example, when exact keyword or identifier matches (part numbers, names, specific terms) need to be found reliably alongside semantically similar content.

Qdrant — open-source, Rust-based, built for speed and self-hosting

Qdrant is open-source and written in Rust, generally benchmarking as one of the fastest options for raw vector search throughput, particularly when self-hosted on your own infrastructure. It supports rich metadata filtering integrated directly into the HNSW search (filtering during traversal rather than after retrieval, which avoids wasting search effort on candidates that would be filtered out anyway), and offers a managed cloud option as well as straightforward self-hosting via Docker.

It's a strong choice when performance and self-hosting control matter more than having the absolute largest ecosystem of integrations, and it tends to be the go-to recommendation for teams who want an open-source, self-managed option without building on a general-purpose database.

pgvector — when you're already on Postgres

pgvector is a PostgreSQL extension that adds a vector column type and ANN indexing (HNSW or IVFFlat) directly inside Postgres. Its biggest advantage isn't raw vector search performance — dedicated vector databases generally out-perform it at large scale — it's that you can store and query vectors in the same database as your relational data, with full SQL, transactions, and joins against your existing tables.

For teams already running Postgres, this avoids standing up and operating an entirely separate database system just for embeddings, and lets you combine vector similarity search with ordinary relational filters in a single query. It's the recommended default when your vector workload is modest (roughly under a million vectors, though this threshold keeps moving up with pgvector improvements) and operational simplicity matters more than squeezing out maximum search speed.

Pinecone vs. Weaviate vs. Qdrant vs. pgvector

What's next

Vector databases store and retrieve the knowledge an agent reads at inference time. A separate question is how to adapt the model's own weights for a specific task — the next lesson covers LoRA merging and model merging, techniques for combining multiple fine-tuned adapters or models together.