Postgres Won: The Complete 2026 Guide to Picking a Vector Database
The vector database rankings flipped in 2026. Based on verified benchmarks, real pricing math, and production failure patterns — here's how to choose between Pinecone, Qdrant, Weaviate, Milvus, and pgvector without getting misled.
One Benchmark Changed Everything
In April 2026, a single published result reshuffled nearly every vector database recommendation written in the previous three years. Running on identical hardware, Postgres with the pgvectorscale extension processed 471 queries per second at 99% recall across 50 million 1536-dimensional vectors. Qdrant, on the same machine, reached 41.47 QPS. The same pgvectorscale setup showed 28× lower p95 latency and 16× higher throughput than Pinecone's storage-optimized index at the same recall target. The throughput gap compounds with scale: roughly 6.7× at 10M vectors, 11.4× at 50M, and 14× at 100M.
The dedicated vector database category was built on a single assumption: purpose-built systems beat general-purpose ones at vector search. That assumption no longer holds, at least not as a default. The downstream effects are still propagating through the market. VentureBeat's 2026 data predictions describe vectors as having "moved from being a database category to a data type." Databricks spent $1B acquiring Neon in May 2025. Snowflake spent roughly $250M acquiring Crunchy Data in June 2025. Both are Postgres-first companies that ship pgvector out of the box.
This article is the one worth reading before making that decision. Vendor pages are indistinguishable from each other. Comparison blogs recommend whatever they're compensated to recommend. Most benchmarks use workloads that flatter whoever commissioned them. What follows is the version that pairs verifiable public numbers with real pricing math, failure modes from actual production incidents, and a decision framework honest enough to say "Postgres is now the right answer more often than you'd expect" without pretending it's always right.
The Five Systems Worth Comparing
Dozens of databases added vector support in the past two years. For production decisions in 2026, only five are genuinely worth evaluating: Pinecone, Qdrant, Weaviate, Milvus (and its managed form, Zilliz Cloud), and Postgres with pgvector — often combined with pgvectorscale.
Pinecone launched in 2019 and created the managed-vector-database-as-a-service category. Its serverless architecture, released in 2024, decoupled storage from compute and introduced usage-based pricing that every competitor has since imitated. The core strength is zero operational overhead. The core weakness is a cost curve that steepens sharply above 10M vectors.
Qdrant was written in Rust from scratch in 2021. That implementation produces consistently lower latencies than Go- or Python-based alternatives, and its payload index — enabling fast metadata filtering combined with vector search — is genuinely best-in-class. At 10M vectors, p99 latency sits around 12ms versus Weaviate's 16ms and Milvus's 18ms. The tradeoff is that large-scale QPS now trails pgvector, which makes the Rust latency advantage less decisive than it used to be.
Weaviate started as an open-source project in 2019 and grew into a managed offering with strong hybrid search — combining vector similarity with BM25 keyword scoring in the same query. For teams that need both, Weaviate does it as a first-class feature rather than a custom workaround. Pricing is reasonable at small scale and climbs quickly with vector dimensions.
Milvus / Zilliz Cloud is the open-source workhorse for the 100M+ vector range, where the cost savings of running a distributed cluster justify the operational complexity. Below that scale, Milvus is overkill in the same way Cassandra is overkill for an app with a thousand users. Zilliz Cloud is the managed wrapper that offloads that complexity.
Postgres with pgvector and pgvectorscale is the rising default. The pgvector extension, first released in 2021 by Andrew Kane, added vector storage and similarity search to standard Postgres. The 2024 introduction of HNSW indexes brought query latency into range with dedicated vector databases at small-to-medium scale. The 2026 release of pgvectorscale by Timescale — implementing DiskANN-based indexing — moved Postgres into the leading position at 50M+ vectors. The combined stack now handles a meaningful share of all production RAG workloads.
What Published Benchmarks Actually Measure
Most vector database benchmarks you find online have been useless for years. They test a single dataset — usually SIFT, GIST, or ada-002 embeddings — at a single scale, with default parameters no one uses in production. The numbers are technically accurate. Their relevance to your specific workload is approximately zero.
Benchmarks worth taking seriously in 2026 do three things right. They run at multiple scales (1M, 10M, 50M, 100M) because system rankings flip across those thresholds. They publish the recall target, since QPS at 99% recall looks nothing like QPS at 90%. And they report p50, p95, and p99 latency separately, because tail latency is what ruins production user experiences. The pgvectorscale benchmark clears all three bars. Most blog-post benchmarks clear none.
One result that stands out for production planning: rankings between vector databases depend heavily on scale and filter complexity. At 1M vectors with no metadata filters, almost every system delivers sub-10ms p99 latency at 99% recall. Differences are real but small. At 10M vectors with metadata filters, Qdrant's payload index advantage becomes visible. At 50M and beyond, pgvectorscale's DiskANN approach pulls ahead on throughput while keeping latency competitive, because DiskANN's disk-resident graph avoids the memory pressure that HNSW hits at scale.
A non-obvious insight from running these comparisons on the same dataset: filter selectivity matters more than vector database choice. A vector query that hits 100 candidate vectors after filtering is fast on every system. A query that has to score 100,000 candidates is slow on every system. The path to fast production vector search runs through schema design and metadata column indexing — not through picking the right database vendor.