The pgvector-vs-Pinecone fight is really a fight over whose benchmark you trust

“Do you actually need Pinecone, or is Postgres with pgvector good enough?” is one of the longest-running arguments in the RAG-infrastructure world, and it’s still being fought with dueling benchmarks rather than settled. The clearest example: Timescale (now Tigerdata) and Pinecone have each published a head-to-head on the same kind of workload, and they don’t agree.

Timescale’s benchmark, run against 50 million 768-dimension Cohere embeddings, reports that pgvector plus its pgvectorscale extension beats Pinecone’s storage-optimized index by 28x lower p95 latency and 16x higher throughput at 99% recall, and edges out Pinecone’s performance-optimized index too. On cost, Timescale puts self-hosted Postgres at roughly $835/month against $3,241–$3,889/month for the equivalent Pinecone indexes — a 75-79% saving. That post (127 points on Hacker News) is the one most often cited in “you don’t need Pinecone” threads, including the discussion here, where developer cl42 wrote: “After trying a number of different options (Pinecone, ChromaDB, FAISS + memory stores), I felt like pgvector offered the best value” — while also flagging that a lot of the performance discourse “might be FUD rather than real benchmarks.” Timescale’s own akulkarni chimed in on that thread that “pgvectorscale only makes pgvector better,” with “no cost (technical or financial)” to adding it.

Pinecone’s response, in its own comparison post, doesn’t dispute pgvector can be fast — it argues the operational reality is worse than the benchmark suggests. Pinecone’s engineers report that pgvector’s HNSW index needs RAM “proportional to the dataset size, specifically 1.2x of the entire dataset,” and that once an index exceeds available RAM, “build throughput drops precipitously — over 10x slower.” They also point out pgvector’s HNSW implementation lacks native metadata filtering, and that IVF-Flat indexes degrade as data changes: “Unless you have the exact data you want to upload, and you never update that data, IVF-Flat indexes will not be able to support your application.” On cost specifically, Pinecone’s own tested datasets found Pinecone Serverless cheaper, by a factor of 1.1x-2.2x — the opposite conclusion from Timescale’s numbers, on ostensibly similar workloads.

That gap is the real story: both benchmarks are internally consistent and both are self-serving, which is exactly why “Pinecone is too expensive” remains a live complaint rather than a settled one. On Hacker News, commenter redskyluan put the underlying frustration plainly: “Pinecone is notoriously expensive compared to other vector database services,” pointing to the removal of Pinecone’s public pricing calculator as making the comparison harder, not easier, to do yourself.

What this means for buyers

There isn’t a universal answer here, and anyone telling you there is one is selling something — often literally, given who publishes these benchmarks. What you can control is testing on your own data and query patterns rather than trusting either vendor’s dataset choice, and pricing out the operational cost of self-hosting (backups, upgrades, on-call) against a managed vector database’s premium. Crail’s Vector Databases category tracks pricing and agent-readiness across Pinecone, Weaviate, Qdrant, Chroma, Zilliz Cloud, and MongoDB Atlas Vector Search — and our MongoDB Atlas Vector Search vs Qdrant comparison is a good starting point if you’re weighing a managed option against a more infrastructure-flexible one.