pgvector vs Pinecone: Filtered RAG Latency & Cost Benchmark

An ANN query can look impressively fast and still fail in production.

Imagine a tenant filter that matches just 1% of your corpus. The vector index returns ten globally similar chunks in a few milliseconds, but only one belongs to the requesting customer. The application either returns a weak answer or runs another, slower query. The benchmark looked good; the product experience did not.

That’s the central problem in comparing pgvector, Pinecone, and Qdrant. Raw nearest-neighbor speed matters, but filtered recall, concurrency, consistency, and total operating cost matter more.

This article is a benchmark and architecture guide rather than a claim that one product is universally fastest. The useful question is:

At the required recall and application-level p99 latency, which system handles your filters, writes, concurrency, and budget most effectively?

Why unfiltered vector benchmarks mislead

Many vector comparisons run approximate nearest-neighbor (ANN) queries against an unfiltered dataset. That produces a clean chart, but production RAG requests often include:

• tenant or organization IDs;
• document-level permissions;
• geography, language, or product filters;
• published = true;
• document-version constraints;
• fresh writes and updates;
• keyword retrieval alongside semantic search.

Approximate indexes may explore a limited candidate set before applying metadata filters, depending on the engine and configuration. If only 1% of the corpus is eligible, an index tuned for unfiltered recall may not inspect enough candidates to return ten valid results.

The benchmark must therefore measure application behavior, not just the vector operation:

application p99 =
vector search
+ network transfer
+ metadata retrieval
+ authorization checks
+ reranking

A dedicated vector service may beat PostgreSQL by 10 milliseconds on ANN search and still lose the request-level comparison if the application needs a second round trip to fetch metadata or verify permissions.

The storage problem arrives earlier than expected

Raw vector storage is straightforward:

Raw storage = vector count × dimensions × bytes per component

The first column uses decimal gigabytes, where 1 GB equals 1 billion bytes. These figures exclude row metadata, HNSW or IVF indexes, replicas, WAL, backups, compaction space, and the free capacity needed for maintenance.

HNSW memory also isn’t a fixed percentage of vector storage. It depends on the implementation, graph parameters, dimensions, data type, and number of indexed rows.

For a reproducible pgvector test, pin the extension version. The examples below assume pgvector 0.8.0; record the exact version installed in every benchmark environment because features such as halfvec, iterative scans, and filtered-index behavior are version-sensitive. Check the pgvector release history before comparing results across versions.

The broad index trade-off is familiar:

• HNSW generally offers a strong speed-and-recall trade-off, but uses more memory and takes longer to build.
• IVFFlat usually builds faster and consumes less memory, but often requires more tuning to reach comparable recall.
• Selective filters may require larger candidate pools, iterative scans, partial indexes, or partitioning.

A minimal HNSW test might look like this:

CREATE INDEX documents_embedding_hnsw
ON documents
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 120);

SET hnsw.ef_search = 100;

SELECT id, content, embedding <=> $1 AS distance
FROM documents
WHERE tenant_id = $2
  AND published = true
ORDER BY embedding <=> $1
LIMIT 10;

These settings are starting points, not recommendations. Increasing ef_search can improve recall while increasing latency. Record the index parameters and PostgreSQL configuration with every result.

A benchmark designed for production RAG

Use identical embeddings, query vectors, filters, and quality targets for pgvector, Pinecone, and Qdrant. Keep the corpus and query set fixed, and document the hardware or service tier.

Exact brute-force search should provide the ground truth. Then test ANN search at several filter selectivities:

For each system, report:

1. Recall@10 and Recall@50 against exact search.
2. p50, p95, and p99 application latency.
3. QPS at fixed concurrency.
4. Sustained insert and update rates while reads run.
5. Index build or initial-ingest time.
6. Memory and storage consumption.
7. Recovery behavior after a node or replica failure.
8. Monthly cost at the tested workload.

Test warm-cache and cold-cache behavior separately. Also include burst concurrency. A system that produces a 12 ms median at concurrency four may deliver a 400 ms p99 at concurrency 128.

