Vector Databases Compared: pgvector vs. Pinecone vs. Weaviate

This is for engineering teams past "we need a vector database" and into "which one." If you've read our RAG explainer, you know the vector database sits at the retrieval step: it stores document embeddings and finds the closest matches to a query in milliseconds. Picking the wrong one usually doesn't break a prototype; it breaks your cost model or your ops team six months into production.

What does a vector database actually do?

A vector database stores high-dimensional vectors (the embeddings produced from your document chunks) and answers nearest-neighbor queries fast: given a new query vector, find the k most similar stored vectors, typically in under 100 milliseconds even across millions of records. Under the hood, this means building and maintaining an approximate nearest-neighbor index (commonly HNSW), which trades a small amount of accuracy for large speed gains over brute-force comparison. The choice between options mostly comes down to where that index lives: bolted onto a database you already run, in a dedicated managed service, or in infrastructure you manage yourself.

pgvector vs. Pinecone vs. Weaviate vs. Qdrant: comparison table

Prices above are current as of late 2026 per each vendor's own pricing page: Pinecone, Weaviate, Qdrant. Vector database pricing changes often as vendors adjust usage-unit definitions, so confirm current rates before budgeting a production deployment.

When should you just use pgvector?

If you already run Postgres for your application's primary data, and your vector workload is moderate (roughly up to a few million vectors with reasonable query volume), pgvector is usually the right default. The case for it is simple: no new service to operate, no new vendor relationship, no data synchronization problem between your relational data and your vector store, and you can join vector search results directly against your existing tables in a single SQL query, which is awkward or impossible with most dedicated vector databases. The tradeoff is that pgvector is not purpose-built for vector search the way Pinecone or Qdrant are; past a certain scale, index build time and query latency need real tuning (quantization, parallel index builds, careful choice between HNSW and IVFFlat index types), and very large-scale deployments sometimes outgrow it. For most startups and mid-market products, that ceiling is well above where the project actually sits, which is why pgvector is our default recommendation unless a client has a specific reason to need more.

When does a dedicated vector database earn its cost?

Reach for a dedicated vector database (Pinecone, Weaviate, or Qdrant) when one of these is true:

• Scale genuinely exceeds what pgvector handles comfortably, typically tens of millions of vectors with high query throughput, where a purpose-built index and horizontal scaling model matters.
• You need hybrid search, multi-tenancy, or managed embedding generation built in, which Weaviate in particular packages as one platform rather than infrastructure you assemble yourself.
• Your team doesn't want to own index tuning and scaling decisions, and would rather pay a managed service to handle that, trading cost for reduced ops burden. Pinecone is the clearest example of this tradeoff: higher cost, close to zero infrastructure decisions.
• You need fine-grained cost control at large scale through techniques like quantization and disk-based indexes, where Qdrant's infrastructure-level configurability tends to produce the lowest cost per vector once you're willing to manage those decisions yourself.

A worked example: choosing for a 2-million-document RAG system

Say you're building a RAG system over 2 million document chunks (roughly consistent with a mid-sized company's full internal knowledge base), expecting moderate query volume, perhaps 50,000-100,000 queries a month. Three realistic paths:

1. pgvector on an existing Postgres instance, sized with a properly tuned HNSW index. At this scale, this is comfortably within pgvector's working range, costs nothing beyond your existing database hosting, and avoids adding a new service. This is usually our default recommendation for a build at this scale unless another requirement pushes toward a dedicated option.
2. Pinecone Standard, which at this query volume would likely run close to or somewhat above the $50/month usage minimum once read and write unit costs are factored in, trading a modest monthly cost for essentially zero index management.
3. Qdrant Cloud, sized to a small-to-mid dedicated cluster, likely in the same general cost range as Pinecone at this scale but with more manual sizing decisions and more room to reduce cost further through quantization if query patterns allow for it.

At this scale, the three options land in a similar cost range; the deciding factor is usually team preference (do you want to own infrastructure decisions, or pay to avoid them) rather than cost alone. The calculus changes meaningfully past roughly 20-50 million vectors or very high query throughput, where the differences between these approaches start to compound.

What about metadata filtering and index type?

Most real RAG applications need more than pure similarity search: you often need to filter results by metadata, like restricting search to a specific customer's documents, a date range, or a document type, before or alongside the vector similarity ranking. All of the options compared here support metadata filtering, but performance under heavy filtering varies: pgvector relies on Postgres's standard indexing and query planning, which works well when filters are selective (narrowing to a small subset before the vector search runs) but can degrade if filters are broad and the vector index still has to scan a large candidate set. Pinecone and Weaviate both support native metadata filtering integrated into their index structures, generally handling this more gracefully at scale. If your application depends heavily on multi-tenant filtering, meaning every query is scoped to one customer's data, test filtered-query latency specifically during evaluation, not just raw unfiltered vector search speed, since that's the pattern that actually matters in production.

On index type, most of these databases default to HNSW (Hierarchical Navigable Small World), which trades a small amount of recall for fast approximate search. Some, including Qdrant and pgvector, also support IVFFlat or disk-backed index variants that trade some query speed for lower memory usage, useful when vector volume is large relative to available RAM. This is a tuning decision worth revisiting once you have real production query patterns rather than guessing upfront, since the right tradeoff depends on your actual ratio of vectors to available memory and your latency requirements.

Does the embedding model matter as much as the database?

Often more. The vector database stores and searches whatever embeddings you give it; if the embedding model poorly represents your domain's semantic distinctions (for example, a general-purpose embedding model that doesn't distinguish well between similar legal clauses, or similar part numbers), no amount of database tuning fixes retrieval quality. Evaluate your embedding model choice (OpenAI's text-embedding-3 family, Google's Gemini embedding models, or open-source options like BGE and E5) against your actual retrieval test set before assuming a database swap will fix a quality problem that's actually upstream. See our RAG explainer for how embedding choice fits into the overall pipeline.

How much does vendor lock-in matter for this decision?

Less than it might seem, if you architect for it upfront. The actual data you'd need to migrate, document chunks and their embeddings, is portable across every option here; the work in switching databases later is mostly re-indexing and re-tuning retrieval parameters for the new system, not a from-scratch rebuild. Where lock-in shows up more is in managed-platform features that go beyond plain vector storage: Weaviate's built-in embedding generation and Query Agent, or Pinecone's specific index configuration options, aren't directly portable and would need to be re-implemented if you moved providers. If you expect to need those platform-specific features, that's a reasonable tradeoff to accept; if you're choosing mainly for raw vector search, keeping your embedding generation and retrieval logic in your own application code (rather than deeply coupled to one vendor's platform features) keeps a future migration cheap regardless of which database you start with.

How we approach this at Venzpire

We default to pgvector when a client already runs Postgres and the vector workload is moderate, because it keeps the stack simple and avoids an extra vendor relationship. When scale, hybrid search needs, or a client's existing infrastructure preferences point elsewhere, we've shipped with Pinecone and Weaviate too; our stack includes pgvector, Pinecone, and Weaviate, and the choice is driven by your actual data volume and query patterns, tested during the $1,500 discovery sprint rather than assumed upfront. If you're scoping a RAG or retrieval-heavy system and want the database choice grounded in your real numbers, see our LLM integration page or apply directly.