Vector Databases Compared: pgvector vs Pinecone vs Weaviate vs Qdrant

Introduction

Picking the wrong vector database locks you into operational pain. Picking the right one disappears into your stack and lets you focus on building features. The choice has real consequences for cost at scale, latency, operational overhead, and architectural flexibility.

This comparison covers the four vector DBs we use most often — pgvector, Pinecone, Weaviate, and Qdrant — across the criteria that actually matter at production scale. We'll cover where each wins, where each loses, the specific scale and performance characteristics, and the decision framework we use with clients.

If you're starting a project that needs vector search, this post will save you from the most common architecture mistake: picking a dedicated vector DB when Postgres would do.

pgvector: the default when Postgres is in your stack

pgvector is a Postgres extension that adds vector similarity search. The killer feature is operational simplicity — you already run Postgres, you already have backups and monitoring, and you can query vectors alongside relational data.

Where it wins

• Operational simplicity: One database, one backup strategy, one monitoring stack.
• Hybrid queries: Join vector search results with structured data in a single SQL query.
• Cost: Effectively free (Postgres cost only).
• Familiarity: Your team knows Postgres. Operational risk is low.

Scale characteristics

With HNSW indexing on Postgres 16+:

• Up to 10M vectors: Latency stays under 50ms at modest QPS on standard Postgres hardware.
• 10-50M vectors: Latency stays under 100ms with appropriate hardware and index tuning.
• 50-100M vectors: Performance starts to degrade. Hardware needs to scale up. Operational complexity grows.
• 100M+ vectors: pgvector struggles. Time to consider dedicated vector DB.

Where it loses

• Scaling past 50-100M vectors gets painful.
• Pure vector search performance can't match dedicated systems at very high QPS.
• Hybrid keyword + vector search is more work to set up than dedicated systems with built-in hybrid search.

Pinecone: managed simplicity at scale

Pinecone is the managed default. Excellent at scale, good documentation, the API is straightforward. The trade-off is cost and vendor lock-in.

Where it wins

• Zero operational overhead: Fully managed. Scales reliably without intervention.
• Hybrid search built-in: Vector + keyword search in a single query.
• Excellent scale characteristics: Handles 100M+ vectors with consistent sub-50ms latency.
• Strong filtering: Metadata filtering doesn't kill performance.
• Multi-tenancy ready: Per-tenant namespace support out of the box.

Where it loses

• Cost grows with scale. At 100M+ vectors, monthly bills are significant.
• SaaS-only. No self-hosted option. Data residency or compliance constraints can rule it out.
• Vendor lock-in. Pinecone-specific APIs make migration to alternatives costly.
• Limited query flexibility. Less expressive than SQL for complex queries that combine vector + structured filters.

Weaviate: feature-rich open source

Weaviate is the most feature-rich open vector DB. Built-in modules for various embedding models, GraphQL API, strong hybrid search story, self-hostable for data residency.

Where it wins

• Strong hybrid search: BM25 + vector with sensible defaults.
• Rich query capabilities: GraphQL API, generative search, reranking modules.
• Open source license: Can self-host for data residency or cost.
• Module ecosystem: Built-in support for various embedding models, reranking, generative search.

Where it loses

• Operational complexity at scale. Multi-node clusters take real engineering investment.
• Memory-heavy: Higher infrastructure cost than Qdrant for equivalent data volume.
• GraphQL API: Mixed reception. Some teams love it; others find it adds complexity.
• Smaller managed ecosystem: Weaviate Cloud exists but less mature than Pinecone.

Qdrant: performance-focused open source

Qdrant has emerged as the performance leader among open vector DBs. Rust implementation, strong filtering, lower memory footprint than alternatives. Both self-hosted and managed (Qdrant Cloud) options.

Where it wins

• Performance: Fast queries at high QPS. Rust implementation pays off.
• Strong filtering: Pre-filter, post-filter, hybrid filter modes all perform well.
• Memory efficiency: Better than Weaviate for equivalent data volume.
• Reasonable operational footprint: Easier to run than Weaviate at scale.
• Open source + managed: Qdrant Cloud for teams that want managed.

Where it loses

• Smaller ecosystem: Newer than Pinecone or Weaviate. Fewer integrations, fewer tutorials.
• Fewer battle-tested production references: Catching up but not yet at the level of Pinecone.
• Less feature-rich than Weaviate: No built-in generative search or reranking modules.

Side-by-side comparison

Quick reference across the dimensions that matter:

• Operational complexity: pgvector (none, you already run Postgres) → Pinecone (none, managed) → Qdrant (moderate) → Weaviate (moderate-high).
• Scale limit: pgvector (50-100M) → Qdrant/Weaviate (1B+) → Pinecone (1B+).
• Cost at 100M vectors: pgvector (cheapest) → Qdrant self-hosted → Weaviate self-hosted → Pinecone (most expensive).
• Cost at 10M vectors: pgvector (effectively free) → others (significant).
• Hybrid search ergonomics: pgvector (manual) → Qdrant → Weaviate (strongest) → Pinecone.
• Self-hosted option: pgvector (yes) → Weaviate (yes) → Qdrant (yes) → Pinecone (no).
• Data residency / compliance: pgvector → Qdrant → Weaviate → Pinecone.

Our recommendation framework

When deciding for a specific project:

• Start with pgvector if Postgres is in your stack. Default answer for most projects under 50M vectors.
• Use Pinecone if you need managed simplicity at scale and SaaS is acceptable.
• Use Qdrant when you want open source with strong performance. Self-hosted is fine.
• Use Weaviate when you need rich features (generative search, reranking modules, GraphQL).
• Don't change vector DBs unless your current one is the actual bottleneck. Migration costs are real.

Migration realities

If you do need to migrate between vector DBs, the considerations:

• Embeddings are portable. The vectors themselves work across systems.
• Index types differ. Performance characteristics vary; re-tuning is needed.
• Hybrid search semantics differ. If your queries use vendor-specific hybrid search, those queries need to be rewritten.
• Metadata filtering syntax differs. Same logical filters, different syntax.
• Operational tooling changes. Monitoring, alerting, backup strategies all need to be re-established.

Total migration effort: typically 4-12 weeks depending on scale and complexity.

Conclusion

Default to pgvector. Move to a dedicated vector DB only when you have a specific reason. The most common architecture mistake we see is teams reaching for Pinecone or Weaviate when Postgres would handle their workload at a fraction of the cost and complexity.

When you do need to move, pick by scale needs, hybrid search requirements, hosting constraints, and cost characteristics. There's no universally right answer, but there are clearly wrong answers — and the framework above helps you avoid them.

If you're evaluating vector DBs for a project, we've shipped all four in production. Happy to walk through which fits your specific scale, latency, and operational profile.