Choosing a Vector Store: Pinecone, Chroma, and pgvector Compared
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).
Related
- 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.