Choosing a Vector Database in 2026: pgvector vs Pinecone vs Qdrant vs Weaviate

Here is my actual opinion before the nuance: most teams should start with pgvector, and most teams asking which vector database to use have not yet earned the right to care. You probably do not have a vector database problem yet. You have a "ship the product" problem, and pgvector lets you ship without adding a new piece of infrastructure. This post is about that default, and the specific signals that mean you have genuinely outgrown it.

If you are still fuzzy on what a vector database even does, start with what a vector database is and how RAG uses it, then come back here for the buying decision.

The default: pgvector#

If you already run Postgres, pgvector is an extension that adds a vector type and similarity search. Your vectors live in the same database as the rest of your data, in the same backups, the same transactions, the same access controls. No new service to deploy, secure, monitor, and pay for. That is a bigger deal than any benchmark.

CREATE EXTENSION IF NOT EXISTS vector;
 
CREATE TABLE docs (
  id bigserial PRIMARY KEY,
  content text,
  embedding vector(1536)
);
 
-- HNSW index for fast approximate search
CREATE INDEX ON docs USING hnsw (embedding vector_cosine_ops);
 
-- nearest neighbours to a query vector
SELECT id, content
FROM docs
ORDER BY embedding <=> '[...]'
LIMIT 5;

And it is not a toy. With an HNSW index, pgvector returns results in single-digit milliseconds at sensible scales and holds its own against dedicated databases at high accuracy on equivalent compute. For under roughly 10 million vectors with straightforward similarity queries, it is usually all you need. The killer feature is that you can join your vector search against your normal relational data in one query, no syncing two systems.

When you have outgrown it#

You move off pgvector for concrete reasons, not vibes. The usual triggers:

• Your vector count is in the tens or hundreds of millions and index build times and memory pressure are hurting your Postgres instance.
• You need heavy metadata filtering ("vectors from this tenant, in this date range, with this tag") at scale, and the way Postgres combines filtering with vector search is too slow.
• You need hybrid search (dense vectors plus keyword/BM25) as a first-class feature rather than something you hand-roll.
• You want zero operational ownership and would rather pay someone to run it.

When one of those is real, here are the three contenders worth your time.

Pinecone: pay to not think about it#

Pinecone is managed-only and proprietary. You do not run anything; you call an API. The serverless tier (which fixed the old expensive per-pod pricing model) scales storage and compute independently and is competitive on price now.

Pick Pinecone when operational simplicity is worth more to you than control or cost, and you do not want to own a stateful service. The tradeoffs: you are locked into their platform, the serverless tier trades some latency for convenience, and at very large scale (100M+ vectors) the bill gets real, into thousands of dollars a month. For a small team that wants vector search to just be someone else's problem, that can still be the right trade.

Qdrant: best performance per dollar if you self-host#

Qdrant is open source with a managed cloud option, and it is the one I reach for when I want strong performance without paying managed-service prices. Its in-graph filtering genuinely pulls ahead when you have selective metadata filters on large collections, which is exactly the workload that makes pgvector struggle. Self-hosted on a small VPS it will handle millions of vectors for tens of dollars a month.

Pick Qdrant when you want the best price-to-performance and are willing to run a service (or pay for their managed tier). It is my default recommendation for teams that have outgrown pgvector but still care about cost.

Weaviate: strongest for hybrid search and rich schema#

Weaviate is also open source with a managed cloud, and its sweet spot is hybrid search and a richer data model. If combining vector similarity with keyword search out of the box matters to you, or you want a more schema-driven approach with built-in modules, Weaviate is the natural pick. Its managed entry tier is among the cheapest of the major players.

Pick Weaviate when hybrid search and schema richness are central to your product, rather than raw vector throughput at the lowest cost.

The comparison at a glance#

How I would actually decide#

Start on pgvector. Ship the product. Add a real retrieval eval so you know your numbers (recall@k, latency at p95). When something specific breaks (build times, filter latency, scale, an SLA you keep missing) you will know exactly which capability you are buying, and the choice gets easy:

• Want it fully off your plate, cost secondary: Pinecone.
• Want the best cost-to-performance and can run a service: Qdrant.
• Hybrid search and schema are central: Weaviate.

Do not migrate on a benchmark blog post. Migrate when your own metrics say pgvector is the bottleneck. Migrating means re-indexing your whole corpus and adding a stateful dependency, so the bar should be a measured problem, not a hypothetical one.

Wrapping up#

The honest answer to "which vector database in 2026" is: pgvector until proven otherwise, then Qdrant for cost-conscious self-hosting, Pinecone for hands-off managed, and Weaviate when hybrid search is the point. The database matters far less than people think compared to your chunking and embedding choices, which is why this is the fourth post in the series, not the first.

If you want to go back to the start, the series opens with chunking strategies for RAG.