Decision comparison
MongoDB Atlas Vector Search vs pgvector
Neither of these is a dedicated vector database, and that is the point of both. MongoDB Atlas Vector Search indexes embeddings on documents you already store in Atlas; pgvector adds a vector column and index to a PostgreSQL you already run. The choice is usually made for you by which database your application data is already in, because the whole advantage of either is not adding a second system. Where they genuinely differ is reach: pgvector runs anywhere PostgreSQL runs, while Atlas Vector Search requires Atlas.
Architecture choice. These take different approaches to the same problem. Read the table as a fit question rather than a feature race.
All 2 are vector databases.
Quick Comparison
| Decision factor | MongoDB Atlas Vector Search | pgvector |
|---|---|---|
| What it is | Vector search built into MongoDB Atlas, indexing embeddings stored on ordinary documents | A PostgreSQL extension adding a vector column type and index methods to a database you already run |
| Where it runs | MongoDB Atlas managed service on AWS, GCP or Azure; not available on self-managed MongoDB | Anywhere PostgreSQL runs — self-hosted, Docker, Kubernetes, or any managed Postgres that ships the extension |
| Data model | Embeddings as an array field on a JSON document, queried with the aggregation pipeline | A vector column beside your existing relational columns, queried with ordinary SQL |
| Filtering | Pre-filtering on document fields as part of the vector search stage | Any SQL WHERE clause, including joins to other tables, applied by the query planner |
| Index methods | Managed index built and maintained by Atlas; tuning surface is deliberately small | HNSW or IVFFlat, chosen and tuned by you, with parameters exposed directly |
| Transactional guarantees | Documents and their embeddings live together with MongoDB's consistency model | Full ACID transactions across vectors and relational data in the same commit |
| Pricing model | Contact for pricing | Open-source (self-hosted), no paid tiers mentioned |
MongoDB Atlas Vector Search
- What it is:
- Vector search built into MongoDB Atlas, indexing embeddings stored on ordinary documents
- Where it runs:
- MongoDB Atlas managed service on AWS, GCP or Azure; not available on self-managed MongoDB
- Data model:
- Embeddings as an array field on a JSON document, queried with the aggregation pipeline
- Filtering:
- Pre-filtering on document fields as part of the vector search stage
- Index methods:
- Managed index built and maintained by Atlas; tuning surface is deliberately small
- Transactional guarantees:
- Documents and their embeddings live together with MongoDB's consistency model
- Pricing model:
- Contact for pricing
pgvector
- What it is:
- A PostgreSQL extension adding a vector column type and index methods to a database you already run
- Where it runs:
- Anywhere PostgreSQL runs — self-hosted, Docker, Kubernetes, or any managed Postgres that ships the extension
- Data model:
- A vector column beside your existing relational columns, queried with ordinary SQL
- Filtering:
- Any SQL WHERE clause, including joins to other tables, applied by the query planner
- Index methods:
- HNSW or IVFFlat, chosen and tuned by you, with parameters exposed directly
- Transactional guarantees:
- Full ACID transactions across vectors and relational data in the same commit
- Pricing model:
- Open-source (self-hosted), no paid tiers mentioned
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 | MongoDB Atlas Vector Search | pgvector |
|---|---|---|
| GitHub commits, 90d(Developer adoption) | 216 | Not available |
| GitHub stars(Developer adoption) | 153 | Not available |
| Search interest(Market interest) | 0 | 3 |
| Hacker News mentions, 90d(Community interest) | 0 | 10 |
| Hugging Face downloads(Product adoption) | 148.5k | Not available |
| Hugging Face likes(Product adoption) | 118 | Not available |
| Docker Hub pulls(Product adoption) | Not available | 194.8M |
| GitHub commits, 90d(Product adoption) | Not available | 153 |
| GitHub stars(Product adoption) | Not available | 23,000+ |
| npm weekly downloads(Developer adoption) | Not available | 369.9k |
| PyPI weekly downloads(Developer adoption) | Not available | 6.7M |
| Stack Overflow questions(Community interest) | Not available | 90 |
As of September 21, 2026 — updated weekly.
Health & risk evidence
Observed public-source checks for mapped package versions and repositories.
MongoDB Atlas Vector Search
Package vulnerabilities
Not available
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
Interface Preview
MongoDB Atlas Vector Search
Feature Comparison
| Feature | MongoDB Atlas Vector Search | pgvector |
|---|---|---|
| Search | ||
| Approximate nearest-neighbour search | Full support | Full support |
| Filtered vector search | Full support | Full support |
| Joins to other data in one query | Partial support | Full support |
| Hybrid keyword and vector search | Full support | Partial support |
| Data model | ||
| Vectors beside operational data | Full support | Full support |
| Schema enforcement on filter fields | Partial support | Full support |
| ACID transactions covering vectors | Partial support | Full support |
| JSON document storage | Full support | Partial support |
| Operations | ||
| Available on self-managed deployments | Not verified | Full support |
| Managed service option | Full support | Full support |
| Index tuning exposed to the user | Partial support | Full support |
| Runs on AWS, GCP and Azure | Full support | Full support |
| Ecosystem | ||
| Python and Node.js clients | Full support | Full support |
| RAG framework integrations | Full support | Full support |
| Open-source licence | Partial support | Full support |
| Existing footprint in most stacks | Partial support | Full support |
Search
Approximate nearest-neighbour search
Filtered vector search
Joins to other data in one query
Hybrid keyword and vector search
Data model
Vectors beside operational data
Schema enforcement on filter fields
ACID transactions covering vectors
JSON document storage
Operations
Available on self-managed deployments
Managed service option
Index tuning exposed to the user
Runs on AWS, GCP and Azure
Ecosystem
Python and Node.js clients
RAG framework integrations
Open-source licence
Existing footprint in most stacks
Which approach fits
Neither of these is a dedicated vector database, and that is the point of both. MongoDB Atlas Vector Search indexes embeddings on documents you already store in Atlas; pgvector adds a vector column and index to a PostgreSQL you already run. The choice is usually made for you by which database your application data is already in, because the whole advantage of either is not adding a second system. Where they genuinely differ is reach: pgvector runs anywhere PostgreSQL runs, while Atlas Vector Search requires Atlas.
When each approach fits
Choose MongoDB Atlas Vector Search if:
Choose MongoDB Atlas Vector Search when your operational data is already in Atlas and the documents you want to retrieve are the documents you already store. Embeddings become another field, the aggregation pipeline handles retrieval and filtering together, and the index is managed for you rather than tuned. It suits document-shaped content with variable structure, where a rigid schema would be a nuisance rather than a safeguard.
Choose pgvector if:
Choose pgvector when PostgreSQL is your system of record, which for a great many teams it is. Vectors sit beside relational columns, queries are ordinary SQL with joins and WHERE clauses the planner optimises, and a single transaction can update a row and its embedding atomically. It also runs anywhere Postgres runs — self-hosted, Docker, Kubernetes, or any managed provider — so it carries no platform commitment.
These scenarios reflect the available product evidence. Your requirements, existing stack, and team expertise should guide the final decision.
Frequently Asked Questions
Is a general database good enough for vector search?
For a great many applications, yes. Both handle corpora into the millions with reasonable latency, and the operational saving of not running a second system is real and immediate. Dedicated stores earn their place when the retrieval layer grows its own demands — very high query concurrency, per-tenant isolation at scale, hybrid ranking you need to tune, or a corpus large enough that index memory should not compete with your transactional workload. Until then, the extra system is cost without benefit.
What is the biggest practical difference?
Where each can run. pgvector is an extension, so it works on self-hosted PostgreSQL, on Docker or Kubernetes, and on essentially every managed Postgres provider. MongoDB Atlas Vector Search is an Atlas feature and is not available on self-managed MongoDB, so adopting it is a commitment to the managed platform. If avoiding that commitment matters to you, the decision is already made.
How do filters behave?
pgvector inherits the SQL query planner, so a vector search can be combined with any WHERE clause and joined to other tables in one statement — which is powerful and occasionally means reading a query plan to understand why something is slow. Atlas applies pre-filters on document fields as part of the vector search stage, which is simpler to reason about and narrower in what it can express. Neither approach suffers the classic post-filtering recall collapse.
What about index tuning?
pgvector exposes its index methods directly: you pick HNSW or IVFFlat and set the parameters, which means you can tune recall against memory and build time, and also that you have to. Atlas manages the index for you with a deliberately small tuning surface. Teams with an opinion about recall curves will prefer the first; teams who want the database to make a sensible default decision will prefer the second.
Can we move to a dedicated vector database later?
Yes, and it is a normal progression rather than an admission of error. Embeddings are portable — the vectors themselves carry no vendor format — so a migration is an export, a re-upload and a rebuilt index, plus whatever query code changes. The cost is real but bounded, and it is usually smaller than the cost of running a dedicated store for two years before you needed one.