Pinecone vs Weaviate vs Milvus: which one to use

Choosing a vector database feels like picking a cloud provider in 2012 — everyone claims sub-millisecond latency and infinite scale, but the operational reality diverges fast. Pinecone, Weaviate, and Milvus represent three fundamentally different architectural bets: fully managed proprietary, open-source with modular extensions, and distributed cloud-native. This comparison cuts through the marketing to help you decide which trade-offs you’re actually willing to live with.

Architecture and deployment model

Pinecone is a fully managed service — no self-hosted option exists. You create an index, pick a pod type (or serverless), and ingest vectors. The control plane handles replication, sharding, and upgrades. This is the fastest path to “it works,” but you’re locked into their pricing, their index algorithm, and their regional availability. If Pinecone goes down in us-east-1, your application goes down with it.

Weaviate ships as a single Go binary with an embedded vector index (HNSW) and an optional module system for vectorization, reranking, and generative search. You can run it locally via Docker, on Kubernetes with the official Helm chart, or on Weaviate Cloud Services (WCS). Multi-tenancy is a first-class concept: isolated namespaces with per-tenant resource quotas, which matters for B2B SaaS.

Milvus separates compute from storage at the architecture level. The coordinator, proxy, query nodes, data nodes, and index nodes scale independently. It relies on etcd for metadata, MinIO or S3 for object storage, and Pulsar/Kafka for the write-ahead log. This makes Milvus the most operationally complex — you’re running a distributed system, not a database — but it also means you can scale ingest and query throughput independently. Zilliz Cloud offers a managed tier if you want the architecture without the pager duty.

# Milvus docker-compose snippet showing component separation
services:
  etcd:
    image: quay.io/coreos/etcd:v3.5.5
  minio:
    image: minio/minio:RELEASE.2023-03-20T20-16-18Z
  pulsar:
    image: apachepulsar/pulsar:2.11.0
  milvus:
    image: milvusdb/milvus:v2.3.4
    depends_on: ["etcd", "minio", "pulsar"]

Indexing and search capabilities

All three support HNSW as the primary ANN index. Pinecone exposes exactly one index type — their proprietary variant — with two knobs: pod_type (which determines memory/CPU) and metadata_config for filtering. You cannot tune efConstruction or M directly. This is intentional: they optimize for you, but you lose the ability to trade recall for latency on a per-index basis.

Weaviate uses HNSW via the hnswlib library and exposes the full parameter surface: efConstruction, ef, maxConnections, and vectorCacheMaxObjects. It also supports inverted file (IVF) indexes for disk-heavy workloads and a flat (brute-force) index for small collections. Hybrid search (BM25 + vector) is native — you write a single GraphQL query that fuses lexical and semantic scores with configurable weights.

# Weaviate hybrid search with alpha weighting
{
  Get {
    Document(
      hybrid: {
        query: "transformer attention mechanism"
        alpha: 0.75
        properties: ["title^2", "body"]
      }
      nearVector: { vector: [0.1, -0.3, ...] }
    ) {
      title
      _additional { score }
    }
  }
}

Milvus supports the widest index zoo: HNSW, IVF_FLAT, IVF_SQ8, IVF_PQ, SCANN, DISKANN, and GPU-accelerated variants (GPU_IVF_FLAT, GPU_IVF_PQ). Each index type has distinct memory, latency, and recall profiles. You choose at collection creation time and can rebuild with a different index later. Milvus also supports range search, grouped search, and iterator-based streaming for large result sets — features Pinecone and Weaviate lack.

Filtering and metadata handling

Pinecone’s metadata filtering uses a proprietary engine that evaluates filters during the ANN traversal (pre-filtering). It supports exact match, range, and $in/$nin operators on up to 40KB of metadata per vector. Performance degrades noticeably when filter selectivity is low (e.g., filtering on a high-cardinality field that matches 80% of vectors).

Weaviate stores metadata as properties in the same object as the vector. Filters are applied post-retrieval by default, though the filtered vector search operator can push some predicates into the HNSW traversal. The GraphQL where filter supports nested boolean logic, geo-coordinates, and cross-ref traversal. For multi-tenant workloads, the tenant filter is enforced at the storage layer — zero leakage risk.

Milvus uses a bitmap-based filtering engine (Bitset) that intersects with the ANN candidate set. It supports scalar filtering on INT, FLOAT, VARCHAR, BOOL, and JSON fields, plus array containment and JSON path expressions. The query planner decides whether to pre-filter or post-filter based on selectivity estimates. For high-cardinality filters, Milvus often outperforms both alternatives because the bitmap intersection happens before the expensive distance computations.

Performance characteristics

No vendor publishes reproducible, workload-agnostic benchmarks — and for good reason. Vector search performance depends on dimensionality, index parameters, filter selectivity, batch size, and hardware. What I can share from production experience:

• Pinecone serverless delivers consistent 20–50ms p99 latency for 1536-dim vectors at 1M scale with light filtering. Cold starts add 100–300ms on first request after idle. Pod-based deployments remove cold starts but require capacity planning.
• Weaviate on equivalent hardware (8 vCPU, 32GB RAM) serves 100–200 QPS at 90% recall for 768-dim vectors with hybrid search. HNSW ef tuning is critical: ef=128 vs ef=64 can swing recall from 85% to 95% with 2x latency cost.
• Milvus shines at scale. A 3-node query cluster (16 vCPU, 64GB each) handles 100M+ vectors with sub-50ms p99 on filtered search. The separation of data nodes (ingest) and query nodes (search) means write throughput doesn’t contend with read latency.

