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

Short version: if Postgres is already in your stack, use pgvector. It is fine to roughly 50 million vectors, it lives in the database you already run, and it costs you no second system to operate. Past that point, Qdrant is the safe pick when raw vector latency is what you are buying, and Weaviate is the safe pick when hybrid keyword-plus-vector ranking in one query is the actual requirement. Pinecone, Chroma, Milvus and Vespa each win a narrower case, covered below.

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, and a second database genuinely pays for itself past about 50M vectors or when you need hybrid ranking in one query. Here is the honest 2026 rundown of the six worth knowing, when each fits, and where the marketing oversells.

At a glance

Qdrant and Weaviate both run on Layerbase Cloud. Pinecone, Chroma and Milvus do not, for reasons covered in each section below, and neither does pgvector: our managed Postgres ships the standard contrib extensions and vector is not one of them.

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.

One thing to be clear about, since this is our site: Layerbase Cloud does not ship pgvector on its managed Postgres. The images carry the standard contrib extensions and vector is not among them, so if pgvector is the plan, host Postgres somewhere that bundles it. pgvector vs Qdrant goes through the decision in detail.

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. Qdrant and Weaviate also branch there, which no other managed vector store offers: fork the embeddings before an eval run or a reindex, and throw the fork away.

FAQ

Which vector database should I use in 2026?

pgvector, unless you have a specific reason not to. If Postgres is already running in your stack, pgvector handles roughly 50 million vectors and saves you a second database to operate. Reach past it when you outgrow that ceiling, when hybrid keyword-plus-vector ranking is the core of the workload, or when you are serving a billion vectors with sub-millisecond p99.

Is pgvector good enough for production?

Yes, for the scale most applications actually reach. It gives you vector columns, distance operators and HNSW indexing, and the indexing work in the last two releases brought it within striking distance of dedicated vector databases through about 50M vectors. Where it starts to feel its limits is single-digit-millisecond p99 at 100M vectors and up, where tuning HNSW parameters inside Postgres becomes real operational work.

When is a dedicated vector database actually worth it?

Past about 50M vectors, or when you need vector and keyword ranking answered by one query. Those are the two cases where a second database pays for its own operational cost. Below that, the honest answer is that you are buying features the workload will not use.

What is the difference between Qdrant and Weaviate?

Qdrant is the speed pick and Weaviate is the feature pick. Qdrant is written in Rust and public benchmarks put it roughly 10-25% ahead of Weaviate and Milvus on common workloads, with p99 at 10M vectors landing near 12ms against 16ms for Weaviate. Weaviate answers vector and BM25 keyword ranking in a single query and treats multi-tenancy as a first-class feature, which matters if each of your customers needs an isolated vector space.

Is it hard to migrate between vector databases?

Not usually. Vectors are just floats, so moving the data is typically one script that reads from one store and writes to the other. What does not move is the query layer: Pinecone's API is proprietary, so leaving it is a rewrite rather than a pg_dump. The lock-in is in the queries, not the data.

Can I try pgvector, Qdrant and Weaviate side by side?

Yes, and it is the fastest way to settle the question. Layerbase Cloud runs all three with the same free dev tier, so you can load one real dataset into each and run your own queries against them in an afternoon. Qdrant and Weaviate also branch there, which means you can fork the embeddings before an eval run or a reindex and throw the fork away afterwards.

Wrapping up

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.

Try pgvector via Postgres, Qdrant, or Weaviate.