Pinecone vs pgvector

Datasets: mnist, nq-768-tasb, yfcc (10M), and cohere (10M). The cost model assumes a full upsert, an average of 10 queries per minute, and 10 percent of the dataset modified each month. The pgvector side is priced as the EC2 instance needed to answer 95 percent of queries in under 100ms (p95 latency), plus EBS storage. These runs date from April 2024 and predate pgvector 0.8.0, which added iterative index scans and better cost estimates for filtered queries. The filtering section below covers what changed. We last checked the claims on this page against pgvector 0.8.6, the current release at the time of review.

Source: Pinecone vs. Postgres pgvector: For vector search, easy isn't so easy (April 2024). Results depend on the dataset, query pattern, and configuration. Test your own workload before deciding on these numbers.

Index memory is hard to predict

pgvector builds its HNSW graph in memory. To keep builds and queries fast, that graph needs to fit in the memory you have provisioned. How much it needs depends on the data itself as well as its size on disk.

In Pinecone's benchmark, index memory ranged from about 1.2x the raw dataset size on one dataset to more than 5x on others. No simple formula tells you where your data falls before you load it. If you guess low, the index spills to disk. In the benchmark, build throughput then fell by more than 10x.

The trouble shows up after launch. An application ships with acceptable latency, data accumulates, the index outgrows the memory it was given, and query latency degrades sharply. The fix at that point is a larger instance or sharding the database.

pgvector's own scaling guidance names two ways to shrink the index. The halfvec type stores each dimension in two bytes instead of four. An expression index over binary_quantize() shrinks it further. You then rerank the results against the original vectors to win back the recall that quantization loses. Try both before you conclude the index will not fit. The benchmark numbers above were measured on the full-precision vector type, without either technique.

Both techniques leave the work with you. You choose the representation, tune how deep the reranking goes, and re-check recall as the data changes. Pinecone chooses and adjusts quantization itself while it re-optimizes the index in the background.

Filtering after the search can cut results short

Most retrieval applications filter, by tenant, document set, date range, or language.

pgvector's HNSW index does not apply those filters while it searches the graph. Postgres searches the vector index first, then applies the WHERE clause to what comes back. When the filter is selective, Postgres throws away most of the candidates and the query returns fewer results than you asked for. One query in Pinecone's 2024 test set returned nothing at all. Raising the candidate count to its maximum brought back a single result out of ten.

A GIN index lets Postgres filter first and then rank, which works when the planner chooses it. In the same test set, the planner sometimes used the vector index instead and returned partial results. In another case it skipped both indexes and ran a sequential scan that took several seconds. Queries that looked alike took different paths.

pgvector has since added a mitigation. Version 0.8.0, released in October 2024 after the benchmark above, introduced iterative index scans. When a filtered query comes up short, pgvector can keep scanning the index until it has enough matches. It is off until you enable it per session with the hnsw.iterative_scan setting. Because it stops at a configurable cap on how many index entries it visits, it cannot guarantee a full result set. Its relaxed-ordering mode gives up exact distance ordering to get better recall. The same release also improved the planner's cost estimates for choosing an index when a query filters.

If you are staying on pgvector, iterative scans narrow the gap. The underlying difference remains. Postgres still filters outside the index search. Complete results depend on a setting you have to know about and tune. Even then, the scan stops at a cap on how many index entries it visits. Pinecone applies filters during the search itself. A filtered query returns the full number of results you asked for, as long as enough records match the filter. There is nothing to configure.

Pinecone has caveats of its own here. The claim above describes how the search works. We have published one measurement behind it. In our benchmark against OpenSearch on 10 million vectors, Pinecone's filtered queries found an average of 98.9% of the true 10 nearest matches, against 99.8% for OpenSearch. We have not published recall at each level of filter selectivity, the view that would show where filtering starts to cost accuracy. Pinecone filters also have limits: at most 10,000 values in an $in or $nin list and at most 40 KB of metadata per record. Run your real filters against both systems before you decide.

IVFFlat saves memory but loses recall as data changes

pgvector's other index type, IVFFlat, needs far less memory than HNSW. It clusters vectors into partitions when the index is built.

Those partitions reflect the data that existed at build time. Vectors added later go into partitions that were drawn without them. In Pinecone's tests, recall dropped on every dataset once the data had changed since the initial build. Getting it back means rebuilding the index.

That rules IVFFlat out for most production retrieval, where documents are added and updated all the time.

Most vector benchmarks do not look like production

Published vector benchmarks tend to query a frozen corpus one client at a time. HNSW earns its good results on that test. Most applications serve concurrent traffic against a corpus that is still being written to.

Under that load, two things change. Adding a vector to an HNSW graph means running a series of approximate searches through the graph's layers. Writes therefore compete with queries for the same memory and CPU. On a single Postgres instance, queries, ingest, index rebuilds, and autovacuum all contend for that one machine. Read replicas can take some read traffic off the primary, but you then have replicas to run and replication lag to deal with.

The slowdown hits the slowest requests while the median still looks fine. A healthy p50 (median latency) can sit alongside a p99 (the slowest 1 percent of requests) that has climbed into seconds. Users feel those slow requests. Pinecone separates storage from compute and gives reads their own capacity. Ingest does not compete with queries.

What the operational difference costs

Keeping vectors in Postgres saves you a second system, but running pgvector at scale still takes work. You predict index memory, watch for the point where it stops fitting, choose between two index types that fail in different ways, add GIN indexes to make filters behave, and check query plans when results look wrong.

Pinecone's benchmark also modeled direct cost across the four datasets. On ongoing monthly cost, Pinecone Serverless came out between 1.5x and 2.9x cheaper. Including the one-off cost of the initial upsert, it came out between 1.1x and 2.2x cheaper. Those figures exclude the cost of operating Postgres itself.

You also pay for idle capacity. A Postgres instance sized for peak index memory is paid for around the clock, whether or not anyone is querying it. By default, Pinecone charges for what you query. Where traffic is sustained enough to justify provisioned capacity, Dedicated Read Nodes trade per-query cost for fixed read capacity. Pinecone has published three production workloads that moved to Dedicated Read Nodes: 77 percent lower cost on a billion-vector index at low query volume, 83 percent on a latency-sensitive workload, and 97 percent on one with sustained high QPS (queries per second).