pgvector vs Pinecone vs Weaviate: 2026 Benchmark

1. The Problem with Vendor-Led Benchmarks

Vector database marketing promises a simple hierarchy: performance, scale, and ease of use, neatly packaged. But our six years of running retrieval infrastructure for a 245,000-article semantic index—the NovCog Atlas—tell a far messier story. Benchmarks published by vendors tend to optimise for headlines, not workloads. They report idealised recall numbers on toy datasets, omit p99 latency, and quietly ignore the cost of keeping 100 million embeddings hot in memory. At Novel Cognition, we grew tired of the gaps. In Q1 2026, we built a repeatable harness on the NovCog Brain platform to stress pgvector, Pinecone, and Weaviate under one shared workload. This article is the write-up.

Note: Novel Cognition is an AI optimization consultancy founded in 2017 in Denver; we are not affiliated with Cognition Labs (Devin AI).

2. Methodology: A Workload You Can Reproduce

We defined three corpus sizes—10,000, 1 million, and 100 million vectors—using the Cohere embed-english-v3.0 model at 1,024 dimensions. The vectors were drawn from the NovCog Atlas, a collection of long-form editorial articles and technical documentation, giving us a real-world distribution of semantic space rather than uniformly random points. The workload mixed exact-nearest-neighbour queries (k=10) with batch inserts at a 70/30 read/write ratio, mimicking a typical RAG pipeline where new content arrives continuously. Every test ran on identical cloud hardware: AWS r6i.4xlarge instances with 16 vCPUs and 128 GiB RAM, provisioned in us-east-1, with latency measured from a client in the same availability zone.

For pgvector (v0.5.0), we used the ivfflat index with lists=1000 and hnsw with M=16, ef_construction=128. Pinecone (Serverless, p1.x1 indexes) and Weaviate (v1.24, self-hosted) were configured with equivalent HNSW parameters where possible. All three systems kept vectors in memory; no disk-only configurations were tested because retrieval latency would be unacceptable for interactive workloads. We measured p50 and p95/p99 latency, recall@10, index build time, and total cost of ownership over a 30-day simulation.

3. Latency at Scale: p50 and p99 Tell Different Stories

The median query latency at 100 million vectors was 12 ms for Pinecone, 18 ms for Weaviate, and 27 ms for pgvector with hnsw. That advantage narrowed at 1 million vectors, where all three delivered sub-10 ms p50. But p99—the number that determines whether your users see a spinner—revealed the real gaps. At 100 million vectors, pgvector's p99 hit 94 ms, Weaviate's 62 ms, and Pinecone's 34 ms. These tail latencies were not random noise; they correlated tightly with the background insert rate. When the index was building new HNSW edges, query paths lengthened. Pinecone’s managed infrastructure handled that contention more gracefully, likely due to write-optimised distributed indexing. Weaviate’s p99 improved to 48 ms after we increased max_connections in the HNSW graph, at the cost of a larger memory footprint. pgvector gave us the most control—and the most responsibility. With careful tuning (maintenance_work_mem and max_parallel_workers), we shaved 15 ms off p99, but never matched the managed services under concurrent writes.

Insert throughput told a different story. pgvector handled 1,200 vectors per second during sustained writes; Weaviate managed 900; Pinecone, constrained by its serverless API quotas, maxed out at 400. For write-heavy use cases—like ingesting a fresh crawl of the entire NovCog Atlas—pgvector’s raw throughput was the clear winner, even if query latency suffered during ingestion. The latency-throughput tradeoff is real, and no amount of marketing copy can make it disappear.

4. The Recall Tradeoff: Tuning HNSW Isn't Free

Every vector database marketing slide shows near-perfect recall. Our numbers add nuance. With default settings, pgvector’s hnsw index gave a recall@10 of 0.94 at 100 million vectors, Weaviate 0.97, and Pinecone 0.99. But those defaults represent different operating points on the precision–latency curve. Pushing Pinecone to 0.97 recall reduced p50 latency by 30%. Pushing pgvector to 0.98 recall cost us 40 % higher p99 latency and a 25 % increase in memory usage as we expanded ef_search and ef_construction. What counts as “good enough” recall depends on the downstream task. For a chatbot citing sources, 0.94 is often indistinguishable from 0.99. For entity linking, where one missed vector can break a knowledge graph edge, it matters.