# Latency profiling snippet — run against your actual workload
import time
import numpy as np
from pinecone import Pinecone
import weaviate
from pymilvus import MilvusClient

def benchmark_search(client, index_name, query_vector, filter_expr, runs=100):
    latencies = []
    for _ in range(runs):
        start = time.perf_counter()
        # Pinecone: index.query(vector=query_vector, filter=filter_expr, top_k=10)
        # Weaviate: client.query.get(...).with_near_vector(...).with_where(...).do()
        # Milvus: client.search(collection_name=index_name, data=[query_vector], filter=filter_expr, limit=10)
        latencies.append((time.perf_counter() - start) * 1000)
    return np.percentile(latencies, [50, 95, 99])

Developer experience and ergonomics

Pinecone’s Python SDK is the cleanest — minimal surface area, sensible defaults, and excellent type hints. The REST API is OpenAPI-spec’d. You’ll write less boilerplate, but you’ll also hit walls faster when you need something outside the happy path (custom scoring, partial updates, bulk delete by filter).

# Pinecone upsert — minimal ceremony
from pinecone import Pinecone, ServerlessSpec

pc = Pinecone(api_key="...")
index = pc.Index("prod-docs")
index.upsert(vectors=[
    {"id": "doc-1", "values": [0.1]*1536, "metadata": {"source": "blog", "tenant": "acme"}}
])

Weaviate’s Python client is verbose but explicit. The GraphQL-based query language is powerful once you learn it — hybrid search, generative search, and cross-reference traversal are single-request operations. The schema migration story is weak: adding a property requires a class recreation or a migration script. Type safety comes from Pydantic models you maintain yourself.

Milvus’s pymilvus client exposes the full gRPC surface. You manage collections, partitions, indexes, and load/release state explicitly. This is systems programming, not application development. The MilvusClient (new in 2.3) provides a simpler ORM-style interface, but the legacy Collection API is still widely used. Expect to read the gRPC protobuf definitions when debugging.

Ecosystem and integrations

Pinecone has the deepest LangChain, LlamaIndex, and Vercel AI SDK integrations — often first-party maintained. If your stack is Next.js + LangChain + OpenAI embeddings, Pinecone drops in with zero glue code. The downside: you’re dependent on their integration pace. When OpenAI released text-embedding-3-large with 3072 dimensions, Pinecone support lagged by weeks.

Weaviate’s module system means vectorization (OpenAI, Cohere, HuggingFace, custom), reranking (Cohere, Jina, Voyage), and generative search (OpenAI, Cohere, HuggingFace, Ollama) are configurable at schema level — no application code changes. The GraphQL API makes it easy to swap providers. Community modules exist for Voyage, BGE, and instructor embeddings.

Milvus integrates with the same frameworks but often via community-maintained connectors. The Milvus team maintains LangChain and LlamaIndex integrations, but they lag feature parity by a release or two. Milvus’s strength is the broader data ecosystem: Apache Spark/Flink connectors for batch/stream ingest, CDC from MySQL/PostgreSQL via Debezium, and Grafana dashboards for observability. If you’re building a data platform, not just a RAG app, Milvus fits the existing tooling.

Cost model

Pinecone serverless charges per 1M vector dimensions stored ($0.06) and per 1M read units ($0.35) / write units ($0.15). A “read unit” ≈ 1000 vectors scanned. At 10M vectors (1536-dim) with 100 QPS, expect $400–800/month. Pod-based pricing starts at $70/month for a p1.x1 (2GB index memory) and scales linearly — a p2.x8 (100GB) runs ~$3,500/month. No free tier beyond the 100k vector starter index.

Weaviate Cloud Services charges per “capacity unit” (CU) — 2 vCPU, 8GB RAM, 50GB storage for $0.50/hour (~$365/month). Self-hosted is free (Apache 2.0) but you pay for infrastructure. A 3-node EKS cluster (m6i.xlarge) with EBS gp3 runs ~$600/month including data transfer. WCS includes managed backups, SSO, and SOC2 — valuable for enterprise.

Milvus self-hosted on Kubernetes: 3 query nodes + 2 data nodes + etcd/MinIO/Pulsar on m6i.xlarge instances ≈ $1,200/month on AWS. Zilliz Cloud charges per CU (4 vCPU, 16GB RAM) at $0.75/hour (~$550/month/CU). The decoupled architecture means you can run 1 data node for ingest and 10 query nodes for search bursts — pay for what you use. Milvus also supports tiered storage (hot SSD / cold S3) which can cut storage costs 5–10x for archival vectors.

Comparison table

Which to choose

Choose Pinecone if: you need a vector index tomorrow, your team has zero bandwidth for infrastructure, and your workload fits the serverless model (bursty traffic, <50M vectors, minimal filtering complexity). The developer velocity gain is real — but you’re buying a black box. When (not if) you hit a limitation, your only lever is support tickets.

Choose Weaviate if: you’re building a multi-tenant B2B product where data isolation is a compliance requirement, you need hybrid search (lexical + semantic) out of the box, or you want the flexibility to swap embedding providers without code changes. The GraphQL API pays off when your query logic gets complex. Self-host on Kubernetes if you have the ops maturity; WCS if you don’t.

Choose Milvus if: you’re operating at 100M+ vectors, you need independent scaling of ingest vs. query throughput, you have specific index requirements (DISKANN for cost, GPU indexes for latency, binary vectors for memory), or you’re building a data platform that needs Spark/Flink/CDC integration. Accept that you’ll spend real engineering time on cluster operations — or pay Zilliz Cloud premium to offload it.

There’s no universal winner. The right choice is the one whose constraints you’re willing to inherit.