Every team building a RAG system in 2026 faces the same decision tree. You need a vector store. You open the comparison guides. Pinecone says it is the fastest. Milvus says it scales to billions. pgvector says you already have PostgreSQL. Neo4j says relationships matter. FAISS says nothing because it is a library that does not make claims.
None of them are wrong. All of them are incomplete answers.
The right vector store is determined by one thing and one thing only: the shape of the queries your users actually ask. Not your current query distribution — your full query distribution, including the hard queries you have not written good answers for yet.
This is the complete guide to what each option actually does, where each one genuinely wins, and — critically — why Neo4j occupies a fundamentally different architectural position than every other option on this list.
Table of Contents
- What Every Vector Database Is Actually Doing
- FAISS: The Library That Started It All
- pgvector: The PostgreSQL Extension
- MongoDB Atlas Vector Search: The Document Database Approach
- Milvus: Purpose-Built for Billion-Scale
- Pinecone: The Fully Managed Standard
- Neo4j: The Fundamentally Different Option
- The Benchmark Numbers You Can Trust
- The Query Shape Decision Framework
- The Hybrid Pattern That Production Uses
- Decision Matrix
1. What Every Vector Database Is Actually Doing
Before comparing options, the mechanics must be clear — because many comparisons confuse what different systems are optimized for.
All vector databases do one thing at the core: given a query vector, find the stored vectors closest to it by some distance metric — cosine similarity, dot product, or Euclidean distance. The vectors represent meaning. Proximity in vector space means semantic similarity. This is what enables semantic search: you embed the user's question, retrieve the stored chunks closest to that embedding, and pass them to the model.
The variation between systems is not what they compute — it is how efficiently they compute it at scale, what additional data they store alongside vectors, what query patterns they support beyond pure similarity, and what operational model they require.
FAISS is a library — it computes in memory with no persistence, no metadata, no serving infrastructure. Every other option on this list is a database — it adds persistence, API serving, metadata filtering, and operational management. pgvector, MongoDB, and Neo4j are vector capabilities added to existing databases. Milvus and Pinecone are databases built specifically for vector workloads.
Neo4j is the only option that combines vector search with a native property graph — making it architecturally distinct from all the others in a way that matters enormously for specific query types.
2. FAISS: The Library That Started It All
Facebook AI Research Similarity Search was released in 2017 and remains the reference implementation for approximate nearest neighbor search. It is what many of the databases above use under the hood for their core ANN computation.
FAISS is not a database. It has no persistence, no API server, no metadata storage, no access control, no multi-tenancy. It is a highly optimized C++ library with Python bindings that performs extremely fast in-memory similarity search.
On raw vector search speed with GPU acceleration, FAISS outperforms full vector databases including Milvus on pure similarity search benchmarks. The computation is faster when you eliminate all the database overhead.
Where FAISS wins: Research environments, offline batch processing, embedding this functionality into a custom application where you control all surrounding infrastructure, and benchmarking to understand what the ANN computation ceiling looks like before adding database overhead.
Where FAISS fails: Any production application that needs persistence across restarts, metadata filtering, concurrent access, updates to the vector index, or monitoring. Using FAISS in production means building all of this yourself. Teams that do this once rarely do it twice.
The honest verdict: FAISS is the correct choice if you are a researcher or if you are building infrastructure that wraps it. It is the wrong choice if you are building an application and want to be operational in weeks rather than months.
3. pgvector: The PostgreSQL Extension
pgvector adds vector storage and ANN search to PostgreSQL. You store vectors as a column type alongside your regular relational data. You query them with SQL. You get the vector search result in the same transaction as your relational joins.
This is pgvector's genuine and significant advantage: you eliminate a separate infrastructure component. Your product data, your user data, your document metadata, and your embeddings all live in one database. A query that needs to filter by user permissions, document date, and semantic similarity executes in one SQL statement rather than requiring a round trip between a vector database and a relational database.
pgvectorscale — Timescale's extension on top of pgvector — achieves 471 queries per second at 99 percent recall on 50 million vectors. This is a serious production number. For most applications under 50 to 100 million vectors, pgvector with pgvectorscale is a fully viable production choice.
The limitation is architectural, not operational. PostgreSQL's query planner was not built for ANN search. At hundred-million-plus vector counts, purpose-built ANN indexes in dedicated vector databases outperform pgvector on recall and throughput. The operational simplicity that makes pgvector attractive at smaller scales becomes a bottleneck at larger ones.
Where pgvector wins: Applications already on PostgreSQL, RAG systems under 50 million vectors, any use case where the ability to JOIN vector results with relational data in a single query is architecturally important, and teams that correctly prioritize operational simplicity over maximum theoretical throughput.
Where pgvector fails: Vector counts above 100 million, applications requiring horizontal scaling of the vector index independent of the relational database, and workloads where the vector search is the primary query pattern rather than a feature within a broader relational application.
The honest verdict: For most RAG workloads under a few million vectors, pgvector in your own Postgres is the strongest choice because embeddings, documents, and metadata sit in one database you can query with SQL joins. The scale ceiling is real but most applications never reach it.
4. MongoDB Atlas Vector Search: The Document Database Approach
MongoDB Atlas Vector Search adds vector indexing and ANN search to MongoDB's document model. Like pgvector, the value proposition is co-location: your document data and your embeddings live in the same database, queryable together.
MongoDB's document model has a genuine advantage over pgvector's relational model for certain data shapes. JSON documents with nested structure, arrays, and variable schema are natural in MongoDB and require schema gymnastics in PostgreSQL. For applications built on document data — content management systems, product catalogs, customer profiles — storing embeddings alongside documents in MongoDB is architecturally cleaner than in PostgreSQL.
The Atlas Vector Search implementation supports HNSW indexing, approximate nearest neighbor search, and hybrid search combining vector similarity with MongoDB's existing query operators. You can filter by any document field alongside the vector search.
Where MongoDB wins: Applications already on MongoDB, document-heavy use cases where the flexible schema is genuinely valuable, and teams that want vector search as an integrated feature of their existing document database rather than a separate service.
Where MongoDB fails: Pure vector workloads that do not benefit from the document model, applications requiring maximum ANN performance at billion-scale, and use cases where the operational overhead of Atlas is not justified by the document model advantage.
The honest verdict: MongoDB Atlas Vector Search is the right choice if you are already running MongoDB and want to add semantic search without new infrastructure. It is not the right choice if you do not already have MongoDB or if your primary workload is pure vector similarity without the document model context.
5. Milvus: Purpose-Built for Billion-Scale
Milvus is the open-source vector database built from the ground up for scale. Where pgvector adds vector capabilities to a relational database, Milvus is built specifically for storing, indexing, and querying embeddings at massive volume with low latency.
Milvus supports multiple index types — HNSW for latency-optimized workloads, IVF for memory-constrained environments, DiskANN for SSD-friendly storage when RAM is scarce, and SCANN for GPU-accelerated workloads. This flexibility in index type is Milvus's primary technical advantage over systems that support only HNSW.
At billion-scale vector counts, Milvus remains the strongest open-source option. It is designed for horizontal scaling — add more nodes and throughput scales proportionally. The operational complexity is real: Milvus requires multiple components including etcd for coordination, MinIO for storage, and the Milvus server itself. This is more infrastructure than pgvector or Pinecone.
Zilliz Cloud is the managed version of Milvus for teams that want billion-scale performance without the operational overhead.
Where Milvus wins: Image and video embedding search at massive scale, multi-modal vector workloads, applications genuinely operating at hundred-million to billion-plus vector counts, and teams with the infrastructure engineering capacity to operate a distributed vector database.
Where Milvus fails: Teams without the operational capacity to run distributed infrastructure, applications under 50 million vectors where pgvector's simplicity wins, and use cases that require rich relational or graph-structured metadata alongside vectors.
The honest verdict: Milvus is the right choice when scale is the primary constraint and you have the engineering resources to operate it. It is the wrong choice as a starting point for most teams who will not reach billion-scale and who underestimate the operational overhead.
6. Pinecone: The Fully Managed Standard
Pinecone is the fully managed, closed-source vector database designed for teams that want production-grade vector search without any infrastructure to operate. You create an index, insert vectors through an API, and query through an API. Pinecone handles scaling, replication, failover, and performance optimization.
Pinecone supports hybrid search — combining dense vector similarity with sparse keyword scores — and metadata filtering. Sub-100ms latency at billion-scale in managed infrastructure is its primary value proposition. Pinecone is the choice that minimizes time-to-production for teams whose primary concern is shipping a working product rather than maximizing performance or controlling infrastructure.
The limitations are the other side of the managed coin: you cannot self-host Pinecone, you cannot inspect or control the underlying infrastructure, and pricing scales with usage in ways that can become significant at high volumes. Data residency requirements that preclude cloud storage preclude Pinecone.
Where Pinecone wins: Teams that want maximum managed simplicity, applications where vector search is the primary workload and relational or graph data is secondary, and organizations with data residency requirements compatible with Pinecone's available regions.
Where Pinecone fails: Organizations with data residency, air-gap, or on-premises requirements. Teams with cost sensitivity at high query volumes. Applications that require vector search to be tightly coupled with relational or graph data.
The honest verdict: Pinecone is the fastest path to production for a pure vector search use case. The trade-off is cost at scale and loss of infrastructure control. For a startup shipping a RAG product in weeks, Pinecone is often the correct choice. For an enterprise with data residency requirements or cost sensitivity at scale, the managed simplicity is not worth the constraints.
7. Neo4j: The Fundamentally Different Option
Neo4j is not competing with the other databases on this list on their terms. Every other option is optimized for one primary operation: given a query vector, find the nearest stored vectors. Neo4j adds vector search to a system whose primary design principle is something entirely different: the efficient storage and traversal of relationships between entities.
This is not a minor distinction. It is the architectural difference that determines when Neo4j is the right choice and when it is the wrong one — and understanding it precisely is the most valuable thing you can take from this entire comparison.
What Neo4j Actually Is
Neo4j is a native property graph database. Data is stored as nodes (entities), relationships (connections between entities), and properties (attributes on both nodes and relationships). Queries are written in Cypher, a declarative graph query language designed for traversal: start from these nodes, follow these relationship types, filter by these properties, return these results.
In 2025, Neo4j added native vector indexing — the ability to store embedding vectors as properties on nodes and search them using ANN. This addition makes Neo4j a genuinely hybrid system: it can do pure vector similarity search like the other databases on this list, AND it can traverse the graph from any retrieved node to find related entities through explicit relationship paths.
The Capability That Sets Neo4j Apart
The practitioner community has largely converged on a pattern by early 2026: vectors for semantic entry-point retrieval, graphs for relational depth.
On the MultiHopRAG benchmark, GraphRAG improved recall by 11 percentage points over a strong vector-store baseline. Zep's temporal knowledge graph built on Neo4j scored 63.8 percent on LongMemEval versus Mem0's 49.0 percent — a 15-point gap driven entirely by graph-based temporal reasoning. On the Deep Memory Retrieval benchmark, Zep achieved 94.8 percent versus MemGPT's 93.4 percent.
These numbers are not about vector search speed. They are about the quality of answers to questions that require traversing relationships — questions that pure vector similarity search cannot answer correctly regardless of how fast the ANN computation runs.
Neo4j is the default for property-graph workloads with mature Cypher tooling. If your enterprise AI pipeline is still relying on basic cosine similarity over flat chunked vectors, you are serving hallucination-prone answers on questions that require relational reasoning.
Where Neo4j Genuinely Wins
Multi-hop reasoning queries. "Which customers purchased products from suppliers affected by the port disruption that correlated with the Q3 logistics delay?" This query requires traversing: customers → purchase relationships → products → supplier relationships → suppliers → disruption relationships → events → timeline relationships → delays. A vector database finds chunks that look similar to this query. Neo4j traverses the actual path and returns the structurally correct answer.
Entity disambiguation across documents. "Apple" as a technology company versus "Apple" as a fruit requires disambiguation based on graph context — what entities appear near Apple in the document graph, what relationship types connect them, what properties they have. Vector similarity alone cannot resolve this reliably. Graph traversal through the entity-relationship structure can.
Temporal reasoning in agent memory. Agents that need to remember not just what happened but the temporal sequence and causal relationships between events benefit from graph-structured memory. Neo4j Labs' agent-memory package treats the graph as a conversation store and knowledge graph simultaneously — every turn, extracted entity, and reasoning step stored as a node, retrieved through Cypher traversal combined with vector similarity on node embeddings.
Compliance and audit chains. "Which decisions were made by which agents based on which data from which source systems over the last quarter, and which regulatory requirements do they implicate?" This is a provenance traversal query — following the causal chain from decision back through the reasoning steps to the source data. Graph traversal handles this natively. No vector database does.
Knowledge graph-grounded RAG. Treating knowledge graphs and vector databases as separate infrastructure introduces double-query latency. Neo4j's hybrid approach lets vector search and graph traversal execute against the same data in the same query — eliminating the round trip between a vector database and a separate graph database that every other hybrid architecture requires.
Where Neo4j Loses
On single-hop fact retrieval — the Natural Questions benchmark — GraphRAG underperforms vanilla RAG by 13.4 percent. Neo4j is optimized for relational depth, not encyclopedic lookup. For time-sensitive queries requiring real-time knowledge, graph RAG shows accuracy drops of up to 16.6 percent due to stale entity representations. Average latency for graph retrieval is 2.3x higher than vector search at equivalent corpus sizes.
Neo4j has a learning curve. Cypher is a well-designed query language but it requires learning. Graph data modeling — deciding which entities become nodes, which become properties, which become relationship types — requires design decisions that flat vector storage does not. One developer community assessment: "Learning Neo4j was tough but worth it" — and it is worth it only when your use case demands the graph capability.
The honest verdict: Neo4j is the right choice when your queries require multi-hop reasoning, entity disambiguation, temporal relationship tracking, provenance traversal, or any other capability that requires understanding how entities connect — not just which chunks are semantically similar. It is the wrong choice for pure semantic search use cases where the answer lives in a single document and relationships between entities are not relevant.
8. The Benchmark Numbers You Can Trust
These are the benchmark results from independently validated sources rather than vendor benchmarks:
Recall at scale — VectorDBBench results:
pgvectorscale at 50 million vectors: 471 QPS at 99 percent recall. Competitive with purpose-built systems at this scale.
Purpose-built databases (Milvus, Qdrant, Weaviate) outperform PostgreSQL extensions beyond 50 to 100 million vectors on both throughput and recall at equivalent hardware.
Hybrid search advantage:
Weaviate's hybrid search combining BM25 with dense vectors, processing all simultaneously rather than as separate queries, demonstrates the strongest hybrid search performance in the 2026 benchmark landscape.
Hybrid retrieval generally delivers 15 to 30 percent recall improvement over single-method vector search — the same finding validated across multiple independent benchmarks.
Neo4j graph advantage on multi-hop tasks:
MultiHopRAG benchmark: 11 percentage point recall improvement for graph-augmented retrieval over vector-store baseline.
LongMemEval: Neo4j-backed temporal knowledge graph 63.8 percent versus pure vector approach 49.0 percent — 14.8 point gap.
The benchmark takeaway: graph retrieval value scales with query complexity. On simple single-hop questions, pure vector search is faster and more accurate. On multi-hop and relational questions, graph-augmented retrieval wins by margins that matter.
The important benchmark caveat:
FAISS outperforms full vector databases on raw ANN speed with GPU acceleration. This number is irrelevant for most production systems because production systems require all the things FAISS does not provide: persistence, serving infrastructure, access control, metadata filtering, and operational management.
9. The Query Shape Decision Framework
Your vector database selection should be driven by your query distribution, not by benchmark numbers or vendor claims.
Your queries are predominantly single-hop semantic lookups:
"What is our policy on X?" "Find documents about Y." "Which articles discuss Z?"
The answer lives in one or a few documents. Similarity is the right retrieval mechanism.
Use pgvector if under 50 million vectors and you value operational simplicity.
Use Pinecone if you want fully managed and zero infrastructure.
Use Milvus if at hundred-million-plus scale with infrastructure capacity.
Do not use Neo4j — the graph adds cost and latency with no benefit.
Your queries require joining vector results with structured data:
"Find documents about X from customers in the enterprise tier created in the last 90 days."
Semantic similarity is necessary but not sufficient — structured filters are equally important.
Use pgvector — the SQL join is the natural solution.
Use MongoDB Atlas if your data is document-structured.
Do not use Pinecone for complex filter patterns at scale.
Your queries require multi-hop reasoning:
"What are the relationships between the events that led to the Q3 incident?"
"Which entities are connected through the supply chain to the affected supplier?"
"What did the agent decide last Tuesday and what data did that decision depend on?"
Use Neo4j. Not because it has the best vector search — it does not. But because no other database on this list can traverse the relationship graph that your query requires. Combining Qdrant for fast vector entry-point retrieval with Neo4j for graph traversal is the validated pattern from Qdrant's own documentation.
Your queries are time-sensitive at billion-plus scale:
Real-time recommendation, image search, video retrieval at massive volume.
Use Milvus with DiskANN for SSD-friendly billion-scale storage.
Use Pinecone if fully managed is acceptable and cost allows.
10. The Hybrid Pattern That Production Uses
By early 2026, the practitioner community has largely converged on a pattern that this comparison makes clear: vectors for semantic entry-point retrieval, graphs for relational depth.
The two-system architecture that avoids double-query latency uses Neo4j as both vector store and graph database. Vector search finds the entry-point nodes. Cypher traversal follows relationship paths from those entry points to gather related context. Both operations execute against the same data in the same query.
The two-system architecture that maximizes pure vector performance at scale uses Qdrant or Milvus for fast ANN retrieval and Neo4j for graph traversal on the retrieved results. Qdrant's own documentation describes exactly this pattern in the GraphRAG with Qdrant and Neo4j tutorial.
The single-system architecture for most applications uses pgvector when the scale is appropriate and the relational co-location advantage is real. It uses Pinecone when managed simplicity outweighs all other concerns. It uses Milvus when scale is the primary constraint.
The architecture that almost everyone evolves toward as their application matures: start with a vector database plus a reranker. Add a knowledge graph or GraphRAG-style index when you have multi-hop questions, entity disambiguation pain, or strict compliance requirements. This is the evolution path documented by FutureAGI, BuildMVPFast, and the practitioner community across multiple independent sources.
11. Decision Matrix
| Dimension | FAISS | pgvector | MongoDB | Milvus | Pinecone | Neo4j |
|---|---|---|---|---|---|---|
| Infrastructure | Library | Postgres ext | Managed/Self | Self/Managed | Fully managed | Self/Managed |
| Scale ceiling | RAM-bound | 50-100M | 100M+ | Billion+ | Billion+ | Relationship-depth |
| Multi-hop queries | No | No | No | No | No | Yes — native |
| Graph traversal | No | No | No | No | No | Yes — native |
| Hybrid search | No | Partial | Yes | Yes | Yes | Yes |
| Operational complexity | Low (no ops) | Low | Medium | High | Zero | Medium |
| Best for | Research | Simple RAG | Doc workloads | Billion-scale | Zero-ops | Relational AI |
| Avoid when | Production | Over 100M | Pure vector | Small scale | Data residency | Simple lookups |
Closing Thought
The 2026 vector database landscape has matured to the point where the question "which is best?" has a clear answer: none of them, universally.
FAISS is best for in-memory research. pgvector is best for co-located simplicity under 50 million vectors. MongoDB is best for document-native applications. Milvus is best for billion-scale. Pinecone is best for zero-ops managed deployment. Neo4j is best for relational reasoning, multi-hop queries, and graph-structured knowledge.
The teams that get this decision right are not the ones who found the best benchmark. They are the ones who accurately characterized their query distribution — specifically, the fraction of their user queries that require relational reasoning versus pure semantic similarity — and selected the architecture that matches it.
If your queries are mostly single-hop semantic lookups: any good vector database works. The operational and cost factors dominate the decision.
If a meaningful fraction of your queries require understanding how entities connect: Neo4j is not one option among several. It is the only option that handles those queries correctly. Everything else returns a fluent but structurally wrong answer.
Know your queries. Then choose your store.
Research Sources
- FutureAGI — Vector Databases and Knowledge Graphs for RAG in 2026. May 14, 2026. Neo4j as default for property-graph workloads, converged hybrid pattern.
- AgentMarketCap — Graph RAG vs Vector RAG for Agent Memory 2026. April 7, 2026. MultiHopRAG 11-point improvement. LongMemEval 63.8 vs 49.0 percent. DMR 94.8 vs 93.4 percent. 2.3x latency overhead. 13.4 percent underperformance on single-hop.
- MarkTechPost — Best Vector Databases in 2026: Pricing, Scale Limits, and Architecture Tradeoffs. May 10, 2026. Weaviate hybrid search architecture. Pricing analysis.
- Firecrawl — Best Vector Databases in 2026: A Complete Comparison Guide. May 27, 2026. pgvectorscale 471 QPS at 99 percent recall on 50M vectors. HNSW architecture.
- Encore — Best Vector Databases in 2026: Complete Comparison Guide. March 9, 2026. pgvector SQL join advantage. Scale ceiling analysis.
- BuildMVPFast — GraphRAG vs Vector RAG: Knowledge Graph AI Guide 2026. March 18, 2026. LazyGraphRAG cost analysis. Neo4j LangChain integration.
- DEV Community — Stop Using Raw Vector Search: Implement GraphRAG with Spring AI and Neo4j. May 21, 2026. Double-query latency problem. Hybrid pipeline architecture.
- Qdrant — GraphRAG with Qdrant and Neo4j. Official documentation. Two-system hybrid pattern. Improved recall and precision.
- AltexSoft — How to Choose the Right Vector Database. March 31, 2026. FAISS GPU acceleration benchmark. Database vs library comparison.
- LakeFS — Best 17 Vector Databases for 2026. January 21, 2026. Open-source landscape. Milvus billion-scale positioning.
- Medium — Vector Database Comparison for AI Developers. May 2025. FAISS, Pinecone, Weaviate, Milvus, Neo4j feature comparison.
- Neo4j Blog — Knowledge Graph vs Vector RAG: Benchmarking, Optimization Levers. June 2024. Graph and vector system complementarity.
- Educative — Vector Search on Knowledge Graph in Neo4j. February 2025. Cypher traversal with vector similarity on node embeddings.
Top comments (0)