Member-only story
I did not expect a 40-year-old relational database to win this.
On 50 million 1536-dimensional embeddings, at a 99% recall target, on the same AWS hardware, Postgres with the pgvectorscale extension served 471 queries per second. Qdrant — a purpose-built, Rust-native vector engine designed for exactly this job — served 41. That is an 11.5x gap in favor of the database everybody already had running before “vector database” was a category.
I spent a week re-running the public benchmarks, rebuilding the indexes myself, and pricing out all three on a real RAG workload, because that number felt wrong. It mostly held up. It also came with an asterisk big enough to change your architecture decision, so let me show you the whole picture instead of the headline.
Here is the short version: for most teams shipping retrieval in 2026, the purpose-built vector database you are paying for is slower, more expensive, and more operationally complex than the Postgres box sitting next to your app. But there is a hard scale line where that flips, and Qdrant wins a category that the QPS number completely hides.
Why this fight suddenly matters #
Two years ago the advice was reflexive: doing RAG? Stand up a dedicated vector store. Pinecone, Weaviate, Qdrant, Milvus — pick one, wire it in, move on. The dedicated engines were genuinely faster…