Vector Databases in 2026: pgvector vs Pinecone vs Qdrant vs Weaviate

The vector database decision that quietly shapes your entire AI stack

If you build anything with LLMs in 2026, you are building with vectors. Retrieval-augmented generation, semantic search, recommendation engines, agent memory, even fraud detection now live or die by how you store and query embeddings. The vector database you pick is not an abstract infrastructure choice — it dictates your latency, your monthly bill, your ability to filter on metadata, and how painful it will be to migrate six months from now.

Yet most teams still pick the same way they did in 2023: default to whatever blog post they read first. The market has moved. Pinecone is no longer the only serious managed option, pgvector has crossed firmly into production-grade territory, Qdrant has become the favorite of teams that care about Rust-grade throughput, and Weaviate has doubled down on hybrid search and multi-modal retrieval. Picking the wrong one in 2026 is more expensive than it was two years ago, because the workloads have grown and the gap between “fine” and “great” has widened.

This is a decision guide, not a leaderboard. We will walk through when each option actually makes sense, when it will quietly ruin your week, and how to think about the trade-offs the marketing pages tend to skip.

What changed in 2026 (and why your old assumptions are stale)

Three things shifted since the last major wave of vector database posts.

First, embedding dimensions ballooned. The jump from 1536 to 3072 dimensions (text-embedding-3-large, many open-weight models) is not a 2x change in storage — it is closer to 4x once you account for HNSW graph overhead. Indexes that felt comfortable in 2024 now need 3-4x the RAM. A team that benchmarked pgvector on 768-dimensional vectors in early 2024 and decided it was too slow is in for a surprise when they re-test on 3072 dimensions — the failure mode looks identical (slow queries) but the cause is different (dimensionality, not the database).

Second, metadata filtering stopped being a nice-to-have. Production RAG almost always combines a semantic query with a hard filter: tenant scope, document type, recency, region, language. The way your vector database handles that filter — inside the HNSW graph, as a post-filter, or via a separate index path — is now the single biggest predictor of real-world latency. A query that returns in 15ms without a filter can balloon to 200ms with a high-selectivity one, and the difference between a database that handles that gracefully and one that does not is the difference between a product that ships and one that does not.

Third, “just use Postgres” became a defensible answer. pgvector 0.7+ and the pgvectorscale extension closed most of the gap that originally pushed people off Postgres. For a large slice of teams, the right answer in 2026 is the database they are already running. The earlier objections — slow at scale, no good filtering, painful index maintenance — have each been addressed in successive pgvector releases, and the team is now genuinely competitive with purpose-built systems for the workloads most teams actually have.

The four contenders, honestly assessed

pgvector — the boring answer that is usually right

pgvector is a PostgreSQL extension. Vectors live next to your relational data, your transactional guarantees cover them, your backups cover them, and your application code does not have to coordinate between two systems to filter on metadata.

The honest strengths: it is the lowest-friction path if you already run Postgres. The killer feature is the query — vector similarity plus SQL predicates in one statement, with row-level security, joins, and ACID transactions all working as expected. Replicating that in a separate vector service means building an application-level join or pushing filters into metadata, which bypasses the HNSW graph and tanks performance.

The honest weaknesses: it is a single-node extension. There is no horizontal sharding story. Past roughly 2 million vectors on a single instance, index builds start exceeding 20 minutes, and VACUUM operations begin to compete with live query traffic. Past 5 million vectors, you are looking at read replicas, partitioning, or a switch. Also, metadata filtering in pgvector happens as a post-filter on the candidate set, not inside the HNSW graph, so high-selectivity filters (filter that rejects 95%+ of candidates) will be slow.

Opinion: for most teams building their first or second RAG system, pgvector is the right default. Migrating later is annoying but not catastrophic, and the time you save on operational complexity is the time you get to spend on retrieval quality, which actually moves the needle.

Pinecone — fast to start, expensive at scale

Pinecone is a fully managed, purpose-built vector database. You send vectors via API, it stores them, you query them. No infrastructure, no sharding decisions, no upgrade windows. Serverless pricing means you do not pay for idle capacity.

