Vector Databases for Enterprise: Pinecone vs Weaviate vs pgvector

Most vector database comparisons are written by people who ran a benchmark on synthetic data with 10,000 vectors and published the results. Real enterprise deployments have millions of vectors, strict metadata filtering requirements, compliance constraints on where data can live, and hybrid search requirements. The benchmarks do not capture any of that.

Here is what production deployments actually reveal about each option.

pgvector: The Default Starting Point

If your team already runs Postgres, start with pgvector. It is not the fastest option at scale, but the operational simplicity of keeping everything in one database is worth a lot in the early stages of a deployment.

pgvector (current: v0.8.x) with HNSW indexing handles up to about 5 million vectors with acceptable query latency (under 100ms for most enterprise queries). Beyond that, you start hitting index build times and memory requirements that become problematic.

One critical limitation to know upfront: pgvector's HNSW index has a 2,000-dimension limit. If you plan to use OpenAI's text-embedding-3-large (3,072 dimensions) or similar high-dimensional models, you have two options: truncate dimensions to 1,536 via the API's dimensions parameter (which reduces quality marginally), or switch to Weaviate, which has no such dimension ceiling.

-- Enable extension
CREATE EXTENSION vector;

-- Create table with vector column
CREATE TABLE documents (
    id BIGSERIAL PRIMARY KEY,
    content TEXT,
    embedding vector(1536),
    doc_type VARCHAR(50),
    department VARCHAR(100),
    created_at TIMESTAMP,
    version INTEGER
);

-- HNSW index for approximate nearest neighbor search
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);

-- Hybrid search: combine vector similarity with metadata filter
SELECT id, content, 1 - (embedding <=> $1::vector) AS similarity
FROM documents
WHERE doc_type = 'contract'
  AND department = 'legal'
  AND version = (SELECT MAX(version) FROM documents d2 WHERE d2.id = documents.id)
ORDER BY embedding <=> $1::vector
LIMIT 20;

The query above runs in under 50ms on a well-tuned Postgres instance with 2 million vectors. That is adequate for most enterprise use cases.

When pgvector breaks down: Concurrent write workloads at scale. If you are ingesting thousands of new vectors per minute while serving queries, the HNSW index rebuild contention starts causing latency spikes. Also, the index lives entirely in memory. A 1536-dimension HNSW index for 5 million vectors requires roughly 10-15GB of RAM.

Weaviate: The Operational Sweet Spot for Most Enterprise Deployments

Weaviate is our default recommendation for enterprise deployments that have grown past what pgvector handles comfortably, or for any deployment where hybrid search is a primary requirement.

What makes it our default:

• Native hybrid search (BM25 plus vector) in a single query, without having to merge result sets yourself
• Module system for integrating with OpenAI, Cohere, and other embedding providers directly
• Multi-tenancy support that maps cleanly to enterprise role-based access control requirements
• HNSW plus product quantization for memory-efficient storage at scale

# Hybrid search in Weaviate
result = client.query.get("Document", ["content", "docType", "department"]) \
    .with_hybrid(
        query="limitation of liability clause",
        alpha=0.6,  # 0 = pure keyword, 1 = pure vector
        properties=["content"]
    ) \
    .with_where({
        "path": ["docType"],
        "operator": "Equal",
        "valueString": "contract"
    }) \
    .with_limit(20) \
    .do()

The alpha parameter controls the balance between keyword and semantic search. We typically tune this per use case. Legal and compliance queries benefit from higher keyword weight (exact term matching matters). Conceptual queries benefit from higher semantic weight.

The operational reality: Weaviate requires Kubernetes or Docker Compose to self-host. Adding a new infrastructure component to your stack is a real cost. If your team does not have the operational capacity to manage it, the managed Weaviate Cloud service is reasonable, but it means your vector data lives outside your infrastructure, which requires an enterprise data processing agreement for regulated industries.

Pinecone: Fast and Managed, With Trade-offs

Pinecone is the fastest to get started with. No infrastructure to manage. The API is clean and the developer experience is good. It is genuinely fast at query time.

The limitations matter in enterprise contexts:

Data residency: Your vectors live on Pinecone's infrastructure. For regulated industries, this requires a data processing agreement and depends on which region you deploy in. Some industries have data residency requirements that effectively rule it out.

Hybrid search limitations: Pinecone added sparse-dense hybrid search, but it requires you to handle sparse index creation and management separately. It is more manual than Weaviate's native hybrid search implementation.

Metadata filtering at scale: Pinecone's metadata filtering can be slow when filter selectivity is low (i.e., when the filter matches a large percentage of your namespace). This becomes noticeable at tens of millions of vectors with broad metadata filters.

The Decision Framework We Use

Under 5M vectors + Postgres already in stack
    → pgvector

Over 5M vectors OR need robust hybrid search
OR need multi-tenancy OR self-hosted is required
    → Weaviate (self-hosted if data residency required,
                managed if operational simplicity preferred)

Fastest time-to-deploy + data residency not a constraint
+ team wants minimal infra management
    → Pinecone

The Index Configuration That Actually Matters

Whichever database you use, the HNSW index parameters have a larger effect on query quality than most teams realize.

m (the number of bidirectional links in the graph): Higher values improve search quality at the cost of more memory and slower index builds. For enterprise knowledge bases where accuracy matters, use m=16 or m=32. For high-throughput real-time applications where latency is more important, m=8 or m=12.

ef_construction (search depth during index build): Higher values mean better index quality and slower build times. We use 64 for most deployments. For very large corpora where index quality directly affects business outcomes (legal, compliance), we use 128.

ef (search depth at query time): This is the most important parameter to tune for quality. Start at 64 and increase if recall is insufficient. The latency increase is predictable and linear.

Sources

• pgvector GitHub — v0.8.x release notes and HNSW dimension limits
• Weaviate Docs — Hybrid Search
• Pinecone Docs — Getting Started
• pgvector HNSW Index Guide (March 2026)