Pinecone vs pgvector vs Qdrant: Vector Databases Compared

**

There is no single best vector database, and the choice falls out of two things you already know about your own stack: where your data currently lives, and how much infrastructure you are willing to run yourself.

Those two axes are the durable part. Prices change, versions ship, benchmark tables go stale — the ones in this post did, inside six weeks. What does not move is the shape of the trade. pgvector keeps vectors on the same side of the boundary as your relational rows.

Pinecone puts them on the far side of a network boundary and takes the operations off your plate. Qdrant hands you the index and its knobs, wherever you decide to run it.

What each one actually is

These three are not the same kind of thing, which is the part most comparisons skip. One is a database extension, one is a managed service, one is a search engine you operate.

Table: deployment shapes and current releases.

pgvector

adds vector types and indexes to Postgres. Your embeddings live in ordinary columns in the same tables as everything else, so a similarity search is just a SELECT with an ORDER BY on distance — no second system to deploy, secure, or keep in sync.

It supports vector, halfvec (2-byte half-precision, indexable up to 4,000 dimensions), sparsevec, and bit types, with HNSW indexes for all four and IVFFlat for everything except sparsevec. The half-precision, sparse, binary, and binary_quantize features landed in 0.7.0.

Pinecone

is the opposite philosophy: you never touch infrastructure. There is no version to install and nothing to provision. You write vectors and query them through an API, and Pinecone handles storage, indexing, and scaling behind a serverless billing meter. The older pod-based indexes still exist as a legacy option, but serverless is the default path now.

Qdrant

is a purpose-built vector engine written in Rust. You can run the binary or a container yourself, or let Qdrant Cloud host it. It is built around high-throughput search with strong metadata filtering, and it exposes the index parameters, the quantization strategy, and the hybrid fusion to you rather than choosing them on your behalf.

Setup and developer experience

With pgvector, setup is one line — CREATE EXTENSION vector; — assuming your Postgres has it, and it is available on the major managed Postgres services (Aurora, RDS, Cloud SQL, Neon, Supabase). The payoff is that you join vectors against your real data in plain SQL:

CREATE EXTENSION vector;

SELECT id, body
FROM documents
WHERE tenant_id = $1 AND status = 'active'
ORDER BY embedding <=> $2
LIMIT 10;

Filtering by tenant_id, ordering by a timestamp, paginating — all the things you already do, no new query language. The cost is that you are now responsible for index tuning, and for the fact that a large HNSW index wants to live in RAM alongside the rest of your working set.

One operational note, since it is the kind of thing that bites quietly. The 0.8.3 changelog entry reads "Fixed possible index corruption with HNSW vacuuming", and 0.8.4's reads "Fixed hnsw graph not repaired error with HNSW vacuuming". If you're running pgvector HNSW in production, be on 0.8.4 or later.

Pinecone is fastest to a working prototype. Create an index, get an endpoint, start upserting. No schema, no capacity planning, no servers. The flip side is that your vectors live outside your primary database, so anything that combines them with relational data happens in your application code.

Qdrant sits in between. It runs as a binary or a container, the REST and gRPC APIs are straightforward, and the official clients are well maintained. You define collections with payload (metadata) schemas, and payload indexes are what make its filtering fast. The operational weight is real if you self-host at scale, but Qdrant Cloud removes most of it.

Search: index control, filtering, and hybrid

pgvector and Qdrant both build on HNSW; Pinecone does not. Pinecone runs its own algorithms — Ananas for small slabs, PQFS for medium, and IVF with PQFS for large — selected automatically per slab, so you never tune an index there. That difference matters less for raw recall than for control: with pgvector and Qdrant you own the index parameters, with Pinecone you don't.

This is worth stating plainly because the opposite claim circulates widely. Pinecone's own indexing documentation puts it in four words: "Pinecone has never used HNSW." It describes the actual arrangement as "Ananas for small slabs (up to ~10k vectors), PQFS for medium (10k to 100k), and IVF with PQFS for large (over ~100k)."

Filtered search — find similar vectors where tenant = X and status = active — is deceptively hard, because aggressive filters can starve a naive HNSW traversal. Qdrant attacks it with payload indexes and ACORN-1 second-hop traversal.

Recent releases have pushed hard on this: 1.16 added tiered multitenancy (user-defined sharding with tenant promotion) and inline storage that keeps quantized vectors inside HNSW nodes for faster reads, and 1.18 added TurboQuant quantization plus per-component memory monitoring. 1.19 pushed TurboQuant further still, adding a datatype that stores only the 4-bit quantized vectors so a collection no longer has to keep the originals on disk.

pgvector handles filtering through ordinary SQL WHERE clauses, and iterative index scans (added in 0.8.0) improved the case where a filter removes most candidates. It works, and for moderate selectivity it is fine — just do not expect it to match a purpose-built engine on adversarial filters over huge collections.

Hybrid search is where the received wisdom is most wrong. Qdrant ships hybrid (dense + sparse) search natively. So does Pinecone, in a single index — the real difference is that Qdrant lets you tune the fusion and the sparse side yourself, while Pinecone hands you a managed path.