The honest strengths: zero operational overhead. Pinecone handles billions of vectors without the team having to think about it. The p95 latency on managed pod deployments stays under 30 ms even at scale. If your team is small, your time is expensive, and you have more important problems than index tuning, Pinecone is genuinely valuable.

The honest weaknesses: Pinecone’s pricing scales with stored dimensions, not with usage. Storing 50 million vectors at 3072 dimensions is a meaningfully different conversation than 50 million at 768. There is also limited ability to tune the index to control the accuracy/performance trade-off — the system makes those choices for you, which is fine until it is not. And hybrid search (combining vector similarity with BM25 keyword) is not first-class; you end up doing it in application code.

Opinion: Pinecone is the right answer when you do not want to think about vector infrastructure and you are willing to pay for that luxury. It is the wrong answer when you are cost-sensitive, when you need tight index control, or when you are doing real hybrid search.

Qdrant — the high-throughput specialist

Qdrant is an open-source vector database written in Rust, with first-class filtering and a strong story for production deployments that need predictable latency under load. Qdrant Cloud is the managed version; self-hosting is “one Docker run” away from production.

The honest strengths: throughput. Qdrant consistently hits 800+ QPS on 1M-vector benchmarks at 768 dimensions with single-digit millisecond p95 latency. Filtering is done inside the HNSW graph, not as a post-filter, which means high-selectivity filters do not blow up the candidate set. The Rust codebase is small enough that you can actually read it. Qdrant is the database teams pick when they care about latency budgets more than they care about ecosystem familiarity.

The honest weaknesses: ecosystem. Qdrant is less integrated with the broader data toolchain than pgvector (which is just Postgres) or Pinecone (which has every major framework pre-wired). Operational maturity outside Qdrant Cloud is real but requires Rust-fluent or at least Docker-fluent engineers. The community is smaller than Postgres or Pinecone’s, which means fewer Stack Overflow answers when you hit an edge case at 3 a.m.

Opinion: if your workload is filter-heavy, latency-sensitive, and you are not married to Postgres, Qdrant is the production-grade answer most teams overlook. It is especially strong for recommendation systems, real-time personalization, and any workload that combines vector similarity with structured predicates.

Weaviate — hybrid search and multi-modal, with a learning curve

Weaviate is an open-source vector database with a strong hybrid search story (BM25 + vector in a single query) and built-in vectorization modules. Its schema model is more elaborate than the others, which is both its strength and its tax.

The honest strengths: hybrid search is first-class. If your retrieval problem genuinely needs the combination of semantic similarity and keyword matching — legal documents, code search, technical support content — Weaviate has the most mature implementation. Multi-modal retrieval (text, image, etc.) is also more integrated than in pgvector or Pinecone, and the GraphQL API is genuinely useful for complex queries.

The honest weaknesses: the schema model and SDK history add cognitive overhead that does not pay off unless you are using the features that need them. For a team that just wants “store vectors and query by similarity,” Weaviate is more machinery than necessary. Operational stories from teams that have used it in production are mixed — the database works, but the learning curve is real, and migrations from Weaviate are not trivial.

Opinion: Weaviate wins on hybrid search and multi-modal. If you do not need either, you are paying an operational tax for features you are not using.

The decision matrix that actually matters

Scenario	Best fit	Why
Under 1M vectors, already on Postgres, team of 1-5 engineers	pgvector	Lowest friction; SQL + vectors in one place; one database to operate
1-5M vectors, predictable traffic, want zero ops	Pinecone Serverless	No infrastructure; p95 stays under 30 ms; cost predictable until you scale
5M+ vectors, latency-sensitive, filter-heavy	Qdrant Cloud or self-hosted Qdrant	Filtering inside HNSW graph; Rust-grade throughput; predictable p95
Hybrid keyword + vector search is a core requirement	Weaviate	First-class BM25 + vector fusion; mature hybrid implementation
Multi-modal retrieval (text + image + audio)	Weaviate or Pinecone (with multi-modal indexes)	Both have native support; Weaviate is more mature for production
Strict data residency / on-prem only	pgvector or self-hosted Qdrant	Both run in your VPC; no data leaves your infrastructure
Cost-sensitive at scale (50M+ vectors)	pgvector with read replicas, or self-hosted Qdrant	Managed services become expensive at this scale; ops trade-off is worth it

