Vector Databases: pgvector vs Pinecone vs Qdrant

Verdict: Which Vector Database Should You Pick?

Pick pgvector when Postgres already holds your data and your vector count stays under tens of millions. Pick Pinecone when you want zero operations and can accept a managed bill. Pick Qdrant when you self-host and need strict filtered search at low latency. Pick Weaviate when hybrid keyword-plus-vector search sits at the core of your product.

That short list covers most real projects. Every team I have seen burn weeks on this decision started with the wrong question. They asked which engine benchmarks fastest. They should have asked which engine fits the stack they already run. Vector search is a feature of your data pipeline, and the database that holds your data has a head start every time.

Use this quick filter before you read further:

• Your app runs Postgres and you want vectors next to relational rows, with ACID and JOINs intact: pgvector.
• You ship a feature, not infrastructure, and no one on the team wants to tune a cluster: Pinecone.
• You run your own hardware or VPC and filtered retrieval must stay fast under strict WHERE clauses: Qdrant.
• Your product blends keyword search with vector search and you want that blend native instead of bolted on: Weaviate.

None of these choices lock you in forever. Migrating embeddings between engines is a re-index job, and most teams outgrow their first pick within a year. The rest of this article gives you the facts behind the verdict so you can defend your pick in a design review.

Also Read:

LLM Structured Outputs: OpenAI vs Anthropic vs Google

How Vector Search Actually Works

An embedding is a fixed-length array of floats. A model turns text, images, or audio into one of these arrays, and the distance between two arrays encodes how similar the two items are. Cosine similarity, Euclidean distance, and inner product are the common measures. The choice of measure rarely decides your architecture, so do not overthink it.

Exact nearest neighbor search compares your query against every stored vector. It delivers perfect recall and falls apart at scale, because a million vectors means a million distance computations per query. Approximate nearest neighbor search, ANN for short, trades a small amount of recall for a large amount of speed. Two index families dominate the field. Graph indexes like HNSW build a multi-layer graph and walk it toward the nearest neighbors. Cluster indexes like IVFFlat group vectors into lists, find the closest lists, and scan those. HNSW answers most production workloads well, which is why nearly every engine in this article ships it.

Two ideas from that paragraph will follow you through the rest of the article. First, recall versus latency is the central trade-off in every benchmark you will read. Second, filtering changes everything: restricting results to rows that match a WHERE clause can starve an ANN index, and each engine handles that problem in its own way. Keep both in mind when you reach the comparison table.

Also Read:

Foreman Review: Reliability Gates for Scheduled AI Agents

If you are still weighing retrieval against training your own model, read the retrieval-versus-fine-tuning guide first: it frames when RAG, and therefore a vector database, is even the right tool.

pgvector vs Pinecone vs Qdrant vs Weaviate: The Comparison

Four engines, four philosophies. pgvector keeps your vectors inside the Postgres you already operate. Pinecone removes operations entirely and bills you for the privilege. Qdrant and Weaviate give you dedicated engines you can self-host, with different answers to filtering and hybrid search. Scan the rows that matter for your workload and skip the rest.

The row that surprises most teams is filtered search. Every engine claims it, and every engine means something different by it. The sections below unpack what those cells cost you in practice.

Also Read:

RAG vs Fine-Tuning: When to Use Which

pgvector in Practice: What You Gain and What Bites You

The pitch for pgvector is simple: your vectors live in the same database as everything else. You keep ACID transactions, you keep JOINs between embeddings and the rows they describe, and you keep your backup story, your replication story, and your monitoring story. No new cluster to learn, no new failure mode to page you at 3 a.m. For teams that already run Postgres in production, this is a serious advantage, and the usual Postgres index types still behave the way you expect alongside the vector indexes.

Adding the extension takes minutes. Create the extension, add a vector column (add the vector column through a migration so the schema change stays reviewable), build an HNSW index, and you have working semantic search. Teams moving up from local prototypes will recognize the SQLite-to-Postgres upgrade path here: the same operational habits scale, and vectors are one more column type.

Also Read:

Gemini Skills Explained: Build Your Own AI Assistant

Two gotchas deserve your attention before you commit. The first is storage and dimension limits. The pgvector README states that each vector takes 4 * dimensions + 8 bytes of storage, and that vectors can have up to 16,000 dimensions. A 1,536-dimension embedding therefore costs about 6 KB per row before indexes. That math is friendly at a hundred thousand rows and worth a spreadsheet at ten million. At very large scale you will reach for halfvec or binary quantization, or for pgvectorscale, the companion extension that pushes pgvector further before you need a new database.

The second gotcha is filtering, and it bites quietly. With approximate indexes, pgvector applies your WHERE clause after the index scan. The README spells out the consequence: if a condition matches 10% of rows, then with HNSW and the default hnsw.ef_search of 40, only 4 rows will match on average. Your strict filter silently returns almost nothing, and the query looks healthy. The fix is iterative index scans, which keep scanning until enough filtered rows accumulate. Turn them on whenever a filter can exclude most of your rows. I consider this the single most important pgvector setting, because the default behavior fails in a way that looks like a data problem instead of a configuration problem.

