Choosing a Vector Store: Pinecone, Chroma, and pgvector Compared

Q: What two finalists should most startups spike?

Often pgvector (if on Postgres) vs one managed vector DB, or Chroma vs managed if still pre-product-market fit.

Use this page when you need a ranked, side-by-side reference for where agent embeddings live.

Scores are engineering fit heuristics for common RAG-agent workloads, not vendor marketing.

APIs, pricing tiers, and feature names move; verify at build.

How to Use This List

Start with Quick pick by job, then confirm in the master matrix.
Prefer the simplest store that meets scale, tenancy, and ops constraints.
Pair with Vector Databases & RAG Basics if the team is still learning embed/index/query.
Re-score after a spike that uses your chunk volume, filters, and QPS - not a toy notebook.

Quick Pick by Job

If your primary job is…	First shortlist	Usually skip first
Managed scale, low ops ownership	Pinecone (or peer managed vector DBs)	Self-hosting ANN stacks with no on-call
Local demos, notebooks, small apps	Chroma (embedded / local server)	Enterprise multi-region clusters
Already on Postgres, moderate vectors	pgvector	Adding a second distributed system too early
Strong SQL filters + vectors together	pgvector	Pure vector SaaS without relational joins
Fastest path from prototype to shared team index	Chroma or managed free tier	Building custom ANN from scratch
Strict VPC / data-residency DIY	pgvector or self-hosted Chroma/alternatives	Public SaaS without a private plan
Very large ANN + productized namespaces	Pinecone / managed peers	Single-node local Chroma as the forever plan

Master Comparison Matrix

Ratings: H = strong default fit, M = workable with effort, L = weak default fit for that axis.

Axis	Pinecone (managed vector DB)	Chroma (embeddable / self-host)	pgvector (Postgres extension)
Time-to-first index	H cloud UX	H local Python DX	M if Postgres already exists; else setup cost
Ops overhead	L for you (vendor operates)	M (you run process/volume)	M-H (you already run Postgres)
Horizontal scale story	H productized	M (architecture-dependent)	M (DB scaling patterns; not a pure ANN service)
Metadata filters	H first-class	H common patterns	H via SQL `WHERE` + vector ops
Hybrid / keyword	M-H (product features vary; verify)	M (compose yourself or via stack)	H with Postgres FTS + vector
Relational joins	L (export/join elsewhere)	L	H same transaction/query plane
Cost model	Usage / units (watch egress & replicas)	Infra + eng time	Postgres storage/CPU you already pay
Local offline dev	L-M (emulator/patterns vary)	H	H with local Postgres
Ecosystem gravity	Strong managed RAG integrations	Strong Python prototype culture	Strong data-platform / Supabase / RDS culture
Lock-in risk	Index + API shape	Storage format + client	Lower if you keep SQL portable
Honest downside	Bill + vendor dependency	Easy to outgrow casual deploy	ANN performance tuning & vacuum ops

Other valid stores (Weaviate, Qdrant, Milvus, Azure AI Search, OpenSearch k-NN, etc.) follow the same axes: managed vs self-host, filter power, hybrid, and who wakes up for pages.

Ranked Defaults by Constraint

1. Need production agent RAG with minimal new ops

Pinecone (or similar managed) - indexes, namespaces, and scaling as a service.
pgvector - if Postgres is already production-hardened on the team.
Chroma self-hosted - only with real deployment, backups, and monitoring.
In-memory toy indexes - demos only.

2. Need local prototype this afternoon

Chroma embedded / local.
pgvector in Docker Compose if SQL filters matter in the spike.
Managed free tiers - when team already has accounts and keys.
Hand-rolled NumPy - teaching only (see Basics).

3. Need strong tenancy filters and reporting joins

pgvector - vectors beside operational tables and RLS patterns.
Managed vector DB with metadata filters + external warehouse joins.
Chroma with careful metadata design - without SQL joins.
Separate vector DB + nightly ETL - more moving parts.

