Pinecone vs Weaviate vs Qdrant vs pgvector: Vector Database Showdown
We benchmarked four vector databases on latency, accuracy, scalability, and cost. Here's which one fits your RAG pipeline and why pgvector might surprise you.

Vector databases are the backbone of RAG pipelines, semantic search, and AI-powered recommendations. The four leading options - Pinecone, Weaviate, Qdrant, and pgvector - take different approaches to the same problem. We benchmarked all four to help you choose.
Quick verdict
| Database | Best for | Avoid if |
|---|---|---|
| Pinecone | Managed simplicity, enterprise scale | Budget-constrained, self-hosting required |
| Weaviate | Hybrid search, complex queries | You need maximum raw speed |
| Qdrant | Performance-critical, self-hosting | You want zero ops overhead |
| pgvector | Postgres shops, moderate scale | High-volume semantic search |
Our recommendation: Start with pgvector if you're already using Postgres - the operational simplicity outweighs performance differences for most use cases. Move to Qdrant for performance-critical applications or Pinecone when you need managed scale without ops burden.
"Integration capability is becoming more important than feature depth. The best tools are the ones that play well with your existing stack." - Dharmesh Shah, Co-founder at HubSpot
Test methodology
We benchmarked each database using:
- Dataset: 1M, 10M, and 100M vectors (1536 dimensions, OpenAI embeddings)
- Queries: 10,000 search queries with varying top-k values
- Metrics: Latency (p50, p95, p99), recall@10, throughput, cost
- Hardware: Comparable cloud instances for self-hosted options
All tests run September 2025 with latest stable versions.
Pinecone
Overview
Pinecone is a fully managed vector database designed for production AI applications. You get a serverless API without infrastructure management.
Architecture
Pinecone uses a proprietary distributed architecture optimised for vector search:
import { Pinecone } from '@pinecone-database/pinecone';
const pinecone = new Pinecone({ apiKey: process.env.PINECONE_API_KEY });
const index = pinecone.index('my-index');
// Upsert vectors
await index.namespace('documents').upsert([
{
id: 'doc-1',
values: embedding,
metadata: { title: 'Example', category: 'tech' }
}
]);
// Query
const results = await index.namespace('documents').query({
vector: queryEmbedding,
topK: 10,
filter: { category: { $eq: 'tech' } },
includeMetadata: true
});Strengths
Zero ops: No servers to manage, no scaling to configure. It just works.
Global distribution: Multi-region replication with automatic failover.
Metadata filtering: Efficient filtered vector search without separate queries.
Enterprise features: SOC2, HIPAA, dedicated clusters for compliance needs.
Weaknesses
Cost at scale: Serverless pricing can surprise you. High-volume workloads get expensive.
Vendor lock-in: Proprietary API and infrastructure. Migration requires re-indexing.
Limited query flexibility: Pure vector search with metadata filters. No hybrid text search.
Cold start latency: Serverless indexes can have startup delays after idle periods.
Benchmark results
| Dataset size | Query latency (p50) | Query latency (p99) | Recall@10 |
|---|---|---|---|
| 1M vectors | 12ms | 45ms | 98.2% |
| 10M vectors | 18ms | 72ms | 97.8% |
| 100M vectors | 28ms | 110ms | 97.1% |
Pricing
| Tier | Monthly cost | Notes |
|---|---|---|
| Starter | Free | 100K vectors, 5M reads |
| Standard (serverless) | ~$70/1M vectors | Pay per operation |
| Enterprise | Custom | Dedicated infrastructure |
Serverless pricing: $0.00002 per read unit, $2 per write unit.
Weaviate
Overview
Weaviate is an open-source vector database with built-in machine learning modules. It emphasises hybrid search combining vectors with keyword matching.
Architecture
Weaviate uses a schema-based approach with native support for multiple search types:
import weaviate from 'weaviate-ts-client';
const client = weaviate.client({
scheme: 'https',
host: 'your-cluster.weaviate.network'
});
// Define schema
await client.schema
.classCreator()
.withClass({
class: 'Document',
vectorizer: 'text2vec-openai',
properties: [
{ name: 'title', dataType: ['text'] },
{ name: 'content', dataType: ['text'] }
]
})
.do();
// Hybrid search (vector + keyword)
const results = await client.graphql
.get()
.withClassName('Document')
.withHybrid({ query: 'machine learning', alpha: 0.5 })
.withLimit(10)
.withFields('title content _additional { score }')
.do();Strengths
Hybrid search: Native combination of vector and keyword search with configurable weighting.
Built-in vectorisation: Automatic embedding generation with OpenAI, Cohere, HuggingFace modules.
GraphQL API: Flexible query language for complex retrieval patterns.
Open source: Self-host for data sovereignty or use managed Weaviate Cloud.
Weaknesses
Complexity: More configuration required than simpler alternatives.
Memory usage: Higher RAM requirements than Qdrant or pgvector.
Query latency: Not the fastest for pure vector search.
Learning curve: Schema design and GraphQL require upfront investment.
Benchmark results
| Dataset size | Query latency (p50) | Query latency (p99) | Recall@10 |
|---|---|---|---|
| 1M vectors | 22ms | 85ms | 97.6% |
| 10M vectors | 38ms | 145ms | 96.9% |
| 100M vectors | 62ms | 220ms | 95.8% |
Hybrid search adds 15-30ms depending on keyword component complexity.
Pricing (Weaviate Cloud)
| Tier | Monthly cost | Notes |
|---|---|---|
| Sandbox | Free | 50K vectors, development only |
| Standard | From $25/month | Production workloads |
| Enterprise | Custom | SLAs, dedicated support |
Self-hosting: Infrastructure costs only (typically $200-500/month for production).
Qdrant
Overview
Qdrant is a high-performance open-source vector database written in Rust. It prioritises speed and efficiency for production deployments.
Architecture
Qdrant uses a segment-based architecture optimised for fast approximate nearest neighbor search:
import { QdrantClient } from '@qdrant/js-client-rest';
const client = new QdrantClient({ url: 'http://localhost:6333' });
// Create collection
await client.createCollection('documents', {
vectors: { size: 1536, distance: 'Cosine' },
optimizers_config: { indexing_threshold: 10000 }
});
// Upsert
await client.upsert('documents', {
points: [
{
id: 'doc-1',
vector: embedding,
payload: { title: 'Example', category: 'tech' }
}
]
});
// Search with filtering
const results = await client.search('documents', {
vector: queryEmbedding,
limit: 10,
filter: {
must: [{ key: 'category', match: { value: 'tech' } }]
}
});Strengths
Performance: Fastest pure vector search in our benchmarks. Rust implementation minimises overhead.
Memory efficiency: Quantisation and on-disk storage options reduce RAM requirements.
Filtering: Rich filtering with JSON-like payload queries.
Self-hosting friendly: Docker deployment with horizontal scaling.
Weaknesses
No hybrid search: Vector-only queries. Keyword search requires external solution.
Managed option newer: Qdrant Cloud is less mature than Pinecone's managed offering.
Smaller ecosystem: Fewer integrations and community resources than Weaviate.
Benchmark results
| Dataset size | Query latency (p50) | Query latency (p99) | Recall@10 |
|---|---|---|---|
| 1M vectors | 8ms | 28ms | 98.4% |
| 10M vectors | 14ms | 52ms | 98.0% |
| 100M vectors | 24ms | 95ms | 97.4% |
Qdrant was consistently fastest across all dataset sizes.
Pricing (Qdrant Cloud)
| Tier | Monthly cost | Notes |
|---|---|---|
| Free | $0 | 1GB storage, development |
| Starter | From $25/month | Production, auto-scaling |
| Enterprise | Custom | Dedicated clusters |
Self-hosting: Infrastructure costs only (typically $100-300/month for production).
pgvector
Overview
pgvector is a Postgres extension adding vector similarity search. It's not a standalone database but enhances your existing Postgres deployment.
Architecture
pgvector adds vector types and indexes to standard Postgres:
-- Enable extension
CREATE EXTENSION vector;
-- Create table with vector column
CREATE TABLE documents (
id SERIAL PRIMARY KEY,
title TEXT,
content TEXT,
embedding vector(1536)
);
-- Create HNSW index for fast search
CREATE INDEX ON documents
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);
-- Query
SELECT id, title, embedding <=> $1 AS distance
FROM documents
WHERE category = 'tech'
ORDER BY embedding <=> $1
LIMIT 10;TypeScript with Supabase:
const { data } = await supabase.rpc('match_documents', {
query_embedding: embedding,
match_threshold: 0.8,
match_count: 10
});Strengths
No new infrastructure: Use your existing Postgres. One less service to manage.
Full SQL power: Join vectors with relational data, complex queries, transactions.
Ecosystem: Works with all Postgres tooling - ORMs, migrations, backups.
Cost effective: No additional database costs if you're already running Postgres.
Weaknesses
Scale limits: Performance degrades faster than purpose-built vector DBs at high scale.
Resource competition: Vector queries compete with other Postgres workloads.
Indexing time: HNSW index builds are slow for large datasets.
Memory requirements: Indexes must fit in RAM for optimal performance.
Benchmark results
| Dataset size | Query latency (p50) | Query latency (p99) | Recall@10 |
|---|---|---|---|
| 1M vectors | 15ms | 55ms | 97.8% |
| 10M vectors | 35ms | 130ms | 96.5% |
| 100M vectors | 85ms | 350ms | 94.2% |
pgvector performed well at moderate scale but showed steeper degradation at 100M vectors.
Pricing
| Option | Monthly cost | Notes |
|---|---|---|
| Self-hosted | Infrastructure only | Your existing Postgres |
| Supabase | From $25/month | Managed Postgres with pgvector |
| Neon | From $19/month | Serverless Postgres |
| AWS RDS | From $50/month | Managed Postgres |
Head-to-head comparison
Performance summary
| Database | 1M p50 | 10M p50 | 100M p50 | Recall@10 (10M) |
|---|---|---|---|---|
| Pinecone | 12ms | 18ms | 28ms | 97.8% |
| Weaviate | 22ms | 38ms | 62ms | 96.9% |
| Qdrant | 8ms | 14ms | 24ms | 98.0% |
| pgvector | 15ms | 35ms | 85ms | 96.5% |
Qdrant is fastest. Pinecone offers the best balance of speed and managed simplicity. pgvector is competitive at moderate scale.
Feature comparison
| Feature | Pinecone | Weaviate | Qdrant | pgvector |
|---|---|---|---|---|
| Managed option | Yes | Yes | Yes | Via Supabase/Neon |
| Self-hosting | No | Yes | Yes | Yes |
| Hybrid search | No | Yes | No | With pg_trgm |
| Metadata filtering | Yes | Yes | Yes | SQL WHERE |
| Replication | Yes | Yes | Yes | Postgres native |
| Transactions | No | No | No | Yes |
| SQL joins | No | GraphQL | No | Yes |
| Quantisation | Yes | Yes | Yes | Limited |
Cost at scale (10M vectors, 100K queries/day)
| Database | Monthly cost | Notes |
|---|---|---|
| Pinecone (serverless) | ~$260 | $70 storage + operations |
| Weaviate Cloud | ~$200 | Depends on instance size |
| Qdrant Cloud | ~$150 | Depends on instance size |
| Qdrant (self-hosted) | ~$200 | c6a.xlarge on AWS |
| pgvector (Supabase) | ~$75 | Pro plan with adequate compute |
| pgvector (self-hosted) | ~$150 | db.r6g.large on RDS |
pgvector is most cost-effective. Dedicated vector databases cost more but deliver better performance at scale.
Use case recommendations
You're already using Postgres
Winner: pgvector
Don't add complexity. pgvector handles most RAG workloads without a new service. Only move to a dedicated vector DB when you hit scale limits.
Maximum performance required
Winner: Qdrant
For latency-sensitive applications (real-time recommendations, search typeahead), Qdrant's raw speed is unmatched.
Zero ops, enterprise scale
Winner: Pinecone
When you need to scale to billions of vectors without managing infrastructure, Pinecone's managed service is the simplest path.
Hybrid search (vector + keyword)
Winner: Weaviate
Native hybrid search with configurable weighting. Essential when keyword relevance matters alongside semantic similarity.
Budget-constrained startup
Winner: pgvector on Supabase
Most affordable option with good enough performance. Scale up when you have revenue.
Multi-modal embeddings
Winner: Qdrant or Weaviate
Both handle varying vector dimensions. Pinecone and pgvector are less flexible with mixed embedding sizes.
Migration considerations
From pgvector to Qdrant
When pgvector hits scale limits:
// Export from Postgres
const vectors = await db.query(`
SELECT id, embedding, metadata
FROM documents
`);
// Import to Qdrant
await qdrantClient.upsert('documents', {
points: vectors.rows.map(row => ({
id: row.id,
vector: row.embedding,
payload: row.metadata
}))
});From Pinecone to self-hosted
For cost reduction at scale:
// Export from Pinecone
const vectors = await pineconeIndex.fetch(ids);
// Import to Qdrant
await qdrantClient.upsert('documents', {
points: Object.entries(vectors.records).map(([id, record]) => ({
id,
vector: record.values,
payload: record.metadata
}))
});Migration typically requires re-indexing. Plan for downtime or parallel operation during transition.
Our verdict
For most teams building their first RAG pipeline, pgvector is the right starting point. It eliminates operational complexity and performs well at typical startup scale (sub-10M vectors).
As you scale, Qdrant offers the best performance per dollar for self-hosted deployments. Pinecone is the right choice if you need enterprise scale without ops investment.
Weaviate fills a specific niche: applications requiring native hybrid search. If keyword relevance matters alongside semantic similarity, Weaviate's approach is more elegant than bolting keyword search onto a vector-only database.
The "best" vector database depends on your constraints. Start simple, measure performance, and migrate when you have data showing you need more.
---
Further reading:
- /blog/pinecone-vs-weaviate-vs-qdrant-vector-databases
- /blog/complete-guide-rag-retrieval-augmented-generation-ai-agents
- pgvector Documentation
- Qdrant Documentation
- Pinecone Documentation
- Weaviate Documentation
---
Frequently Asked Questions
Q: When should I switch tools versus optimise current ones?
Switch when the tool fundamentally can't support your requirements, is becoming unsupported, or is significantly limiting growth. Optimise first when pain points are process-related rather than capability-related.
Q: How do I evaluate total cost of ownership?
Beyond subscription costs, factor in implementation time, training needs, integration work, ongoing maintenance, and the cost of switching if the tool doesn't work out. The cheapest option rarely has the lowest total cost.
Q: How do I choose between similar tools?
Focus on your specific use case and workflow requirements, not comprehensive feature lists. Trial multiple options with real work, involve your team in evaluation, and weight integration capabilities heavily.
More from the blog
OpenHelm vs runCLAUDErun: Which Claude Code Scheduler Is Right for You?
A direct comparison of the two most popular Claude Code schedulers, how each works, what each costs, and which fits your workflow.
Claude Code vs Cursor Pro: Real Developer Cost Comparison
An honest look at what developers actually spend on Claude Code, Cursor Pro, and GitHub Copilot, and how to get the most from each.