Source for both limits: the pgvector README and its filtering notes.

The Dedicated Engines: Pinecone, Qdrant, Weaviate

Pinecone sells the absence of operations. You call an API, vectors go in, nearest neighbors come out, and no one on your team tunes an index. The trade is cost and control: your data lives on someone else’s infrastructure, and the bill scales with storage and queries. The current pricing shape is $0.33 per GB per month for storage with a $50 per month minimum once your usage passes that floor, plus a three-week trial that includes $300 in credits. I re-checked the Pinecone pricing page right before writing this, and those numbers still hold; re-check them again before you sign anything, because managed pricing moves often.

Pinecone also collapsed its search surface recently. The Pinecone index docs describe a single index that can serve full-text search with BM25 and Lucene queries, semantic search, and sparse-vector search together, often covering what previously required two indexes. If your product needs keyword matching and semantic matching on the same corpus, that convergence removes a whole integration layer. One caution from the research: Pinecone’s official plans-and-limits page returned a 404 during research, so treat any third-party table of Pinecone limits as rumor until you confirm it on official docs.

Qdrant takes the opposite route: a dedicated engine you run yourself, written for filtered retrieval. Its docs describe the exact strategy most teams reinvent badly. For weak filters that match most rows, you use the HNSW index as it is. For strict filters that match few rows, you use the payload index and do a complete rescore, per the Qdrant indexing guide. That two-path design is the answer to pgvector’s filtering gotcha, built into the engine instead of bolted on with a setting. Qdrant fits teams that self-host and want predictable behavior when a WHERE clause excludes 99% of the corpus.

Weaviate organizes its indexes as a ladder. The Weaviate vector index docs list four types: a flat index for small data, a dynamic index that automatically switches from flat to HNSW as object count scales, the HNSW index itself, and HFresh, a cluster-based index that uses HNSW for its centroid index. The dynamic index is the interesting one for growing products: it spares you the migration from brute force to ANN because the engine changes shape as you grow. Weaviate also fuses BM25 keyword search with vector search natively, which makes it the natural pick when hybrid search is the product rather than a feature. If you are building agent memory on top of retrieval, this piece on giving agents durable retrieval memory pairs well with the choice.

Benchmarks Disagree, and That Is the Point

Vendor benchmarks for vector databases read like sports commentary, and you should read them that way. Two recent ones point in opposite directions, which makes them perfect teaching material.

Benchmark one comes from TigerData, a company that sells managed Postgres. On a dataset of 50 million Cohere embeddings, the company reports that PostgreSQL with pgvector and pgvectorscale achieves 28x lower p95 latency and 16x higher query throughput for approximate nearest neighbor queries at 99% recall, all at 75% lower monthly cost than Pinecone’s storage-optimized index, when self-hosted on AWS EC2. Read that sentence again and notice what it does not say. It does not say pgvector beats every Pinecone index type. It says pgvector plus a performance extension, on self-managed EC2, beats one specific Pinecone index tier at one specific recall target. Source: the TigerData benchmark writeup.

Benchmark two comes from Elastic, a company that sells Elasticsearch. Its DiskBBQ vector engine achieves up to 7x higher vector search throughput than Qdrant at comparable recall on network-attached storage, according to the Elasticsearch Labs post from June 2026. Same pattern: a vendor’s engine beats a competitor’s engine on the vendor’s chosen dataset, hardware, and recall target.

The honest reading is not that one side lies. Dataset size, embedding dimensions, hardware, and the recall target all move the numbers, and vendors pick the configuration that flatters their architecture. Qdrant’s own benchmark page is explicitly vendor-run with dates from early 2024, and it makes the mirror-image claim about Elasticsearch indexing speed. Nobody in this fight publishes neutral numbers, because neutral numbers do not exist: your data, your filters, and your latency budget define the winner.

The practical takeaway is a procedure, not a ranking. Load a representative sample of your own embeddings, build the index each candidate recommends, fix a recall target your product can tolerate, and measure p95 latency and cost per million queries. pgvector’s own docs include a recall-monitoring recipe for exactly this. Thirty minutes of your own benchmarking beats thirty vendor blog posts.

Conclusion: Start With the Database You Already Run

The decision tree from the verdict still stands. Postgres shop under tens of millions of vectors: pgvector, with iterative index scans on and an eye on the storage math. No ops appetite: Pinecone, with the current $50 monthly floor and $0.33 per GB storage in your budget model. Self-hosted with strict filters: Qdrant and its payload-index rescore path. Hybrid search as the product: Weaviate and its index ladder.

Run a thirty-minute proof before you commit. Load one hundred thousand of your real rows, build the HNSW index, set the recall target your feature needs, and measure p95 latency with your actual filters applied. Write the numbers down. That one page of results will settle more arguments than any comparison table, including the one above.

Your turn: run the checklist on your own workload, share your scale numbers and your p95 in the comments, and subscribe for the follow-up deep dive where each of these engines gets a full production setup guide. The best vector database is the one whose trade-offs you measured yourself.