A compact workload matrix is enough for a first pass:

For pgvector, test both HNSW and IVFFlat. For Pinecone and Qdrant, record the index configuration, shard count, replication, region, and service tier. “Pinecone” or “Qdrant” alone is not a reproducible configuration.

What to compare architecturally

pgvector

pgvector is usually the simplest choice when PostgreSQL already owns the documents, tenants, permissions, and transactions. Filtering happens close to the data, and an application may avoid a second metadata lookup entirely.

That simplicity is valuable for systems with moderate retrieval concurrency, frequent updates, and strong consistency requirements. It also makes authorization easier to reason about: the vector search and relational predicates can run in one transaction.

The trade-off is resource contention. Large indexes, high ef_search values, and bursty retrieval can compete with OLTP queries. Index memory and maintenance costs become material as the corpus grows, especially when replicas and backups are included.

Pinecone

Pinecone is attractive when vector retrieval needs independent scaling, high burst concurrency, or a managed operating model. It can separate search capacity from the transactional database, which is useful when embedding traffic and application transactions have very different growth patterns.

That separation introduces work. The team must keep vectors and metadata synchronized, define freshness guarantees, handle failed writes, and decide where authorization is enforced. If the application stores canonical documents in PostgreSQL, measure the additional network and metadata lookup latency rather than treating vector-query latency as the whole request.

Use the Pinecone pricing page and document the region, index type, replicas, storage, read/write volume, and any minimum capacity assumptions.

Qdrant

Qdrant provides a dedicated vector engine with payload filtering, replication, and deployment options that can suit teams running their own infrastructure or using a managed service. It is worth testing when filtered ANN is central to the product and vector retrieval has outgrown the database’s normal workload.

As with Pinecone, the key question is not whether Qdrant is faster in an isolated query. It is whether the complete architecture improves filtered recall, p99 latency, operational simplicity, or cost. Record collection configuration, payload indexes, quantization, shard count, and replication. Qdrant’s filtering documentation and benchmark material describe the available mechanisms, but vendor benchmarks are context rather than proof for your workload.

Cost: measure completed retrievals

Cloud pricing changes by region, service mode, and commitment. A per-vector comparison hides too much. Use a workload model:

Monthly cost = compute + vector storage + index storage + replicas + requests + ingestion + egress + operations

For pgvector, include database compute, memory, storage, IOPS, WAL, backups, replicas, and the CPU used for joins and filtering.

For Pinecone or Qdrant, include vector storage, query and write charges, minimum capacity, replication, network transfer, ingestion, reindexing, and the database that still stores canonical metadata.

The most useful denominator is:

Cost per successful top-k retrieval at the required recall and p99 target

PostgreSQL may look expensive when treated as a dedicated vector appliance but become cheaper when it replaces a metadata store, synchronization worker, authorization lookup, and separate operational surface. A managed vector service may have attractive query pricing while the surrounding data pipeline becomes the larger bill.

When should you move beyond pgvector?

Don’t migrate because the corpus crossed an arbitrary number of vectors. Move when measured pressure persists:

• filtered Recall@10 misses the product target;
• p99 latency exceeds the application budget at expected concurrency;
• index memory crowds out transactional workloads;
• ingestion interferes with search;
• sharding and replicas would be easier in a dedicated service;
• total cost exceeds the alternative after integration and operations are included.

Stay with pgvector when PostgreSQL is already the system of record, permissions are relational, updates need immediate consistency, and the corpus fits a sensible memory and storage budget.

Choose Pinecone or Qdrant when retrieval is the dominant workload, traffic is bursty, filtered ANN is central to quality, or independent horizontal scaling is worth the synchronization and authorization complexity.

The deciding test is practical: run your real tenant distribution, permission predicates, write rate, and concurrency. If pgvector meets the filtered recall and p99 targets, one durable system is a strong advantage. If it fails despite careful tuning, a dedicated vector database is a measured response—not premature infrastructure.