4. Need hybrid keyword + vector for SKUs and error codes

pgvector + Postgres full-text (or equivalent SQL FTS).
Managed stores with native hybrid APIs (verify current feature matrix).
Dual write to OpenSearch/Elastic + vectors - powerful, heavier.
Vector-only with huge top-k - usually a false economy.

5. Need multi-region / high QPS product surface

Managed vector services designed for that load profile.
Specialized self-hosted ANN (Milvus/Qdrant/etc.) with platform eng.
pgvector - viable with careful indexing and read scaling; validate latency SLOs.
Single-node Chroma - not the default for global QPS.

6. Need lowest conceptual load for a Python agent tutorial

Chroma or framework default (for example LlamaIndex local).
pgvector if the course already teaches SQL.
Managed cloud - extra account friction for classrooms.
Building HNSW yourself - never for the tutorial path.

Cost and Ops Notes (compressed)

Store class	You pay mainly in…	Watch for…
Managed (Pinecone-class)	Usage units, storage, replicas, support tier	Silent cost growth as agents re-query every turn
Chroma-class self-host	Machines, disks, backups, upgrades	"Works on my laptop" becoming production
pgvector	Postgres CPU, memory, storage, autovacuum	Index build time, recall vs `lists`/`m`/`ef` style knobs (verify)

Agent systems query retrieval often (every tool call that needs grounding).

Budget for query QPS and embedding API cost, not only storage GB.

Feature Myths vs Reality

Claim you will hear	More accurate reading
"We need a vector DB to do RAG"	You need vectors + search. Postgres or a library can be enough early.
"Managed is always more expensive"	Eng on-call for a self-hosted cluster can dwarf SaaS for small teams.
"pgvector cannot scale"	It scales like Postgres with ANN trade-offs; validate your latency and recall.
"Chroma is only a toy"	Fine for many internal tools if you operate it; not magic for global SaaS.
"One store forever"	Many teams start local, move managed or Postgres as constraints appear.
"Filters are optional"	Multi-tenant agents without filters are a data leak waiting to happen.

Anti-Patterns When Using This Matrix

Anti-pattern	Why it fails	Better move
Picking by Twitter hype	Ignores filters, backups, and team skills	Weight ops + tenancy columns
Putting prod secrets in a laptop Chroma path	Data loss and leakage	Real deploy, encryption, access control
One global collection for all customers	Cross-tenant retrieval risk	Namespaces, metadata filters, or DB RLS
Changing embed models without rebuild	Silent garbage neighbors	Version indexes per model id
Optimizing store before chunking/eval	Store choice will not fix bad chunks	Fix data plane first
Dual-writing three stores "for flexibility"	Consistency hell	One source of truth + migration plan

Default Decision Order

Where does authoritative text already live? Prefer fewer systems if Postgres already holds the corpus metadata.
What is the scale class? Thousands of chunks vs hundreds of millions changes the shortlist.
Who is on call? No platform eng usually means managed or existing Postgres.
What filters are non-negotiable? Tenant, language, doc type, ACL.
Do you need hybrid search day one? Exact IDs and codes push SQL FTS or native hybrid.
Spike two finalists for 1-2 days with real questions and measure hit-rate + p95 latency.
Write an ADR including embed model id, distance metric, and backup story.

FAQs

Is Pinecone required for serious agents?

No. It is a strong managed option. Serious agents require good chunking, filters, evals, and ops - which several stores can support.

When is Chroma the wrong default?

When you need multi-region SLAs, heavy concurrent write/query isolation, or a team that will not operate another data service carefully.

When does pgvector beat a dedicated vector DB?

When vectors are moderate scale, SQL filters/joins matter, and Postgres expertise (and HA) already exists.

Can I start on Chroma and move to Pinecone later?

Yes if you keep an ingestion pipeline that can re-embed/re-upsert from source documents. Avoid app code that depends on proprietary query quirks without an interface.

Do LlamaIndex and LangChain lock me to one store?

