When should you use pgvector, and when should you skip it?

Use pgvector when: under a few million vectors, or when retrieval joins rows you already have. Skip it when: vector search has become the workload rather than a side feature.

When should you use Qdrant, and when should you skip it?

Use Qdrant when: vector-first workloads with heavy metadata filtering at scale. Skip it when: you want no new datastore to operate.

When should you use Pinecone, and when should you skip it?

Use Pinecone when: zero operational work, and vector search is not your core competence. Skip it when: Residency, cost predictability or a query language you control.

When should you use Chroma, and when should you skip it?

Use Chroma when: getting a prototype working in an afternoon. Skip it when: you need durability, scaling or concurrent writes.

← Comparisons

pgvector vs Qdrant vs Pinecone vs Chroma

Most teams adopt a dedicated vector database before they have established that their existing database cannot do the job. That decision is expensive to undo and rarely necessary.

Short answer

Start on pgvector unless you have a specific reason not to. It removes a whole class of consistency problem, and if your retrieval is joining against rows you already have — users, permissions, tenancy — the relational model is simply the right one.

By Lattice editorial · Licence and cost facts verified 2026-09 · method

Retrieval & Vector Stores

pgvectorVector search as a Postgres extension.
QdrantPurpose-built, Rust, strong filtered search.
PineconeFully managed, zero operations.
ChromaPrototyping-first, minimal ceremony.

pgvector vs Qdrant vs Pinecone vs Chroma compared across 5 dimensions
Dimension	pgvector	Qdrant	Pinecone	Chroma
Operational burden	None — you already run Postgres	Low, single binary	None	None
Hybrid (BM25 + vector)	Yes, via Postgres full-text search	Yes	Yes	Limited
Filtering	SQL — very capable	Strong, purpose-built payloads	Strong	Basic metadata filters
Scales past ~10M vectors	Workable, tuning-sensitive	Yes	Yes	No
Best for	Under a few million vectors, or when joins matter	Vector-first workloads at scale	When you want zero operational work	Getting something working in an afternoon

Scroll the table sideways to see every tool.

What this table is not. These are editorial judgements, not benchmarks: Lattice has not run these tools head to head, and no cell uses GitHub stars or vendor benchmark claims as evidence. Licence and cost facts are re-checked on a schedule the build enforces — the receipt is public.

The recommendation

Which should you choose: pgvector, Qdrant, Pinecone or Chroma?

Rules of thumb

If you need to filter by something that lives in your main database, a join beats a denormalised copy you have to keep in sync.
Pure vector search fails on exact tokens — part numbers, error codes, names. Use hybrid retrieval or accept that class of miss.
Validate recall against a query set before migrating. Most disappointing retrieval is a chunking or embedding problem, not a database problem.

Quick answers

When should you use pgvector, and when should you skip it?: Use pgvector when: under a few million vectors, or when retrieval joins rows you already have. Skip it when: vector search has become the workload rather than a side feature.
When should you use Qdrant, and when should you skip it?: Use Qdrant when: vector-first workloads with heavy metadata filtering at scale. Skip it when: you want no new datastore to operate.
When should you use Pinecone, and when should you skip it?: Use Pinecone when: zero operational work, and vector search is not your core competence. Skip it when: Residency, cost predictability or a query language you control.
When should you use Chroma, and when should you skip it?: Use Chroma when: getting a prototype working in an afternoon. Skip it when: you need durability, scaling or concurrent writes.