The vector database choice gets debated endlessly online, but for most projects it matters far less than your chunking and retrieval strategy. Still, picking the wrong one means unnecessary infrastructure work or a costly migration later. In 2026 the four most common choices are Chroma (also called ChromaDB), Qdrant, Pinecone and pgvector. Others exist, Weaviate, Milvus, LanceDB, turbopuffer, but these four cover the large majority of RAG projects. Here is what actually differs.

Vector databases at a glance

Read the table as a shortlist tool, not a verdict. Every row matters only in a specific context, and the sections below explain when.

Chroma: the simplest starting point

Chroma, also called ChromaDB, runs embedded in your Python process or as a lightweight local server. There is zero infrastructure to stand up, which makes it the fastest way to get a RAG prototype working and a fine choice for small to medium datasets. It persists to disk, has a simple collection API, and integrates with LangChain and LlamaIndex out of the box. What it does not have is a distributed scaling story: no native clustering, limited concurrency under heavy write load, and metadata filtering that is functional but basic. That is rarely a problem until it suddenly is, usually around a million vectors or when several services hit it at once.

• ✓Strengths: no infra, fast to start, good local developer experience, native framework integrations.
• ✓Limits: single node, basic filtering, weak under concurrent writes, not built for horizontal scale.

Qdrant: production-grade filtering, self-hosted

Qdrant is an open-source engine written in Rust. You self-host it or use Qdrant Cloud, and it is built for the case where vector similarity alone is not enough. Its filter-aware HNSW index combines similarity with structured conditions, date ranges, categories, tenant IDs, permissions, efficiently and at scale, rather than filtering before or after the search and paying for it. It supports scalar, product and binary quantization to cut memory, dense and sparse vectors for hybrid search, and a distributed mode with sharding and replication. The cost is that you operate it, or pay for the managed tier.

• ✓Strengths: strong filtered search, quantization, hybrid search, distributed mode, broad SDK coverage.
• ✓Limits: you run the infrastructure, or move to the paid cloud tier; more moving parts than an embedded store.

Pinecone: fully managed, zero ops

Pinecone is a managed SaaS with no self-hosting option. Its serverless indexes scale storage and query capacity without your team touching a server, and latency stays predictable as data grows. The trade-offs are real: pricing is usage-based and grows with volume and query rate, you have less control over index configuration, and your vectors live with one vendor. For a team with no operations capacity and a budget that fits the pricing, that is often an acceptable deal.

• ✓Strengths: no ops, predictable latency at scale, serverless capacity, quick to adopt.
• ✓Limits: no self-hosting, usage-based cost that grows, vendor lock-in, less index control.

pgvector: when you already run Postgres

pgvector adds vector search to an existing Postgres database as an extension. There is no new piece of infrastructure to operate, and you can filter with plain SQL WHERE clauses and join a similarity search against your relational data in a single query, with full transactional consistency. Recent versions support both HNSW and IVFFlat indexes and a half-precision vector type to save space. At very high vector counts or query rates, dedicated engines still outperform it, and pgvectorscale from Timescale pushes that ceiling higher. For moderate datasets it removes an entire moving part from your stack.

-- pgvector: similarity search + metadata filter + join, one query
SELECT d.id, d.title, d.content, a.name AS author
FROM documents d
JOIN authors a ON a.id = d.author_id
WHERE d.tenant_id = $1
  AND d.published_at >= now() - interval '90 days'
ORDER BY d.embedding <=> $2
LIMIT 5;

• ✓Strengths: no extra infra, SQL filtering, joins with relational data, transactional writes, one datastore to back up.
• ✓Limits: slower than dedicated engines past a few million vectors, index build and RAM cost, tuning is on you.

Chroma or pgvector to start?