When this approach is a good choice — and when it is not

Choosing a vector database on the merits of the database alone is a mistake. The right choice depends on three things: your team, your data, and your scale trajectory.

pgvector is a good choice when your team already operates Postgres, your vector counts are in the hundreds of thousands to low millions, and your retrieval pattern combines vector similarity with structured predicates. It is not when you are crossing 5M+ vectors on a single instance, you need sub-20ms p95 globally, or you are doing real-time personalization at high QPS.

Pinecone is a good choice when your team is small, your time is expensive, and you have more important problems than vector infrastructure. It is not when cost is a primary constraint, you need tight index control, or you are doing hybrid search at scale.

Qdrant is a good choice when your workload is filter-heavy, latency-sensitive, and you are not married to Postgres. It is not when your team has zero operational capacity, you need extensive ecosystem integrations, or your vector count is so small that the operational complexity is not justified.

Weaviate is a good choice when hybrid search or multi-modal retrieval is a core requirement, and you have the engineering capacity to absorb the schema model. It is not when you just need basic vector similarity — you are paying an operational tax for features you are not using.

Common mistakes that bite teams in production

• Skipping index parameter tuning. HNSW parameters (m, ef_construction, ef_search) have a 2-5x impact on latency and recall. The defaults are conservative for a reason, but if you never measure your recall, you are flying blind.
• Putting high-selectivity filters as post-filters. If your filter rejects 99% of candidates, the vector search has to scan the entire HNSW graph to find enough neighbors. Either restructure the filter, denormalize the data, or pick a database that does filtered search inside the graph (Qdrant, recent Weaviate).
• Choosing embedding dimensions without checking the cost. 3072-dim embeddings cost roughly 4x the storage of 768-dim. If you do not need the recall, you are paying for accuracy you are not measuring.
• Treating vector search as the bottleneck. In most RAG systems, retrieval quality is the bottleneck, not retrieval speed. Spending a week tuning HNSW parameters when your chunking strategy is broken is the wrong order of operations.
• Forgetting about backups, PITR, and disaster recovery. pgvector inherits Postgres tooling here; Pinecone and Qdrant Cloud handle it for you; self-hosted Qdrant and Weaviate are on you. Plan for it before you have 50M vectors and no backup.
• Ignoring metadata schema design. The metadata you store alongside vectors determines the filters you can run. If you encode document type as a free-text field, you will spend months cleaning it up.
• Migrating too early. Most teams change their vector database once in a project’s lifetime. Choose the one that fits the scale you expect to be at in 18 months, not the scale you are at today. But do not over-engineer — a 1M-vector workload in Pinecone is fine; migrating at 10M is also fine.

A practical decision checklist

Before you commit to a vector database, run through this list.

1. Estimate your 18-month vector count. If you are under 1M, almost any choice is fine. If you are crossing 5M, the choice matters.
2. Identify your filter patterns. If you combine vector search with structured filters, prioritize databases that filter inside the HNSW graph.
3. Decide on operational ownership. If your team has zero capacity for new infrastructure, managed services win on default. If you have database engineers, self-hosting becomes competitive.
4. Check ecosystem fit. Are you using LangChain, LlamaIndex, or rolling your own? Most major frameworks support all four options, but the integration quality varies.
5. Budget realistically. Pinecone and Weaviate Cloud look cheap at 100K vectors and expensive at 50M. pgvector and self-hosted Qdrant look expensive at 100K (because of the human time) and cheap at 50M.
6. Prototype with your real workload. Synthetic benchmarks are misleading. Use a representative slice of your actual data and measure recall, latency, and cost before committing.
7. Plan the migration path. Even if you are not migrating now, know what it would take. Exporting from pgvector is trivial; exporting from Pinecone requires their tooling.