Pinecone's hybrid search guide describes "a single index that stores both a dense vector and a sparse vector per record, queried together in one request", and its serverless document-schema indexes go further, combining dense vectors, sparse vectors, and BM25 full-text search in one index.

With pgvector you compose hybrid search yourself, typically by blending vector distance with Postgres full-text search and reconciling the two rankings in your own query.

Quantization splits the same way. Qdrant's documentation lists four methods and puts TurboQuant first, noting that it "supports up to 32x compression, with strong recall across most embedding models" (shipped in 1.18). pgvector gives you binary_quantize and half-precision halfvec. Pinecone quantizes internally as part of its index selection, and does not expose the choice.

Table: search capabilities.

Scaling and performance

Be skeptical of any single latency number, including the ones below. These are third-party benchmarks, not measurements I ran, and reading the two of them side by side turns out to be more instructive than either one alone.

Vecstore (2026-04-06) tests 1M vectors at 1536 dimensions and reports p50/p95 query latency of roughly 5ms/12ms for pgvector HNSW, 3ms/8ms for Qdrant, 4ms/11ms for Milvus, and 8ms/22ms for Weaviate.

The same table puts Pinecone Serverless at ~12ms p50 / ~48ms p95, the slowest of the five. That's the cost of an architecture that reads slabs from object storage rather than holding a graph in local RAM — and it's the trade Pinecone makes deliberately, in exchange for scaling without you provisioning anything.

Tensoria (2026-05-15) reports pgvector at 8–15ms p50 under the same stated conditions, specifying the hardware only as "on a modern Postgres instance". Its Qdrant figure of 4ms p50 is not comparable to that at all: it comes from 5M+ vectors at 768 dimensions on a 4 vCPU / 16 GB instance, a different workload on every axis.

The two sources don't agree. At the same stated conditions — 1M vectors, 1536 dimensions — Vecstore puts pgvector HNSW at ~5ms p50 while Tensoria puts it at 8–15ms. A 1.6–3x spread at identical stated conditions is itself the finding: neither number is wrong so much as neither is reproducible.

Neither source publishes hardware specs — Vecstore says only "comparable compute resources," and Tensoria describes itself as an engineering comparison "based on production deployments, not vendor benchmarks." Read these as field reports, not benchmarks.

Where pgvector stops being comfortable is genuinely contested: Tensoria draws the line under 5M vectors, while Vecstore argues "pgvector matches or beats dedicated vector databases at 1M scale" and frames the Postgres-is-slow story as an IVFFlat-era leftover. Nobody has published a clean measurement of the breakdown point. Plan for somewhere in the 5–10M range and benchmark your own workload before you commit.

The honest framing is about where each breaks down, not who wins a benchmark. pgvector scales with your Postgres instance, so it eventually competes with your relational workload for memory and CPU. Pinecone's serverless model absorbs scale without you thinking about it, trading that convenience for cost, for tail latency, and for living outside your database.

Qdrant is built to scale horizontally with sharding and replication, and you size the cluster yourself.

Pricing

This is where the architectural differences turn into real money, and the billing models don't line up cleanly. Pinecone bills by usage (storage + read units + write units). Qdrant Cloud bills by provisioned resources (vCPU, RAM, disk, billed hourly). pgvector is free — you pay only for the Postgres under it.

Table: published plans and SLAs.

That last row matters more than its size suggests. The usual shorthand is that wanting to keep data in your own account pushes you toward the self-hostable engine, but Pinecone's BYOC plan breaks that: Pinecone runs in your cloud account with zero-access operations. The axis is not open-source versus managed — it is how much of the index you want to control.

Two caveats on the numbers. Pinecone's per-million read and write rates vary by cloud and region, so the ranges above are real ranges, not rounding.

And Qdrant's official pricing page doesn't publish a flat $/GB-hour figure — community estimates float around $0.078/GB-hour for standard clusters, but that is a third-party estimate, not first-party, so confirm against an actual cluster before you build a budget on it.

Because Qdrant charges for allocated resources rather than query volume, it tends to favor high-throughput workloads, while Pinecone's usage model favors spiky or low-volume ones.

For pgvector, price means whatever your Postgres costs. If you already run one, adding vectors is effectively free until the index forces you to size up.

Choose X if…

Table: decision framework.

Notice what dropped out of that table. Hybrid search is not a tiebreaker, because two of the three do it natively. Raw ANN latency is not a tiebreaker either, because the two published sources disagree with each other by 1.6–3x under conditions they both describe the same way.

What survives is the structural question: do you want the index handed to you, or handed over to you, and which side of the network boundary do your vectors need to sit on?

Start from your stack. If Postgres is already your source of truth, reach for pgvector and move only when you hit its ceiling — then measure where that ceiling actually is for your workload, because nobody else has. If you want to ship without operating anything, Pinecone, and check BYOC before you assume managed means off-premises. If you want the knobs, Qdrant.

References

• Pinecone indexing algorithms and hybrid search guide
• Pinecone pricing and cost docs
• Qdrant pricing and Qdrant Cloud
• Qdrant 1.16 release blog and GitHub releases
• pgvector repo, CHANGELOG, and 0.7.0 release notes
• Third-party benchmarks: Vecstore, Tensoria