Every RAG tutorial picks a vector database and moves on. Almost none of them explain why they picked it, what it costs at scale, or when you should use something different.
This comparison is honest about the tradeoffs. Pinecone, Weaviate, and pgvector each have real use cases where they are the right choice, and real cases where they are the wrong one.
What Vector Databases Actually Do
A vector database stores high-dimensional embeddings and lets you find the nearest neighbors efficiently. When you embed a user query and want to find the most similar chunks in your knowledge base, that is a vector similarity search.
The key operations you care about:
- Insert: store a vector plus associated metadata
- Query: find the K most similar vectors to a query vector
- Filter: narrow results by metadata before or after similarity search
- Update/delete: modify or remove vectors
These sound simple. The performance, cost, and operational complexity differences between options become apparent at scale and in production.
Pinecone
Pinecone is fully managed, serverless, and purpose-built for vector search. You get an API, you call it, it works. No infrastructure to manage.
The good: Pinecone is the fastest path from zero to production vector search. The API is clean, the documentation is good, and the managed service handles scaling, replication, and backups. For teams that want to build applications rather than operate databases, this is the right tradeoff.
Performance: Pinecone's serverless tier has improved significantly. P99 query latency on typical RAG workloads (10M vectors, top-10 retrieval) is under 100ms. Cold start latency on serverless indexes can be higher — if you need consistent sub-50ms queries, use the dedicated pods tier.
The cost reality: This is where Pinecone gets complicated. The serverless tier prices by reads and writes, which is unpredictable. For high-volume applications, you can spend $500-2000/month before you realize it. The dedicated pods tier is more predictable but starts at around $70/month for a single s1 pod.
Rough estimate for a 10M vector index with 1000 queries/day on serverless: $50-150/month depending on vector dimensionality and query patterns. At 100K queries/day, that scales to $3000-8000/month. Model this before committing.
When to use Pinecone:
- You want a managed solution with no infrastructure work
- You are prototyping or at early scale
- Your query volume is predictable or low-to-medium
- You need to ship quickly
When not to use Pinecone:
- You have very high query volume (the cost math gets ugly)
- You need complex metadata filtering alongside vector search
- You want to self-host for compliance or cost reasons
Weaviate
Weaviate is an open-source vector database with a managed cloud option. It goes beyond pure vector search — you can combine semantic search with keyword search (BM25), apply filters, and query across multiple vector spaces in a single request.
The good: Weaviate's hybrid search is genuinely excellent. Combining BM25 keyword matching with vector similarity often outperforms pure vector search for real-world queries, where users mix semantic intent with specific keywords. If you are building a search system rather than a simple RAG pipeline, this matters.
Weaviate also stores your source documents alongside the vectors, which simplifies architecture. You do not need a separate document store.
The honest trade-off: Weaviate has a steeper learning curve than Pinecone. The query language (GraphQL-based) is more complex. Self-hosted Weaviate requires meaningful DevOps investment. The managed cloud option reduces this but costs more than you might expect.
Performance: Self-hosted Weaviate on reasonable hardware handles tens of millions of vectors well. The HNSW index provides strong query performance. Memory requirements are high — plan for 4-8GB RAM per 1M vectors as a rough baseline.
Cost for self-hosted: Infrastructure only — typically $200-600/month on cloud VMs for a production setup with redundancy. Weaviate Cloud starts around $25/month for small deployments and scales from there.
When to use Weaviate:
- You need hybrid search (semantic plus keyword) in one query
- You want to self-host for cost or compliance
- You are building a search-heavy application (not just RAG)
- You need multi-tenancy at the data layer
When not to use Weaviate:
- Your team does not have DevOps capacity for self-hosting
- You need the simplest possible setup quickly
- Pure vector similarity is sufficient for your use case
pgvector
pgvector is a PostgreSQL extension. If you already run Postgres, you can store vectors in the same database as the rest of your data with a single CREATE EXTENSION command.
The good: For applications already running Postgres, pgvector is the most operationally simple option. No additional infrastructure, no additional operational knowledge, no additional cost beyond your existing database. You can join vector search results with relational data in a single query — something neither Pinecone nor Weaviate supports natively.
-- Example: find similar products, filtered by in-stock status
SELECT p.name, p.price, 1 - (p.embedding <=> $1) AS similarity
FROM products p
WHERE p.in_stock = true
ORDER BY p.embedding <=> $1
LIMIT 10;
This kind of query — vector similarity plus relational filtering — is awkward or impossible in purpose-built vector databases.
The honest limitation: pgvector is not designed for high-scale vector workloads. At millions of vectors, query performance degrades without careful index tuning. The HNSW index (added in pgvector 0.5) improved this significantly, but Pinecone and Weaviate still win on raw vector search performance at large scale.
The other limitation: approximate nearest neighbor (ANN) algorithms in pgvector are less mature than in purpose-built vector databases. At high precision requirements, this matters.
Performance: For under 1M vectors with HNSW indexing, query performance is excellent — under 10ms for typical workloads. For 10M+ vectors, expect to do careful performance tuning.
Cost: Essentially free if you are already running Postgres. Managed Postgres with pgvector (Supabase, Neon, RDS) starts at $25-50/month for production setups.
When to use pgvector:
- You already run Postgres and want minimal operational overhead
- You need to join vectors with relational data
- Your vector data volume is under 5-10M entries
- You want the simplest possible architecture
When not to use pgvector:
- You need to scale to hundreds of millions of vectors
- Your query volume is very high (vector search is CPU-intensive in Postgres)
- You need advanced features like multi-vector search or hybrid BM25+vector
The Decision Matrix
| Factor | Pinecone | Weaviate | pgvector | |--------|----------|----------|----------| | Setup time | 30 minutes | 1-4 hours | 10 minutes | | Operational complexity | Low | Medium-High | Low | | Query performance at scale | High | High | Medium | | Hybrid search | No | Yes | Via extensions | | Relational joins | No | No | Yes | | Cost at low volume | Low-Medium | Low (self-hosted) | Low | | Cost at high volume | High | Medium | Medium | | Self-hosting | No | Yes | Yes |
What Most Teams Should Do
For most teams building RAG applications in 2026:
If you are using Supabase or already have a Postgres database, start with pgvector. It is free, simple, and good enough for early-stage products. You can migrate later if you need to.
If you need a fully managed solution and have predictable, moderate query volume, Pinecone's developer experience is hard to beat. Model your costs before committing to serverless at scale.
If you need hybrid search or are building a search-first product, Weaviate's query capabilities are worth the added complexity.
The Phase 4 curriculum at MindloomHQ's Agentic AI course covers Memory and RAG architecture in detail — including vector database selection, embedding models, chunking strategies, and hybrid retrieval patterns. If you are building production RAG, the structured approach pays off.
The wrong vector database will not kill your project. Starting without any observability on your retrieval quality will.