Pinecone vs Weaviate vs Qdrant vs pgvector: Which Vector Database Actually Fits Your RAG Stack

If your RAG pipeline is slow, or your retrieval quality is bad, or your AWS bill has a line item you can't explain, there's a good chance the actual cause is a vector database decision you made in week one without thinking about it. "Just use Pinecone" and "just add a vector column to Postgres" are both defensible answers, and they lead to completely different operational realities six months later. Here's how vector search actually works under the hood, what pgvector, Qdrant, Weaviate, and Pinecone each do differently, and how to pick without guessing.

How vector search actually works under the hood

An embedding model turns a chunk of text into a list of numbers, typically 384 to 3072 of them, positioned in space so that semantically similar text ends up geometrically close together. "Retrieval" then means: take the user's query, embed it the same way, and find the stored vectors nearest to it, usually by cosine similarity or dot product.

The naive way to do that is brute force: compare the query vector against every stored vector and sort. That's fine at 10,000 rows. At 10 million it's a full table scan on every single query, and latency scales linearly with your data size, which is exactly backwards from what you want as a product grows.

This is why every production vector store implements an Approximate Nearest Neighbor (ANN) index instead of exact search. The dominant algorithm right now is HNSW (Hierarchical Navigable Small World): it builds a multi-layer graph where each vector is connected to its nearest neighbors, with sparser layers on top for long jumps and denser layers below for fine-grained search. A query starts at the top layer, greedily walks toward the closest node, drops down a layer, and repeats — landing on a very good (not guaranteed-exact) match in a handful of hops instead of a full scan. You trade a small amount of recall for a massive amount of speed, and that trade is what makes retrieval at scale possible at all. This is the same underlying mechanism our RAG vs fine-tuning breakdown assumes when it talks about "retrieval" as a black box — this is what's actually inside the box.

pgvector: the database you already run

pgvector is an open-source Postgres extension that adds a vector column type plus exact and approximate (HNSW, IVFFlat) search directly inside Postgres. Version 0.8.0, the latest major release, improved iterative index scans so filtered vector queries (WHERE clauses combined with similarity search) stop degrading as badly under selective filters — historically one of pgvector's weaker spots against dedicated engines.

The real argument for pgvector isn't raw speed, it's transactional consistency: you insert a document row and its embedding in the same transaction, in the same database you're already backing up, replicating, and paying for. There's no second system to keep in sync, no "the embedding write succeeded but the document write failed" class of bug. Crunchy Data's technical writeup on HNSW indexing in Postgres is a good primary read on the actual index build and query mechanics if you're evaluating this seriously. The honest limit: once you're past roughly 10 million vectors, or vector search is your product's primary workload rather than a feature bolted onto one, the index build times and memory footprint start working against you compared to something built for this from the ground up.

Qdrant: purpose-built and open source

Qdrant is a vector search engine written in Rust, open source, and self-hostable, with a managed cloud option if you'd rather not run it yourself. It was built as a vector index first, not a general database with vector search added on, which shows up in its filtering performance (combining metadata filters with ANN search without the filter tanking recall) and in native support for sparse vectors (SPLADE-style keyword-aware embeddings) alongside dense ones. Qdrant publishes its benchmark methodology and results openly, including the benchmarking framework itself on GitHub, so you can rerun the comparisons on your own hardware and data shape instead of trusting a vendor's slide — worth doing, because ANN benchmark rankings shift meaningfully with vector count, dimensionality, and filter selectivity.

Weaviate: hybrid search as a first-class feature

Weaviate is also open source and self-hostable, and its defining feature is hybrid search built into the core query path rather than bolted on: it runs a BM25 keyword search and a dense vector search in parallel, then merges the two ranked lists with Reciprocal Rank Fusion, an algorithm that rewards documents ranking well in either list without letting one method dominate. You control the blend with an `alpha` parameter — `alpha=1` is pure vector search, `alpha=0` is pure keyword. This matters in practice because pure semantic search genuinely fails on exact-match queries: part numbers, product SKUs, error codes, or a name spelled an unusual way, where the literal token match matters more than the semantic neighborhood. See Weaviate's own writeup for the query syntax and fusion algorithm details.

Pinecone: paying to make the ops problem disappear

Pinecone is the one product here that isn't open source. It's fully managed serverless, priced on read units, write units, storage, and egress rather than a fixed instance size, with a free Starter tier and no infrastructure for you to run, patch, or scale. That's the entire pitch: you're paying to remove index tuning, sharding, and capacity planning from your team's job list. It's the right call when your team's time is worth more than the markup, or when you need to be in production this week rather than after an infra evaluation. It's the wrong call if a self-hosted open-source option already fits your scale and your team already owns database operations — you'd be paying recurring usage fees for a problem you don't have.

A decision framework that isn't "it depends"

In order: does vector search need to live inside a transaction with your primary data — if yes, pgvector, full stop, unless you're already past ~10M vectors. Do you need hybrid keyword+vector search as a core capability, not an add-on — Weaviate's fusion model is purpose-built for that. Is raw ANN throughput and filtered-query performance at large scale your actual bottleneck, and are you fine self-hosting — Qdrant, and rerun their open benchmarks on your own data before committing. Do you have no interest in owning vector infrastructure at all and the usage-based pricing pencils out — Pinecone. Three of these four options cost nothing to run beyond your own compute; the AIBOOTSTRAPPER AI Product Development Bootcamp walks through wiring any of them into a real retrieval pipeline, including the embedding and chunking decisions that matter more than the database choice ever will.

Where this fits into a real RAG stack

The vector database is one component in a pipeline, not the whole system: chunking strategy, embedding model choice, and reranking typically move retrieval quality more than switching index engines does. But the database decision is the one that's expensive to reverse once you've got production data and traffic sitting on it, which is exactly why it's worth thirty minutes of real evaluation instead of copying whatever the last tutorial you read happened to use.