Vector database landscape: when you need them vs PostgreSQL

Vector databases are designed for similarity search on embeddings—turning unstructured data like text, images, or audio into searchable numeric vectors. They support operations like nearest neighbor search (kNN) with speed and scale that relational databases can’t match natively.
You need a dedicated vector DB when:
- Dataset size exceeds millions of embeddings.
- Latency requirements are <100ms for real-time apps (e.g., chatbots, RAG, semantic search).
- You need advanced indexing (HNSW, IVF, PQ) for optimized retrieval.
PostgreSQL with pgvector is sufficient when:
- Dataset < a few million vectors.
- You already use Postgres and want a simple extension.
- Low to medium QPS (queries per second) is acceptable.
In short: pgvector is entry-level; vector DBs are production-grade.
Pinecone: the most popular managed option
Pinecone has become the “default” choice for teams that want a fully managed, cloud-native vector database with minimal setup.
Pricing model and vendor lock-in considerations
- Usage-based: Pay for storage (per million vectors) + queries.
- Pro: No infra management, elastic scaling.
- Con: Vendor lock-in—no self-hosted version. Migrating away means rebuilding indexes.
Cost example: ~1M vectors (768-dim, float32) costs $20–30/month for storage + query costs. At high scale, monthly bills can reach thousands.
Performance and specific features
- Index types: IVF, HNSW under the hood.
- Strong filtering (metadata search alongside vectors).
- Integrations: LangChain, LlamaIndex, OpenAI ecosystem.
- SLA-backed uptime, analytics dashboards.
Great for teams needing enterprise reliability without DevOps burden.
Weaviate: open-source with advanced capabilities
Weaviate is an open-source vector database that also provides a managed cloud. Its strength lies in flexibility and hybrid search (combining keyword + vector).

Self-hosted vs managed cloud options
- Self-hosted: Run via Docker/Kubernetes. Free but requires ops expertise.
- Managed (Weaviate Cloud Services): Usage-based pricing similar to Pinecone.
This dual option reduces lock-in risk—start cloud, migrate self-hosted later.
GraphQL API and integration patterns
- Exposes GraphQL queries for semantic + keyword + hybrid search.
- Built-in modules: text2vec transformers, OpenAI connector, Cohere connector.
- Can act as both vector DB and semantic layer.
Best for teams that want search + semantic reasoning in one platform.
Qdrant: the efficient Rust-based alternative
Qdrant is a high-performance Rust-based vector DB with a focus on efficiency.
- Performance: Extremely low latency with HNSW index, handles high QPS.
- Deployment: Open-source, Docker-ready, or managed cloud.
- Features: Strong metadata filtering, REST/gRPC APIs, tight integration with LangChain & Haystack.
- Cost: Managed Qdrant is cheaper than Pinecone at comparable scale.
Qdrant excels when you want speed + open-source flexibility without Pinecone’s pricing overhead.
pgvector: extending PostgreSQL for simple cases
pgvector is a Postgres extension that enables vector similarity search inside your existing database.
When pgvector is sufficient vs dedicated vector DB
Use pgvector if:
- Dataset is <1–5M vectors.
- Queries per second are modest (<100).
- Your team already maintains Postgres and prefers minimal stack.
It struggles with:
- Very large datasets (10M+).
- High concurrency search.
- Advanced indexing—pgvector supports basic IVFFlat, but not as optimized as HNSW in dedicated DBs.
Ideal for MVPs, prototypes, and small SaaS apps.
Comparative benchmarks: latency, throughput, accuracy
Based on public benchmarks (2024–2025 averages, 768-d vectors, HNSW indexing):
DB | Latency (1M vectors) | QPS sustained | Recall@10 | Notes |
---|---|---|---|---|
Pinecone | 30–60ms | High (elastic) | 0.95–0.99 | Strong cloud reliability |
Weaviate | 40–70ms | High | 0.95–0.98 | Hybrid search advantage |
Qdrant | 25–50ms | Very high | 0.96–0.99 | Rust speed, open-source |
pgvector | 80–150ms | Low–medium | 0.92–0.96 | Best for smaller datasets |
Decision matrix: features vs complexity vs cost
- Pinecone → ✅ Easiest managed option, ❌ vendor lock-in.
- Weaviate → ✅ Hybrid search + open-source path, ❌ slightly more overhead.
- Qdrant → ✅ Fast, cost-efficient, open-source, ❌ fewer “out-of-box” modules than Weaviate.
- pgvector → ✅ Minimal setup for small teams, ❌ not scalable for big workloads.
Migration paths and vendor lock-in mitigation
- Start with pgvector → Migrate to Weaviate/Qdrant when scale grows.
- Start with Pinecone → Export vectors/metadata to open-source DB before lock-in deepens.
- Weaviate/Qdrant → Open-source ensures you can migrate between managed + self-hosted.
Mitigation tactic: store raw embeddings separately (e.g., in S3) so re-indexing in another DB is straightforward.
Production considerations: monitoring, scaling, backup
- Monitoring: Track recall, latency, error rates. Pinecone has dashboards; Qdrant/Weaviate need Prometheus/Grafana setups.
- Scaling: Pinecone auto-scales; Qdrant & Weaviate require Kubernetes tuning; pgvector depends on Postgres scaling.
- Backup: Pinecone = managed snapshots. Weaviate & Qdrant = self-managed or managed backups. pgvector = native Postgres backups.
It is all about choices
- Pinecone: Best for teams prioritizing speed-to-market and managed reliability.
- Weaviate: Flexible, feature-rich, with an open-source fallback.
- Qdrant: Fast, efficient, cost-conscious—great open-source choice.
- pgvector: The “lite” option for small projects or Postgres-first teams.
The right choice depends on scale, budget, and lock-in tolerance.
FAQs
Is pgvector enough for production?
Yes, for small-medium datasets (<5M vectors). At larger scale, latency and query costs rise.
Which DB is fastest?
Qdrant often benchmarks fastest thanks to Rust implementation.
How do I avoid vendor lock-in?
Always store raw embeddings separately. That way you can re-index in another DB anytime.