No. Both treat vector stores as pluggable backends. Still pin versions and test migrations.

How do namespaces relate to multi-tenancy?

Namespaces/collections help isolate corpora. You still need authz in the app so one tenant cannot query another's namespace.

What about Weaviate, Qdrant, or Milvus?

Evaluate them on the same axes in the matrix. Many teams pick them for self-hosted ANN features; the decision process is identical.

Should the agent talk to the vector DB directly?

Prefer a thin retrieval service/tool with credentials server-side. Models should not receive raw admin API keys.

How much does embedding choice matter versus store choice?

Usually more. A weak embed model or messy chunks will fail on every store. Pick a store that fits ops, then invest in data quality.

What two finalists should most startups spike?

Often pgvector (if on Postgres) vs one managed vector DB, or Chroma vs managed if still pre-product-market fit.

How often should we revisit the store decision?

At 10x corpus growth, new tenancy rules, hybrid-search needs, or repeated latency incidents.

Does OpenRouter change the vector store choice?

No. OpenRouter routes chat/completion models. Embeddings and vector storage remain a separate data-plane decision (unless you also standardize embed providers).

How Vector Search Gives Agents a Searchable Memory - why stores exist for agents
Vector Databases & RAG Basics - hands-on embed and search
Building a Retrieval Tool an Agent Can Call - store behind a tool
Hybrid Search: Combining Vector Similarity with Keyword Filters - when FTS matters
Vector Databases & RAG Best Practices - operating habits
LlamaIndex Basics - framework with pluggable stores

Stack versions: Pins from the category manifest (verify at build): OpenRouter (~315+ models, July 2026 pricing/fees); LangGraph 1.0+; CrewAI 1.14+; Microsoft Agent Framework 1.0; Vercel AI SDK 6; Pydantic AI (latest); LlamaIndex (latest); OpenAI Agents SDK (latest + MCP); MCP (Linux Foundation governance); A2A (HTTP+SSE+JSON-RPC 2.0); Solana @solana/web3.js + @solana/spl-token.

Scores are engineering fit heuristics for common RAG-agent workloads, not vendor marketing.

APIs, pricing tiers, and feature names move; verify at build.

How to Use This List

Start with Quick pick by job, then confirm in the master matrix.
Prefer the simplest store that meets scale, tenancy, and ops constraints.
Pair with Vector Databases & RAG Basics if the team is still learning embed/index/query.
Re-score after a spike that uses your chunk volume, filters, and QPS - not a toy notebook.

Quick Pick by Job

If your primary job is…	First shortlist	Usually skip first
Managed scale, low ops ownership	Pinecone (or peer managed vector DBs)	Self-hosting ANN stacks with no on-call
Local demos, notebooks, small apps	Chroma (embedded / local server)	Enterprise multi-region clusters
Already on Postgres, moderate vectors	pgvector	Adding a second distributed system too early
Strong SQL filters + vectors together	pgvector	Pure vector SaaS without relational joins
Fastest path from prototype to shared team index	Chroma or managed free tier	Building custom ANN from scratch
Strict VPC / data-residency DIY	pgvector or self-hosted Chroma/alternatives	Public SaaS without a private plan
Very large ANN + productized namespaces	Pinecone / managed peers	Single-node local Chroma as the forever plan

Master Comparison Matrix

Ratings: H = strong default fit, M = workable with effort, L = weak default fit for that axis.