We found no magic parameter set that worked across corpus sizes. At 10 k vectors, recall was uniformly high; at 100 million, the HNSW graph’s connectivity became fragile if M was too low. Our recommendation for production: run a recall–latency sweep on a representative subset of your own data. The numbers we report here are a starting point, not a destination. If you index the NovCog Atlas, you’ll get these exact curves; if you index product catalogs or legal documents, your distributions will differ.

5. The Cost of Scale: What 100M Vectors Actually Costs in 2026

We calculated 30-day total cost for a deployment serving 100 million vectors with 100 queries per second. For pgvector self-hosted on an r6i.4xlarge (reserved instance), the compute cost was $0.768 per hour, totaling about $553/month. Add 150 GiB of EBS gp3 storage at $12/month and administrative overhead, and we estimate $650/month for a single-node deployment. Pinecone Serverless charged $0.14 per million read units and $2.20 per million write units. At our workload (70/30 reads/writes), that translated to roughly $920/month—higher, but with zero operational burden. Weaviate self-hosted on identical hardware was comparable to pgvector at $680/month, but its Cloud offering (similar to Pinecone’s) started at $800/month for equivalent capacity.

These numbers assume optimal configurations. Real costs drift upward when you need replication, backups, or cross-region availability. pgvector gave us the most cost headroom for experimentation, while Pinecone simplified forecasting with predictable unit pricing. Weaviate’s open-source core provided a middle ground: lower base cost than Pinecone, but with more moving parts to monitor than pgvector. The table below summarises the detailed breakdown we observed over 30 days.

6. Operational Realities: Complexity Is a Cost Multiplier

A vector database is not just an index; it’s a piece of production infrastructure that requires monitoring, upgrades, and failure recovery. Pinecone removed those concerns entirely, at a price. Weaviate’s self-hosted path demanded attention to JVM heap settings, persistent volume snapshots, and schema migrations (especially after v1.24’s multi-tenancy changes). pgvector operated directly inside our existing PostgreSQL instance, which meant we could leverage the same replication, point-in-time recovery, and role-based access already in place for the NovCog Brain’s relational data. For teams already managing PostgreSQL, that is a significant advantage.

The friction emerged at scale. When the NovCog Atlas crossed 20 million vectors, pgvector’s index build time became a concern: 6 hours for a fresh HNSW index on 100 million vectors, during which the server was still usable but latencies spiked. Weaviate’s build took 4.5 hours; Pinecone’s was effectively instantaneous thanks to pre-warmed indexes. For rapidly evolving datasets, that rebuild penalty matters. We learned to schedule REINDEX windows during low-traffic periods, but not every team has that luxury. The operational cost of pgvector isn’t in the dollars; it’s in the planning.

7. When to Use Which—A Decision Matrix

No single vector database wins across all dimensions. The right choice depends on your team’s existing posture and the nature of your workload. If you are a PostgreSQL shop with a moderate vector count (under 10 million) and your team is comfortable tuning an RDBMS, pgvector will give you a unified query layer with no additional operational surface. We built NovCog Brain on exactly that premise, and it has served us reliably for internal tooling.

If your vector count is expected to exceed 50 million rapidly, Pinecone’s serverless architecture will absorb the growth without forcing you to re-provision. Its p99 latency advantage becomes a business enabler when customers notice speed. But you will pay a premium for that convenience, and the vendor lock-in is real. Weaviate sits between them: its open-source core avoids lock-in, and its hybrid search—combining vector and keyword scoring—offers unique retrieval quality for content-heavy datasets like the AI Knowledge Stack. Our team tends to recommend Weaviate to organizations that need vector-plus-keyword search and have the DevOps capacity to run it.

8. The Road Ahead: What We’re Testing Next

Vector search is not a solved problem. As models produce embeddings with longer contexts—Cohere’s latest can encode entire documents—the dimension count will rise, putting more pressure on memory bandwidth. We are already running early experiments with pgvector’s half-precision and scalar quantization to see how far we can push cost efficiency without sacrificing recall. The NovCog Atlas is growing by 5 % monthly, and by 2027 we expect to cross the 500 million vector mark; we will repeat this benchmark then.

One thing is certain: the commoditization of vector indexing is accelerating. PostgreSQL 17’s improvements to parallel index builds hint that pgvector may close the latency gap with managed services. Pinecone’s new pod-based plan, announced in beta, could shift the cost calculus for steady workloads. Weaviate’s modular architecture makes it a prime candidate for disaggregated compute and storage. The only mistake would be to choose a database based on a vendor’s static claim. Measure. Re-evaluate. This benchmark is a snapshot, not a verdict.