Decision comparison
ChromaDB vs pgvector
Chroma and pgvector both make vector search easy to start, by opposite routes. Chroma is a dedicated store that runs in-process, so a prototype needs no infrastructure at all. pgvector adds vectors to PostgreSQL, so if you already run Postgres there is no new system, no pipeline, and full SQL available alongside similarity.
Direct comparison. These are reviewed substitutes bought for the same job, so the differences below are the ones that decide between them.
All 2 are vector databases.
Quick Comparison
| Decision factor | ChromaDB | pgvector |
|---|---|---|
| What it is | A developer-first vector store designed to be running in minutes, from a laptop prototype through to light production | An extension that adds vector types and indexes to PostgreSQL, so embeddings live beside the application's existing tables |
| Where vectors live | In a dedicated store, separate from the application's database | In PostgreSQL, beside the application's existing tables |
| Synchronisation | A pipeline keeps the index in step with the source of truth | A row update and its embedding update are one transaction |
| Deployment | In-process for development, or a server, with an object-storage backend | Wherever PostgreSQL already runs — no new system |
| Filtering | Metadata filtering within the store | Full SQL: joins, subqueries and any predicate Postgres supports |
| Operational burden | One more service to deploy, secure, monitor and back up | None beyond the database you already operate |
| Best fit | Retrieval prototypes and light production without an existing Postgres | Applications already on PostgreSQL, where one system is worth more than headroom |
| Integration path | Python and JavaScript clients over a REST API, with LangChain and LlamaIndex support | Python and JavaScript clients over a REST API, with LangChain and LlamaIndex support |
ChromaDB
- What it is:
- A developer-first vector store designed to be running in minutes, from a laptop prototype through to light production
- Where vectors live:
- In a dedicated store, separate from the application's database
- Synchronisation:
- A pipeline keeps the index in step with the source of truth
- Deployment:
- In-process for development, or a server, with an object-storage backend
- Filtering:
- Metadata filtering within the store
- Operational burden:
- One more service to deploy, secure, monitor and back up
- Best fit:
- Retrieval prototypes and light production without an existing Postgres
- Integration path:
- Python and JavaScript clients over a REST API, with LangChain and LlamaIndex support
pgvector
- What it is:
- An extension that adds vector types and indexes to PostgreSQL, so embeddings live beside the application's existing tables
- Where vectors live:
- In PostgreSQL, beside the application's existing tables
- Synchronisation:
- A row update and its embedding update are one transaction
- Deployment:
- Wherever PostgreSQL already runs — no new system
- Filtering:
- Full SQL: joins, subqueries and any predicate Postgres supports
- Operational burden:
- None beyond the database you already operate
- Best fit:
- Applications already on PostgreSQL, where one system is worth more than headroom
- Integration path:
- Python and JavaScript clients over a REST API, with LangChain and LlamaIndex support
Public signals
Verified factual signals only. Bars appear only for like-for-like metrics with five weekly assessments for every tool; missing evidence stays explicit. These signals do not establish enterprise adoption, product quality, or total cost.
| Metric | ChromaDB | pgvector |
|---|---|---|
| Docker Hub pulls(Product adoption) | 7.7M | 194.8M |
| GitHub commits, 90d(Product adoption) | 156 | 153 |
| GitHub stars(Product adoption) | 29,000+ | 23,000+ |
| Search interest(Market interest) | 0 | 3 |
| Hacker News mentions, 90d(Community interest) | 1 | 10 |
| Hugging Face downloads(Product adoption) | 980 | Not available |
| Hugging Face likes(Product adoption) | 427 | Not available |
| npm weekly downloads(Developer adoption) | 211.3k | 369.9k |
| PyPI weekly downloads(Product adoption) | 1.4M | Not available |
| Stack Overflow questions(Community interest) | 266 | 90 |
| PyPI weekly downloads(Developer adoption) | Not available | 6.7M |
As of September 21, 2026 — updated weekly.
Health & risk evidence
Observed public-source checks for mapped package versions and repositories.
ChromaDB
September 21, 2026Package vulnerabilities
npm · chromadb@3.5.0 · PyPI · chromadb@1.5.9
8 vulnerabilities
across 2 packages
Repository security score
Not available
pgvector
September 21, 2026Package vulnerabilities
npm · pgvector@0.3.0 · PyPI · pgvector@0.5.0
0 vulnerabilities
across 2 packages
Repository security score
Not available
Feature Comparison
| Feature | ChromaDB | pgvector |
|---|---|---|
| Architecture | ||
| Vectors beside operational data | Not verified | Full support |
| Transactional updates with the source rows | Not verified | Full support |
| No extra system to run | Partial support | Full support |
| Dedicated search scaling | Partial support | Not verified |
| Query | ||
| Approximate nearest neighbour indexing | Full support | Full support |
| Full SQL joins and predicates | Not verified | Full support |
| Metadata filtering | Full support | Full support |
| Hybrid keyword and vector search | Partial support | Full support |
| Adoption | ||
| Running in minutes | Full support | Full support |
| In-process mode for development | Full support | Not verified |
| Object storage backend | Full support | Not verified |
| Open source | Full support | Full support |
| Integration | ||
| Python and JavaScript clients | Full support | Full support |
| REST API | Full support | Full support |
| Metadata stored with vectors | Full support | Full support |
| Works with LangChain and LlamaIndex | Full support | Full support |
Architecture
Vectors beside operational data
Transactional updates with the source rows
No extra system to run
Dedicated search scaling
Query
Approximate nearest neighbour indexing
Full SQL joins and predicates
Metadata filtering
Hybrid keyword and vector search
Adoption
Running in minutes
In-process mode for development
Object storage backend
Open source
Integration
Python and JavaScript clients
REST API
Metadata stored with vectors
Works with LangChain and LlamaIndex
Which to choose
Chroma and pgvector both make vector search easy to start, by opposite routes. Chroma is a dedicated store that runs in-process, so a prototype needs no infrastructure at all. pgvector adds vectors to PostgreSQL, so if you already run Postgres there is no new system, no pipeline, and full SQL available alongside similarity.
Best-fit scenarios
Choose ChromaDB if:
Choose Chroma when there is no PostgreSQL to build on, or when the retrieval work is separate enough from the application that keeping it apart is the cleaner design. Running in-process removes deployment questions entirely for the first week.
Choose pgvector if:
Choose pgvector when the application already runs on PostgreSQL. Embeddings live beside the rows they describe, so updates are transactional rather than a pipeline, filtering is the full SQL you already write including joins, and there is no additional system to deploy, secure, monitor or back up.
These scenarios reflect the available product evidence. Your requirements, existing stack, and team expertise should guide the final decision.
Frequently Asked Questions
How far does pgvector scale?
Further than most teams expect and not indefinitely. For corpora in the low millions with reasonable query rates it is usually adequate, and the indexes have improved steadily. Beyond that, or where search load would compete with the application's own queries, a dedicated store earns its place. Measure recall and latency on your own corpus rather than assuming either limit.
Is full SQL alongside vectors actually useful?
It removes a common awkwardness. Real retrieval queries want to combine similarity with ordinary predicates and joins — this customer's documents, not archived, ranked by similarity, joined to their metadata. In one database that is a single query. Across two systems it is a retrieval, then a second lookup, then reconciliation in application code.
How does filtering work on each?
Real queries are almost always "similar to this, and belonging to this customer, and not archived", and this is where the two diverge. pgvector filters with SQL over ordinary indexed columns and lets the planner decide whether to filter or search first — flexible, occasionally a bad plan, and debuggable with tools you already know. Chroma filters on metadata stored beside the vectors through its own `where` clauses, which covers the common cases and is narrower than SQL. If your predicates involve joins to other tables, pgvector answers it directly and Chroma means fetching ids and filtering them elsewhere.
What keeps embeddings in step with the rows they describe?
In Postgres, a transaction. The document and its embedding are columns on one row, so an update either happens or does not, and there is no window where the index describes a document that no longer exists. With Chroma it is a pipeline you write: notice the change, re-embed, upsert, delete what was removed, and handle the retries when the embedding service is slow. That work is ordinary and it is also where vector deployments quietly rot. Weigh it heavily if your corpus changes continuously, and lightly if it is rebuilt in batches.
What do these need to run?
An embedding model and a client. Applications in Python or JavaScript call a REST API, embeddings come from an OpenAI, Cohere or open-source model, and the retrieval framework is usually LangChain or LlamaIndex. Self-hosted options run as containers on Docker or Kubernetes with S3 or compatible object storage behind them; managed options need only an API key. The infrastructure is unremarkable — the work is in chunking, embedding choice and keeping the index current.
How should we evaluate them?
With your own corpus and your own queries, measuring recall rather than latency alone. Approximate nearest neighbour search trades accuracy for speed, and the tuning knobs differ between engines, so a fast engine returning worse neighbours looks good on a benchmark and bad to a user. Build a small set of queries with known correct answers, then compare recall at the latency you actually need.