These are the two common ways to begin. Choose pgvector if you already run Postgres and want a single datastore, SQL filtering, and transactional writes alongside your application data. Choose Chroma for a pure-Python prototype where you do not want to manage a database at all. Neither is where you end up if you grow to tens of millions of vectors under load, but both are more than enough to ship a first version and learn what your retrieval actually needs.

Performance and scale

What drives vector search performance is mostly not the brand. It is the index type and its parameters (HNSW ef_construction and M), quantization, how selective your metadata filters are, the dataset size, and the recall target you accept. Directionally: dedicated engines like Qdrant and Pinecone pull ahead past a few million vectors and under concurrent load, while Chroma and plain pgvector are fine up to roughly a million vectors at typical RAG query rates. Public benchmarks vary widely with configuration, so treat them as direction and measure with your own data, your recall target, and your filter patterns.

• ✓Dataset size and growth rate.
• ✓Recall@k at your chosen k, not just raw speed.
• ✓p95 latency, filtered and unfiltered, since filtering changes the cost.
• ✓Ingestion throughput and index build time.
• ✓Memory footprint of the index, with and without quantization.

Filtering and hybrid search

Metadata filtering is where RAG quality is often won or lost: tenant isolation, recency, document type, access control. The question is whether the database filters as part of the search or before and after it, which changes both accuracy and speed. Qdrant, Pinecone and pgvector all handle filtered search well; Chroma is more limited. Hybrid search, combining dense vectors with a sparse keyword signal such as BM25 or SPLADE, is built into Qdrant, available in Pinecone, and possible in pgvector with extensions. It matters most when exact terms, names, codes, error strings, need to rank alongside semantic matches.

Cost

• ✓Chroma: the infrastructure you run it on, close to nothing for small local or single-instance use.
• ✓Qdrant: self-hosted compute you provision, or Qdrant Cloud tiers priced on memory and storage.
• ✓Pinecone: usage-based, billed on storage plus read and write units, predictable in operation but growing with scale.
• ✓pgvector: a marginal cost on a database you already pay for, mainly storage and the RAM the index needs.

Migrating between databases

Vectors are portable. As long as you keep the same embedding model, you do not re-embed anything to switch databases. What changes is the client API, the filter syntax, the index configuration and the metadata schema. If a switch is plausible, keep the vector store behind an interface, the vectorstore abstraction in LangChain or LlamaIndex is enough, so the change stays in one place. You only re-embed when you change the embedding model itself, which is a separate and larger decision.

Decision guide

• ✓Prototyping or a small dataset: Chroma.
• ✓Already running Postgres, moderate scale: pgvector.
• ✓Self-hosted with heavy metadata filtering: Qdrant.
• ✓No ops team and a budget that fits: Pinecone.
• ✓Tens of millions of vectors at high query rates: Qdrant, Pinecone, or pgvector with pgvectorscale.

FAQ

Chroma or Qdrant?

Chroma for the simplest local start and small datasets. Qdrant when you need production-grade filtered search, control over self-hosting, or scale beyond a single node. A common path is to prototype on Chroma and move to Qdrant once retrieval requirements are clear.

ChromaDB vs pgvector: which should you choose?

pgvector if you already run Postgres and want SQL filtering, joins with your data, and one datastore to operate. Chroma if you want a zero-database Python prototype. Both top out around a million vectors for typical RAG traffic, so the decision is about your existing stack, not raw capability.

Is Pinecone worth the cost?

Yes if you have no operations capacity and the usage-based pricing fits your volume. If you can self-host, Qdrant or pgvector will usually cost less and give you more control.

Do you need a dedicated vector database for a small RAG system?

No. Below roughly a million vectors at normal RAG query rates, pgvector or Chroma is enough. Move to a dedicated engine when you have a measured reason, not in anticipation of one.

The short version: start with Chroma or pgvector, keep the vector store behind an interface, and reach for Qdrant or Pinecone when a concrete limit, scale, filtering, or ops load, forces the move. The database matters, but less than the retrieval quality you build on top of it.