Graph databases find connections. Vector databases find similarities. When to use which, real benchmarks, and why PostgreSQL might replace both.
Get new posts delivered to your inbox. No spam, unsubscribe anytime.
UnitedHealth Group tracks 120 billion relationships among members, providers, claims, visits, and prescriptions for 26 million patients -- in a graph database. Pinecone handled 2 million queries per second on Black Friday for an e-commerce client with 43ms average latency -- in a vector database. Same industry (loosely). Same scale ambitions. Completely different data structures, completely different problems being solved. And yet I keep seeing teams agonize over "should we use a graph database or a vector database?" as if they're interchangeable options on a dropdown menu.
They're not. They solve fundamentally different problems. But the AI hype cycle has mashed them together because both showed up in the same architecture diagrams for RAG and agentic AI systems. The vector database market hit $2.55 billion in 2025. The graph database market sits at roughly $2.85 billion. Both are growing at 24-28% CAGR. Both claim to be essential for AI. One of them might be slowly dying as a standalone category.
I've built systems with both. I've also built RAG pipelines and Graph RAG systems that use them together. Here's everything I wish someone had told me before I wasted two months on the wrong choice.
A vector database stores numbers. Specifically, it stores high-dimensional embedding vectors -- numerical representations of text, images, or any data -- and finds the most similar ones fast. When you ask "what documents are similar to this question?", a vector database answers by comparing mathematical distances between points in high-dimensional space.
A graph database stores relationships. It models data as nodes (entities) and edges (connections between them) and excels at traversing those connections. When you ask "how is person A connected to person B through three intermediaries?", a graph database walks the relationship path.
| Dimension | Vector Database | Graph Database |
|---|---|---|
| Stores | High-dimensional embeddings (numbers) | Nodes and edges (entities + relationships) |
| Answers | "What's most similar to X?" | "How are X and Y connected?" |
| Query type | Nearest neighbor search (ANN) | Graph traversal (BFS, DFS, path finding) |
| Data model | Flat -- vectors with metadata | Structured -- explicit relationships |
| Best for | Unstructured data (text, images, audio) | Structured relationships (networks, hierarchies) |
| Latency | 7-50ms for similarity search | Varies -- fast for traversals, slower for aggregations |
| Core algorithm | HNSW, IVF, PQ | Cypher, Gremlin, SPARQL |
| Primary language | Python SDKs, REST APIs | Cypher (Neo4j), Gremlin (Neptune) |
Here's the simplest mental model: vector databases find things that look alike. Graph databases find things that connect.
Both markets are growing fast, but the stories underneath the numbers are different.
Vector databases:
Graph databases:
The graph database market is slightly larger today and growing slightly faster. But here's the twist: the vector database market faces an existential threat that graph databases don't. More on that in a minute.
Let me give vector databases their due. For semantic search over unstructured data, nothing beats them.
# Vector database in action: semantic search
from qdrant_client import QdrantClient
from sentence_transformers import SentenceTransformer
model = SentenceTransformer("all-MiniLM-L6-v2")
client = QdrantClient(url="http://localhost:6333")
# Embed a query
query_vector = model.encode("How do I handle customer refunds?")
# Find the 5 most similar documents
results = client.search(
collection_name="support_docs",
query_vector=query_vector,
limit=5
)
# Returns documents ranked by cosine similarity
The performance numbers are impressive. Redis benchmarks show the leading vector databases handling millions of vectors at sub-50ms latency:
| Database | Relative QPS | p99 Latency | Recall |
|---|---|---|---|
| Redis | Baseline (fastest) | Baseline | 0.98+ |
| Qdrant | 3.4x lower | ~40ms | 0.98+ |
| Weaviate | 1.7x lower | ~50-70ms | 0.98+ |
| pgvector (Aurora) | 9.5x lower | Higher | 0.98+ |
| MongoDB Atlas | 11x lower | Higher | 0.82 max |
Where vector databases shine:
Production adoption is real. Pinecone powers Microsoft, Shopify, Notion, and Zapier. Milvus runs at Salesforce, PayPal, IKEA, and Walmart. Qdrant serves Discord and Johnson & Johnson. These aren't experiments -- they're production systems handling real traffic.
Graph databases solve a different class of problems. Problems where the relationships between things matter more than the things themselves.
-- Graph database in action: find fraud rings (Neo4j Cypher)
MATCH (a:Account)-[:TRANSFERRED_TO]->(b:Account)-[:TRANSFERRED_TO]->(c:Account)
WHERE a.flagged = true
AND c.opened_date > date() - duration({days: 30})
RETURN a, b, c,
[(a)-[r:TRANSFERRED_TO]->(b) | r.amount] AS amounts
Try doing that with a vector database. You can't. There's no concept of "follow this path from A to B to C" in vector space. Vector search finds similar documents -- it doesn't traverse relationship chains.
Where graph databases shine:
Fraud detection. eBay uses knowledge graphs for product data. Financial institutions map transaction networks to find circular money flows. One e-commerce company discovered 12 million new account connections across 5 websites and saved ~$3 million in fraud losses.
Social networks. Facebook, LinkedIn, Twitter, Instagram -- all built on graph databases. The core question "who is connected to whom, and how?" is a graph problem.
Supply chain. A global automaker runs 50,000+ product availability checks daily on its graph, reducing capacity planning time by 50% and human decision points by 60%.
Healthcare. UnitedHealth's 120 billion relationships across 26 million members. Connections between members, providers, claims, visits, prescriptions -- every one of these is a relationship that a graph models natively.
Knowledge graphs for AI. This is the fastest-growing use case. Structuring organizational knowledge as a graph so AI can reason over it. Not just "find similar documents" but "trace the reasoning path from question to answer."
The real fight between graph and vector databases is happening in the RAG space. And the benchmarks are damning for vector-only approaches.
FalkorDB and Diffbot benchmarked vector RAG against Graph RAG on enterprise queries:
| Metric | Vector RAG | Graph RAG | Difference |
|---|---|---|---|
| Accuracy on knowledge-intensive queries | 56.2% | 90%+ | 3.4x improvement |
| Accuracy with 5+ entities per query | ~0% | Stable | Vector collapses |
| Factual correctness (hybrid GraphRAG) | Baseline | +8% | Neo4j benchmark |
That middle row is the killer stat. Vector RAG accuracy drops to essentially zero when queries involve more than 5 entities. The moment a question requires connecting multiple pieces of information -- "Which suppliers in region X are affected by regulation Y and supply products to our top 10 customers?" -- vector search falls apart. It can find documents mentioning suppliers. It can find documents about regulations. It can't connect them.
Graph RAG sustains stable performance even with 10+ entities per query because it's designed to traverse relationships. That's the fundamental architectural difference.
But here's what the Graph RAG evangelists don't tell you: vector RAG is still better for single-hop factual lookups. "What's our refund policy?" -- vector search nails this faster and cheaper than building a knowledge graph. The complexity of graph-based retrieval isn't justified for simple questions that sit in a single document chunk.
I wrote a whole article about Graph RAG if you want the deep technical breakdown. The short version: graph wins on multi-hop reasoning, vector wins on simple similarity, hybrid wins overall.
Here's the trend that makes the "graph vs vector" framing increasingly outdated: they're merging.
Neo4j added vector search. The leading graph database now supports native vector similarity search alongside its graph traversal capabilities. You can store embeddings on graph nodes and combine semantic search with relationship traversal in a single query.
Weaviate added graph capabilities. The vector database now supports knowledge graph patterns and graph-based retrieval alongside its vector search.
TigerGraph launched TigerVector. Version 4.2 (December 2024) integrated vector search into the graph database and demonstrated comparable or higher performance than specialized vector databases.
PostgreSQL does both. With pgvector for embeddings and Apache AGE for graph queries, PostgreSQL is becoming the Swiss Army knife. And this matters because Snowflake and Databricks spent ~$1.25 billion acquiring PostgreSQL-first companies in 2024-2025.
The convergence trend has led some analysts to declare that standalone vector databases are dying. The argument: vectors are a data type, not a database type. Every major database (PostgreSQL, MongoDB, Oracle, Snowflake, Databricks) now supports vector search as a built-in feature. Why run a separate Pinecone instance when your PostgreSQL can do vector search?
I think the "vector databases are dead" take is premature but directionally correct. For most teams, especially those already using PostgreSQL, pgvector eliminates the need for a separate vector database. pgvectorscale achieves 28x lower latency than Pinecone s1 at 99% recall. But at massive scale -- billions of vectors, sub-10ms latency requirements -- purpose-built vector databases like Qdrant and Milvus still have clear performance advantages.
Every "graph vs vector" article online gives you a surface-level comparison. Here's the one with actual specifics.
| Criteria | Vector Database (e.g., Qdrant) | Graph Database (e.g., Neo4j) | PostgreSQL + extensions |
|---|---|---|---|
| Similarity search speed | Excellent (30-50ms at scale) | Poor (not designed for it) | Good (pgvector, ~100ms) |
| Relationship traversal | Impossible | Excellent (native capability) | Possible but awkward (recursive CTEs) |
| Multi-hop reasoning | Fails beyond 5 entities | Excels at arbitrary depth | Limited |
| RAG accuracy (simple queries) | High (~68% F1) | Overkill | High |
| RAG accuracy (complex queries) | Collapses (~0% at 5+ entities) | Stable (90%+) | Moderate |
| Setup complexity | Low (managed services available) | Medium (schema design required) | Low (extension install) |
| Cost at 1M records | $30-300/month | $50-500/month | $0-80/month (on existing Postgres) |
| Team skills needed | Python, embedding models | Cypher/Gremlin, graph modeling | SQL (already known) |
| Vendor lock-in risk | High (proprietary APIs) | Medium (Cypher is Neo4j-specific) | Low (PostgreSQL is open) |
| Scaling to billions | Purpose-built for this | Challenging (scalability ceiling) | Challenging (pgvector slows) |
Wrong #1: "Choose one." The most common framing is "graph database OR vector database." In practice, the best AI systems use both. Vector search for initial retrieval, graph traversal for relationship reasoning, combined in a hybrid pipeline. This isn't a "pick one" decision for serious production systems.
Wrong #2: "Graph databases are slower." Graph databases are slower at similarity search. They're dramatically faster at relationship queries. Comparing them on similarity search is like comparing a boat to a car on highway speed. You're measuring the wrong thing.
Wrong #3: "Vector databases handle relationships through metadata filtering." I've seen this claim in vendor marketing. It's technically true and practically useless. You can tag vectors with metadata like department: "engineering" and filter on it. That's not a relationship -- that's a flat attribute. You can't follow multi-hop paths through metadata filters. The moment you need "find all people who report to someone who reports to the CEO," metadata filtering collapses.
Wrong #4: "You need a graph database for RAG." You don't. Most RAG systems work fine with vector search alone. You need a graph database when your RAG system must answer questions that require connecting information across multiple documents or entities. That's a subset of RAG use cases -- an important one, but not the default.
Wrong #5: "pgvector is good enough for everyone." It's good enough for most teams. But at scale, purpose-built vector databases outperform it significantly. The Redis benchmarks show pgvector at 9.5x lower QPS than Redis for vector search. If you're serving millions of queries per second, "good enough" isn't good enough.
After building systems with both, here's how I decide.
This covers 70% of teams. Seriously. Don't overthink it.
Most teams stop at step 1 or 2. That's fine. Don't add complexity you don't need.
Vector databases in production are easy. Managed services (Pinecone, Weaviate Cloud, Qdrant Cloud) handle scaling, backups, and infrastructure. You embed your data, push it in, query it. The learning curve is days, not weeks. Companies report 40-60% faster resolution times when support agents have semantic access to knowledge bases.
Graph databases in production are hard. Schema design matters enormously. Poor graph modeling leads to slow queries and confusing results. You need someone who understands graph theory, Cypher or Gremlin, and your domain well enough to model relationships correctly. The scalability ceiling is real -- most graph databases handle hundreds to thousands of queries per second, not millions. And data quality issues compound across graph traversals in ways they don't in flat vector search.
The hidden cost of both: the engineering time to maintain them. Vector databases need regular re-embedding when your embedding model changes. Graph databases need constant curation as relationships evolve. Neither is "set it and forget it." The team that thinks they're buying a database is actually committing to an ongoing data engineering practice.
If you're a solo developer or small team, vector search on PostgreSQL gives you 80% of the value at 20% of the complexity. The people who need Neo4j know they need Neo4j -- their data is screaming "I'm a graph" at them. If your data isn't screaming that, it probably isn't.
The "graph vs vector" framing is already obsolete. We're heading toward a world where every database does both, and the question becomes how well it does each.
PostgreSQL is winning. It's the most popular database among professional developers, it turns 40 in 2026, and it now handles vectors (pgvector), graphs (Apache AGE), full-text search, JSON, time-series, and geospatial data. The fact that Snowflake and Databricks spent $1.25 billion acquiring PostgreSQL companies tells you where the market is heading.
Standalone vector databases have a shrinking window. Right now, Qdrant, Pinecone, and Milvus outperform pgvector at scale. But pgvector is improving fast. pgvectorscale already beats Pinecone on latency at 99% recall. Give it two more years and the performance gap may not justify a separate database for most teams.
Graph databases have a more durable moat. Relationship traversal is fundamentally hard to bolt onto a relational or vector database. Neo4j's Cypher query language, its graph storage engine, and its community detection algorithms aren't things you replicate with a PostgreSQL extension. Graph databases will survive as a standalone category longer than vector databases will.
The real question isn't "graph or vector." It's "what shape is my data, and what questions do my users ask?" If your data is unstructured text and your users ask similarity questions, vectors. If your data has rich relationships and your users ask connection questions, graphs. If both (and it's increasingly both), then build a hybrid system -- vector for retrieval, graph for reasoning.
And if you're just starting out? Use PostgreSQL. Add pgvector. Build your RAG pipeline. Measure what breaks. Then -- and only then -- reach for a specialized database. The worst architectural decision is optimizing for problems you don't have yet.
The data engineering skills needed to work with both paradigms are becoming essential. The SQL fundamentals you already know transfer directly to graph query languages. And the AI engineer role increasingly requires understanding when to use which data store. Learn both. Start with the simpler one.