What is worth doing now vs. what is still overhyped

Worth doing now: treating vector database choice as a real engineering decision, not a default. Picking the database that matches your scale and filter patterns. Measuring recall on a real workload, not synthetic data. Investing in metadata schema design before you have 50M vectors and a cleanup project. Running a one-week prototype with your actual data before you commit to a vendor relationship.

Still overhyped: the idea that managed vector databases are always cheaper. At small scale, yes. At 10M+ vectors with steady traffic, the math flips. Also overhyped: chasing the latest “vector database” startup. The four options in this guide are the four serious contenders in 2026; the long tail of new databases is mostly marketing, not engineering. And overhyped: the assumption that “more dimensions = better embeddings.” Matryoshka-style training and binary quantization are making lower-dimensional embeddings surprisingly competitive, and many production systems are overpaying for accuracy they are not measuring.

One more thing worth saying out loud: most of the teams I have seen over-engineer this decision are the same teams that under-invest in retrieval quality. Chunking strategy, embedding model choice, hybrid search, and reranking are responsible for more production RAG wins than the vector database underneath. Pick a sensible default, ship the system, and come back to this question when you actually have scale problems. A mediocre vector database with great retrieval quality will outperform a great vector database with mediocre retrieval quality every time.

How to think about this in 18 months

The vector database market in 2026 is more mature than it was two years ago, but it is not settled. Three things are worth watching.

First, the embedding model consolidation. As fewer, larger embedding models dominate (and as open-weight models close the gap with proprietary ones), the metadata you store alongside vectors becomes more important than the vector itself. The teams that designed their schemas to capture document type, source, recency, and provenance will be in a much stronger position than the teams that treated vectors as opaque blobs.

Second, the rise of disk-based vector indexes. Most production vector databases still keep the entire HNSW graph in RAM, which is the single biggest cost driver at scale. Disk-based and hybrid memory/disk indexes (DiskANN-style approaches, pgvectorscale’s StreamingDiskANN) are getting good enough to deploy in production, and they will change the cost math significantly. If you are sizing your infrastructure for 50M+ vectors today, it is worth re-checking in 12 months.

Third, the integration story. As vector search becomes a feature of general-purpose databases (Postgres, MongoDB, Elasticsearch, even SQLite) rather than a separate product, the “do I need a separate vector database” question will get easier to answer. In 2026, that question is still nuanced. By 2027, for most workloads, the answer may simply be “no, the database you already use does it fine.”

None of this means the decision you make today does not matter. It means the decision you make today should be the one that fits your scale and your team for the next 18 months, with a clear eye on what the migration path looks like if the landscape shifts. Pick the boring answer, ship the system, and revisit when the data tells you it is time.

Frequently asked questions

Is pgvector production-ready in 2026?
Yes, for most workloads under 5 million vectors on a properly sized Postgres instance. Past that, you are looking at partitioning, read replicas, or a switch.

When does Pinecone become more expensive than self-hosting?
Roughly when you cross 5-10M vectors with steady query traffic, or when your embedding dimensions exceed 1536. The exact crossover depends on your traffic pattern and your team’s fully-loaded cost.

Can I switch vector databases later?
Yes, but it is annoying. The vector format is portable; the metadata, the index parameters, the filter patterns, and the application code that depends on them are not. Plan for one migration in a project’s lifetime.

Do I need a vector database at all, or can I just use file-based search?
For under 100K documents, brute-force search in memory is fine. Past that, you want a real index. The complexity is worth it well before 1M vectors.

What about the new vector databases (Lance, Vexilla, etc.)?
They are interesting, but they have not yet built the operational track record of the four options in this guide. For production systems in 2026, sticking with the proven options is the safer bet.

The short version

Default to pgvector if you are on Postgres. Pick Pinecone if you do not want to think about it. Choose Qdrant if your workload is filter-heavy and latency-sensitive. Pick Weaviate if hybrid search is a core requirement. Stop optimizing this decision before you have shipped, and put the energy into retrieval quality instead.