Every team that builds retrieval into an application eventually faces the same fork in the road: where do the embeddings live, and what searches them. Three names dominate that decision in 2026, and this vector database comparison puts them side by side. pgvector turns an existing Postgres database into a vector store. Pinecone sells a fully managed service built only for vectors. Qdrant offers an open-source engine written in Rust that you can self-host or buy as a managed cloud. They solve the same problem in very different ways, and the right pick depends on your scale, your budget, and how much infrastructure you want to run.
- pgvector is the cheapest and simplest option when your data already lives in Postgres and you stay under a few million vectors.
- Qdrant delivers the fastest filtered search by running filters inside the graph traversal, and self-hosting keeps the bill low.
- Pinecone removes all tuning work and holds latency steady past 5 million vectors, at a price several times higher than the alternatives.
- Independent 2026 benchmarks put Qdrant near 8ms p95 at 1M vectors, pgvector around 48ms, and Pinecone under 30ms at much larger scale.
The three contenders at a glance
The split between these tools is philosophical before it is technical. pgvector, an extension for PostgreSQL, treats vectors as just another column type. You add it to a database you already run, store embeddings next to your relational rows, and query both in a single SQL statement. The project lives on GitHub and has become the default for anyone who would rather not run a second database.
Pinecone takes the opposite stance. It is a closed, fully managed cloud service that does one job, vector search, and hides every operational detail. You never see an index build, a replica, or a memory setting. You send vectors, you query them, and the bill arrives monthly. That simplicity is the product.
Qdrant sits between the two. It is an open-source engine you can run in a Docker container on your own hardware, or pay for as a managed cloud, with the same software underneath either way. Written in Rust and focused on speed and filtered search, it appeals to teams that want strong performance without handing the whole operation to a vendor. Knowing which philosophy fits your team narrows the choice before a single benchmark enters the picture.
How vector search actually works: HNSW and IVF
To read the benchmarks honestly you need a feel for the index underneath. Searching millions of high-dimensional vectors for the nearest neighbors of a query is expensive if done exactly, so all three tools use approximate nearest neighbor search, which trades a small amount of recall for a large gain in speed. The dominant algorithm is HNSW, short for Hierarchical Navigable Small World, which builds a layered graph of vectors and walks it from coarse to fine to find close matches quickly.
HNSW has two knobs that matter. The construction parameters, often called M and ef_construction, control how densely the graph is connected and therefore the balance between build time, memory use, and final accuracy. A query-time parameter controls how hard the search works before returning. Tuning these is the difference between a fast index that misses results and a slower one that finds them. pgvector exposes both m and ef_construction per index. Qdrant goes further, giving full control over the M and ef_construct settings plus a full_scan_threshold that decides when to skip the graph entirely. Pinecone, by design, exposes none of these and tunes the index for you, which is convenient until you need behavior it does not offer.
The older alternative, IVF, partitions vectors into clusters and searches only the nearest few. pgvector supports an IVFFlat index as a lighter, more memory-friendly option than HNSW, useful when memory is tight and you can accept lower throughput. For most workloads in 2026, HNSW is the default because it holds higher recall at low latency, and the cost is slower, more memory-hungry index builds.
Latency and throughput: the benchmark picture
Numbers vary with hardware, dimensions, and recall target, so treat any single figure as a data point rather than a verdict. With that caveat, independent testing through 2026 paints a consistent shape. An independent production comparison reported pgvector handling about 220 queries per second at roughly 48ms p95 latency on one million 1536-dimensional vectors with standard settings, rising to about 360 queries per second with four parallel workers. The same report measured Pinecone at around 340 queries per second and 28ms p95 on a similar half-million to one-million vector set.
Qdrant's published benchmarks, which the project maintains on its own benchmark page, show it pulling ahead on raw query speed, with figures near 850 queries per second and 8ms p95 latency on one million 768-dimensional vectors. Lower dimensionality helps those numbers, so the comparison is not perfectly apples to apples, but the gap is wide enough to signal a real advantage on throughput. Other testing through 2026 has put pgvector's HNSW responses in the 5 to 8ms range on smaller sets and Qdrant's p50 latency under 5ms at high recall.
The practical reading is that all three are fast enough for interactive applications at modest scale, and the differences only become decisive when query volume is high or the dataset is large. If you are serving a few queries per second over a hundred thousand vectors, any of them will feel instant, and the choice should rest on cost and operations rather than milliseconds.
Scaling: where each one hits a wall
Scale is where the three diverge most sharply, and where many projects discover they chose wrong. pgvector is excellent until it is not. The same production comparison found that standard pgvector HNSW starts to slow noticeably above five to ten million vectors, that a single instance struggles past two million, and that index builds can exceed twenty minutes at that size. Beyond a few million vectors you are into read replicas or partitioning, which is real engineering work rather than a configuration flag.
Pinecone was built for the high end and shows it. The reporting indicates it holds sub-20ms p95 latency at five million vectors and beyond with no configuration tuning, staying under 30ms on its pod-based deployments at that scale. For a team whose dataset is already in the tens of millions and growing, that consistency without operational effort is the central reason to pay the premium.
Qdrant scales well in both modes. Self-hosted instances handle millions of vectors on a single capable machine, and the managed cloud scales with the resources you provision. Because you control the hardware, you can throw more memory and cores at the problem directly, which suits teams comfortable running their own infrastructure. The trade is that the scaling work is yours to plan rather than a vendor's to absorb.
Pricing: the cost curve that decides most projects
For many teams the bill, not the benchmark, settles the question, and the gap here is large. The production comparison put pgvector on Supabase at roughly $25 per month for one million vectors and $60 to $100 per month at five million, against Pinecone at $50 to $80 per month for one million and $250 to $400 per month at five million. At the larger end pgvector lands three to eight times cheaper, and the gap widens as the data grows.
The gap looks even starker in heavier deployments. A separate analysis cited self-hosted Postgres running pgvector at about $835 per month on EC2 against Pinecone tiers of $3,241 and $3,889 per month for comparable capacity, roughly a 75 percent saving. Qdrant occupies the low end when self-hosted, with a small VPS running $30 to $50 per month and the managed cloud landing between $100 and $300 depending on configuration. Qdrant Cloud's entry tier starts near $9 per month for a fraction of a vCPU, with about $36 per month covering one million vectors on 4 GB of memory.
Self-hosted prices hide a real cost: the time your team spends running the database. A $30 VPS is only cheap if nobody is paged at 3 a.m. to restart it. Factor in the engineering hours, not just the cloud invoice, when you compare a managed service against a self-hosted one.
Filtering and metadata: the underrated dimension
Pure vector search rarely survives contact with a real product. You almost always need to combine similarity with filters, such as restricting results to one user's documents, a date range, or a category. How a database handles those filters can matter more than its raw speed, because a naive approach scans far more candidates than it should.
Qdrant treats this as a first-class concern. It indexes payload fields and runs filters inside the HNSW graph traversal, so the search prunes non-matching vectors as it walks the graph rather than fetching a large candidate set and discarding most of it afterward. On selective queries, where only a small slice of the data qualifies, that in-graph approach is materially faster and is the strongest argument for Qdrant on filter-heavy workloads.
Pinecone manages filters during traversal as well, applying metadata constraints as it searches, which keeps filtered queries fast without exposing the mechanics. pgvector typically takes a post-filter path, scanning a candidate set from the vector index and then applying the SQL WHERE clause, which is simple and fully expressive thanks to Postgres but can do more work than necessary on highly selective filters. The upside for pgvector is that you get the entire SQL language for those filters, including joins against other tables, which neither dedicated engine can match.
Hybrid search and the embedding dimension
Dense vectors capture meaning, but they miss exact terms that a keyword search would catch, such as a product code or a rare proper noun. Hybrid search blends the two, combining dense similarity with sparse keyword matching to recover the best of both. Qdrant supports hybrid search natively, storing dense and sparse vectors together and fusing their results, which is a meaningful edge for applications where users sometimes search by concept and sometimes by exact phrase. Pinecone has built sparse and hybrid capabilities into its service as well, and pgvector can approximate the pattern by pairing its vector index with Postgres full-text search in the same query, again leaning on the fact that everything is in one database.
The embedding dimension itself shapes every number in this comparison. A 1536-dimensional embedding, common from popular embedding models, costs more memory and compute per vector than a 768-dimensional one, which is part of why benchmarks at different dimensions are hard to compare directly. Smaller embeddings store and search faster but can lose nuance, so the choice of embedding model ripples through storage cost, query latency, and overall recall regardless of which database you pick. Some teams shrink dimensions deliberately, through models that support shorter outputs, to cut their vector bill, and that decision often matters as much as the database choice. Whichever engine you land on, the embedding you feed it sets the floor for both cost and quality, so it deserves the same scrutiny as the database itself.
Operational model: managed versus self-hosted
The operational question often outweighs every benchmark, because it determines who spends time keeping the system alive. pgvector inherits whatever you already do for Postgres. If a managed provider like Supabase or a cloud database runs your Postgres, vectors come along for free with no new system to learn, and a single backup covers both your relational data and your embeddings. That consolidation is a quiet but significant advantage.
Pinecone removes operations entirely. There is no server to patch, no index to rebuild by hand, and no capacity to provision, which is exactly what a small team without a database specialist wants. The cost is lock-in and a higher bill, since you cannot take the engine and run it elsewhere. Qdrant offers a middle path: run the open-source engine yourself and own the operations, or pay for Qdrant Cloud and offload them, with the freedom to move between the two because the software is the same. For teams wary of vendor lock-in, that exit option has real value.
A vector database comparison decision guide
Pulling the threads together, the choice falls out of three questions about your situation rather than a single best answer. The first is scale. Under two million vectors, pgvector is hard to beat on cost and simplicity. In the tens of millions and climbing, Pinecone's steady latency without tuning earns its premium, and a well-resourced Qdrant deployment is the open alternative at that size.
The second question is whether your data already lives in Postgres. If it does, pgvector lets you keep one database, one backup, and one query language, and the convenience often outweighs a raw speed deficit. The third question is filtering. If your queries lean heavily on selective metadata filters, Qdrant's in-graph filtering is the standout, while pgvector wins when those filters need the full power of SQL, including joins.
Budget threads through all three. pgvector and self-hosted Qdrant sit at the low end, Qdrant Cloud in the middle, and Pinecone at the top, and the multiples grow with scale. A team optimizing for the lowest invoice and willing to do some operations leans toward pgvector or self-hosted Qdrant. A team optimizing for zero operations and predictable performance at scale leans toward Pinecone.
Picking the right tool for your stage
The most useful framing is to match the database to the stage you are in rather than the scale you imagine. Early projects almost always start best with pgvector, because the data is small, Postgres is probably already in the stack, and the cost is negligible. Many applications never outgrow that choice, and migrating later is a known, bounded task rather than a crisis. Starting simple costs you nothing if you stay small and very little if you grow.
It helps to remember that the embeddings themselves are portable. A vector is just an array of numbers, so moving from one database to another mostly means re-inserting the same vectors and rebuilding the index, not regenerating anything from scratch. The friction lives in the query layer and the metadata schema rather than the data, which is why a migration is a planned afternoon rather than a rewrite. That portability is a quiet argument for starting with the simplest option: you keep the door open to every other engine without paying for capacity you may never need, and you defer the harder decision until your real traffic, not a forecast, tells you it is time.
As a workload climbs into the millions of vectors and query volume rises, the calculus shifts toward a dedicated engine. Teams that prize control and want to keep costs down provision Qdrant, lean on its filtering and throughput, and accept the operational ownership that comes with it. Teams that would rather pay to make the problem disappear move to Pinecone and stop thinking about indexes altogether. None of these is wrong in the abstract, because the right answer is the one that fits your data size, your budget, and your appetite for running infrastructure. Measure those three honestly against your own workload, run a small benchmark on your real embeddings before committing, and the decision tends to make itself.