Axis	Pinecone (managed vector DB)	Chroma (embeddable / self-host)	pgvector (Postgres extension)
Time-to-first index	H cloud UX	H local Python DX	M if Postgres already exists; else setup cost
Ops overhead	L for you (vendor operates)	M (you run process/volume)	M-H (you already run Postgres)
Horizontal scale story	H productized	M (architecture-dependent)	M (DB scaling patterns; not a pure ANN service)
Metadata filters	H first-class	H common patterns	H via SQL `WHERE` + vector ops
Hybrid / keyword	M-H (product features vary; verify)	M (compose yourself or via stack)	H with Postgres FTS + vector
Relational joins	L (export/join elsewhere)	L	H same transaction/query plane
Cost model	Usage / units (watch egress & replicas)	Infra + eng time	Postgres storage/CPU you already pay
Local offline dev	L-M (emulator/patterns vary)	H	H with local Postgres
Ecosystem gravity	Strong managed RAG integrations	Strong Python prototype culture	Strong data-platform / Supabase / RDS culture
Lock-in risk	Index + API shape	Storage format + client	Lower if you keep SQL portable
Honest downside	Bill + vendor dependency	Easy to outgrow casual deploy	ANN performance tuning & vacuum ops

Other valid stores (Weaviate, Qdrant, Milvus, Azure AI Search, OpenSearch k-NN, etc.) follow the same axes: managed vs self-host, filter power, hybrid, and who wakes up for pages.

Ranked Defaults by Constraint

1. Need production agent RAG with minimal new ops

Pinecone (or similar managed) - indexes, namespaces, and scaling as a service.
pgvector - if Postgres is already production-hardened on the team.
Chroma self-hosted - only with real deployment, backups, and monitoring.
In-memory toy indexes - demos only.

2. Need local prototype this afternoon

Chroma embedded / local.
pgvector in Docker Compose if SQL filters matter in the spike.
Managed free tiers - when team already has accounts and keys.
Hand-rolled NumPy - teaching only (see Basics).

3. Need strong tenancy filters and reporting joins

pgvector - vectors beside operational tables and RLS patterns.
Managed vector DB with metadata filters + external warehouse joins.
Chroma with careful metadata design - without SQL joins.
Separate vector DB + nightly ETL - more moving parts.

4. Need hybrid keyword + vector for SKUs and error codes

pgvector + Postgres full-text (or equivalent SQL FTS).
Managed stores with native hybrid APIs (verify current feature matrix).
Dual write to OpenSearch/Elastic + vectors - powerful, heavier.
Vector-only with huge top-k - usually a false economy.

5. Need multi-region / high QPS product surface

Managed vector services designed for that load profile.
Specialized self-hosted ANN (Milvus/Qdrant/etc.) with platform eng.
pgvector - viable with careful indexing and read scaling; validate latency SLOs.
Single-node Chroma - not the default for global QPS.

6. Need lowest conceptual load for a Python agent tutorial

Chroma or framework default (for example LlamaIndex local).
pgvector if the course already teaches SQL.
Managed cloud - extra account friction for classrooms.
Building HNSW yourself - never for the tutorial path.

Cost and Ops Notes (compressed)

Store class	You pay mainly in…	Watch for…
Managed (Pinecone-class)	Usage units, storage, replicas, support tier	Silent cost growth as agents re-query every turn
Chroma-class self-host	Machines, disks, backups, upgrades	"Works on my laptop" becoming production
pgvector	Postgres CPU, memory, storage, autovacuum	Index build time, recall vs `lists`/`m`/`ef` style knobs (verify)

Agent systems query retrieval often (every tool call that needs grounding).

Budget for query QPS and embedding API cost, not only storage GB.

Feature Myths vs Reality

Claim you will hear	More accurate reading
"We need a vector DB to do RAG"	You need vectors + search. Postgres or a library can be enough early.
"Managed is always more expensive"	Eng on-call for a self-hosted cluster can dwarf SaaS for small teams.
"pgvector cannot scale"	It scales like Postgres with ANN trade-offs; validate your latency and recall.
"Chroma is only a toy"	Fine for many internal tools if you operate it; not magic for global SaaS.
"One store forever"	Many teams start local, move managed or Postgres as constraints appear.
"Filters are optional"	Multi-tenant agents without filters are a data leak waiting to happen.

Anti-Patterns When Using This Matrix

