Vector databases compared in 2026: pgvector, Qdrant, Weaviate, Pinecone, Chroma, Milvus

Most teams asking "which vector database" only need one of two answers. The first is pgvector. The second is "whichever one your existing data platform recommends." The rest is shopping for features that 90% of RAG and embedding workloads do not actually use.

That said, the other 10% is real. Here is the honest 2026 rundown of the six vector databases worth knowing, when each fits, and where the marketing oversells.

The two-question framework

Before the rundown, the two questions that determine your answer:

1. Is Postgres already in your stack? If yes, use pgvector. Stop reading. The cost of running a separate vector database almost never justifies itself below a few tens of millions of vectors, and pgvector at that scale is fine.
2. Are you serving more than a billion vectors with sub-millisecond p99? If yes, you are shopping for Milvus or Vespa, and the rest of this post does not really matter. You have a specialist problem.

Everything in between is where the comparison gets interesting.

pgvector

The default. A Postgres extension that gives you vector columns, distance operators, and HNSW indexing. Currently at 0.9, with the indexing improvements in the last two releases bringing it within striking distance of dedicated vector DBs through about 50M vectors.

Use it when: you already run Postgres, your vectors live alongside relational data you also need to join against, your scale is in the millions to low tens of millions, and you do not want to operate a second database.

Avoid it when: you genuinely need single-digit-millisecond p99 at 100M+ vectors. pgvector at that scale starts to feel its limits and the operational overhead of tuning HNSW parameters in Postgres becomes real.

Layerbase Cloud hosts this as part of the regular Postgres engine, so you get pgvector by default with no separate provisioning.

Qdrant

The open-source speed leader. Written in Rust, which shows up in the latency numbers. Public benchmarks have Qdrant about 10-25% faster than Weaviate or Milvus on common workloads. P99 at 10M vectors lands around 12ms for Qdrant versus 16ms for Weaviate and 18ms for Milvus.

Use it when: you outgrew pgvector, you want self-hosted or managed (both work), and latency matters more than feature breadth.

Avoid it when: hybrid search (vector + keyword) is the core of your workload. Qdrant does it, but it is not the headline feature.

Available on Layerbase Cloud as a managed engine.

Weaviate

Hybrid search done well. Vector plus keyword in one query, with the GraphQL surface and BM25 ranking that you would otherwise stitch together yourself. Multi-tenancy is a first-class feature, which matters if you are building a B2B SaaS where each customer needs an isolated vector space.

Use it when: hybrid search is the actual reason you are picking a vector database, or you have multi-tenant requirements that map cleanly to Weaviate's tenant model.

Avoid it when: you just need vectors. The hybrid and GraphQL machinery is weight you carry without benefit.

Available on Layerbase Cloud.

Pinecone

The easiest managed-only experience. You hit an API, vectors get indexed, queries return. There is no self-host path, which is the point, and the developer experience reflects that focus.

Use it when: you are a small team, you do not want to operate anything, your scale is moderate, and the cost difference does not bother you.

Avoid it when: you care about portability, you have cost sensitivity at scale (Pinecone costs add up faster than self-host or cheaper managed options), or you want the option to swap providers later. Pinecone's API is proprietary, so migrating off is not a pg_dump.

Not on Layerbase. If you want managed-only and you are willing to pay the price, Pinecone is the right pick.

Chroma

The best developer experience for prototyping. Python-native, in-memory by default, single-line install, and the API is intuitive for someone who just opened a Jupyter notebook to try RAG.

Use it when: you are prototyping a RAG app, doing research, or building a personal project where production scale is not yet a concern.

Avoid it when: you are deploying to production at any meaningful scale. Chroma's production story has improved a lot in 2025 and 2026, but it still trails Qdrant and Weaviate for serious workloads.

Not on Layerbase. Chroma is best run embedded in your application or on a single server you control.

Milvus

The choice when you have a billion vectors and need them fast. Distributed by design, with Kubernetes-native operators, and a partitioning model that scales horizontally. The trade is that you are now operating a distributed system.

Use it when: you have genuinely large vector workloads, you have ops capacity, and you care about cost per vector at scale (Milvus is competitive there because it is designed for billions).

Avoid it when: your workload is below 100M vectors. The operational overhead is not worth it.

Not on Layerbase. For Milvus-scale problems, you should be running your own cluster or paying Zilliz for managed Milvus.

What about Vertex AI Vector Search and Vespa?

Vertex AI Vector Search is fine if you are deep into Google Cloud and want vector to live next to BigQuery and Vertex AI. Outside of that, it is overkill for the price.

Vespa is the other "billion-vector serious" option alongside Milvus. Older project (started at Yahoo), production-hardened, harder to operate. Use it if you have very specific hybrid-search needs at very large scale, or if you have Vespa expertise on the team.

How to actually pick

If you are honest about what you need, the answer is usually obvious:

• Existing Postgres app, under 50M vectors: pgvector. Done.
• Vectors at the center of a new app, moderate scale: Qdrant if speed matters, Weaviate if hybrid search matters.
• Want zero ops, can pay for it: Pinecone.
• Prototyping in Python: Chroma.
• Billions of vectors, real ops team: Milvus or Vespa.

If you want to try the three you can self-host or get managed easily (pgvector, Qdrant, Weaviate), Layerbase Cloud has all three in one dashboard with the same free dev tier across all of them. Spin one of each up, load a real dataset, run real queries. The answer becomes obvious in an afternoon.

Try pgvector via Postgres, Qdrant, or Weaviate.

Short version

The vector database market is bigger than it needs to be. For most teams, pgvector is the right answer because the database they already run can do the job. For teams that have outgrown that, Qdrant is the safe pick for pure-vector workloads and Weaviate is the safe pick for hybrid. Everything else is shopping for a specific feature that the marketing pages oversell.

Pick what fits today. Vectors are portable (they are just floats) and migration between vector databases is usually a single Python script that reads from one and writes to the other. The lock-in is in the queries, not the data.