Anti-pattern	Why it fails	Better move
Picking by Twitter hype	Ignores filters, backups, and team skills	Weight ops + tenancy columns
Putting prod secrets in a laptop Chroma path	Data loss and leakage	Real deploy, encryption, access control
One global collection for all customers	Cross-tenant retrieval risk	Namespaces, metadata filters, or DB RLS
Changing embed models without rebuild	Silent garbage neighbors	Version indexes per model id
Optimizing store before chunking/eval	Store choice will not fix bad chunks	Fix data plane first
Dual-writing three stores "for flexibility"	Consistency hell	One source of truth + migration plan

Default Decision Order

Where does authoritative text already live? Prefer fewer systems if Postgres already holds the corpus metadata.
What is the scale class? Thousands of chunks vs hundreds of millions changes the shortlist.
Who is on call? No platform eng usually means managed or existing Postgres.
What filters are non-negotiable? Tenant, language, doc type, ACL.
Do you need hybrid search day one? Exact IDs and codes push SQL FTS or native hybrid.
Spike two finalists for 1-2 days with real questions and measure hit-rate + p95 latency.
Write an ADR including embed model id, distance metric, and backup story.

FAQs

Is Pinecone required for serious agents?

No. It is a strong managed option. Serious agents require good chunking, filters, evals, and ops - which several stores can support.

When is Chroma the wrong default?

When you need multi-region SLAs, heavy concurrent write/query isolation, or a team that will not operate another data service carefully.

When does pgvector beat a dedicated vector DB?

When vectors are moderate scale, SQL filters/joins matter, and Postgres expertise (and HA) already exists.

Can I start on Chroma and move to Pinecone later?

Yes if you keep an ingestion pipeline that can re-embed/re-upsert from source documents. Avoid app code that depends on proprietary query quirks without an interface.

Do LlamaIndex and LangChain lock me to one store?

No. Both treat vector stores as pluggable backends. Still pin versions and test migrations.

How do namespaces relate to multi-tenancy?

Namespaces/collections help isolate corpora. You still need authz in the app so one tenant cannot query another's namespace.

What about Weaviate, Qdrant, or Milvus?

Evaluate them on the same axes in the matrix. Many teams pick them for self-hosted ANN features; the decision process is identical.

Should the agent talk to the vector DB directly?

Prefer a thin retrieval service/tool with credentials server-side. Models should not receive raw admin API keys.

How much does embedding choice matter versus store choice?

Usually more. A weak embed model or messy chunks will fail on every store. Pick a store that fits ops, then invest in data quality.

What two finalists should most startups spike?

Often pgvector (if on Postgres) vs one managed vector DB, or Chroma vs managed if still pre-product-market fit.

How often should we revisit the store decision?

At 10x corpus growth, new tenancy rules, hybrid-search needs, or repeated latency incidents.

Does OpenRouter change the vector store choice?

No. OpenRouter routes chat/completion models. Embeddings and vector storage remain a separate data-plane decision (unless you also standardize embed providers).

How Vector Search Gives Agents a Searchable Memory - why stores exist for agents
Vector Databases & RAG Basics - hands-on embed and search
Building a Retrieval Tool an Agent Can Call - store behind a tool
Hybrid Search: Combining Vector Similarity with Keyword Filters - when FTS matters
Vector Databases & RAG Best Practices - operating habits
LlamaIndex Basics - framework with pluggable stores

Stack versions: Pins from the category manifest (verify at build): OpenRouter (~315+ models, July 2026 pricing/fees); LangGraph 1.0+; CrewAI 1.14+; Microsoft Agent Framework 1.0; Vercel AI SDK 6; Pydantic AI (latest); LlamaIndex (latest); OpenAI Agents SDK (latest + MCP); MCP (Linux Foundation governance); A2A (HTTP+SSE+JSON-RPC 2.0); Solana @solana/web3.js + @solana/spl-token.

Choosing a Vector Store: Pinecone, Chroma, and pgvector Compared

Search Documentation

Choosing a Vector Store: Pinecone, Chroma, and pgvector Compared