On this page
Vector Databases Compared: Scale Cliffs and the Pricing Lie
This vector database comparison reveals a 7x cost inversion between 10M and 100M vectors, where managed services like Pinecone cost far more than self-hosted alternatives. It also exposes a 2.5x to 4x gap between vendor pricing estimates and real production bills, plus a practical decision framework for choosing the right tool for your scale and workload.
At 10 million vectors, Pinecone Serverless costs approximately $70/month while pgvector on RDS runs about $45/month. At 100 million vectors, Pinecone Standard reaches $700+/month while self-hosted Milvus or pgvector stays under $100/month. That 7x cost inversion between 10M and 100M vectors is the single most important data point in the vector database market in 2026, and almost nobody talks about it because vendor pricing pages are designed to hide it.
The gap between vendor pricing page estimates and actual production monthly bills averages 2.5x to 4x, according to LeanOps’s cost analysis. Hidden costs include compute for in-memory indexes, egress charges, and replication for high availability — none of which show up in the pricing calculator you used to get budget approval.
Here’s why that matters for your vector database comparison: the deployment model you choose — managed SaaS versus self-hosted versus Postgres-native — determines your cost trajectory more than any benchmark score. A pattern I’ve observed across the market: scale cliffs at 10M and 100M vectors where cost structures invert, combined with a systemic transparency gap between vendor pricing and production bills. I call this Scale Cliff Economics, and it makes the Query-to-Ingestion Ratio (QIR) your true decision metric, not peak QPS on a synthetic benchmark.
If you’re building RAG pipelines or connecting AI agents to production data, your vector database is becoming one of your biggest infrastructure line items. The “cheapest” option on a vendor pricing page is typically the most expensive in production. Self-hosted estimates omit real operational overhead. Managed services charge per-query fees that explode at scale. The right choice depends entirely on where you sit on the scale curve.
The Pricing Transparency Gap Is Your Biggest Risk
Vendor pricing pages show you storage and basic query costs. They don’t show you the compute needed to keep indexes in memory for low-latency search. They don’t show egress charges when your application and database live in different regions. They don’t show replication costs for high availability — which you absolutely need in production but which doubles or triples your base cost.
The 2.5x to 4x billing surprise that LeanOps documents isn’t a rounding error. It’s structural. Production RAG systems routinely store 10x to 50x more vector data than teams initially estimate because of metadata, multiple embedding models, and versioning. A single OpenAI text-embedding-3-large call produces a 3,072-dimension vector. Store one million documents with that embedding and you’re looking at 12GB of raw vector data before indexing overhead.
Self-hosted estimates have their own blind spot. The DevZone Cost Calculator recommends including $500-750/month in DevOps overhead for true total cost of ownership on self-hosted deployments. That’s the human cost of keeping a distributed vector database running — monitoring, upgrades, capacity planning, incident response. Toggle that off and self-hosted looks dramatically cheaper than managed. Toggle it on and the picture changes.
One lever that genuinely moves the needle: quantization. Dropping from float32 to int8 typically cuts storage costs by ~75% with under 2% recall loss, per the DevZone calculator. That’s not a nice-to-have optimization. At 10M+ vectors, it’s the difference between a manageable bill and a budget crisis.
Managed vs Self-Hosted: The Real Tradeoff Matrix
The deployment model decision isn’t about which database is “best.” It’s about how much operational burden you’re willing to absorb and how much vendor lock-in you can tolerate. Each model has a distinct cost structure that becomes dominant at different scales.
Fully managed (Pinecone): Zero operational overhead and predictable latency with automatic scaling. The tradeoff is a 30-50% cost premium at scale and hard vendor lock-in with a proprietary index format requiring full re-indexing to migrate. Pinecone is closed-source with no self-host option — you’re committing to their cloud permanently.
Self-hosted open-source (Qdrant, Milvus): Sub-2ms latency and highest QPS per dollar with Rust-native efficiency (Qdrant) or billion-scale distributed architecture (Milvus). The tradeoff is self-hosting expertise, operational burden, and in Milvus’s case, Kubernetes complexity.
Postgres-native (pgvector): Zero new infrastructure if you already run Postgres. Vectors sit beside your rows in the same table, filtered through SQL WHERE clauses, with ACID transactions and point-in-time recovery. The tradeoff is a scale ceiling that hits somewhere between 5M and 100M vectors depending on who you ask.
Here’s the comparison that matters:
| Tool | Pricing (10M vectors) | Deployment Model | Target Audience |
|---|---|---|---|
| Pinecone Serverless | ~$70/month | Managed only (closed-source) | Low-ops teams, <10M vectors |
| Qdrant Cloud | ~$65/month | Self-hosted or managed (Apache 2.0) | Cost-conscious teams, filtering-heavy workloads |
| Weaviate Cloud | ~$135/month | Self-hosted or managed (BSD-3) | Hybrid search, multi-modal RAG |
| pgvector on RDS | ~$45/month | Postgres extension (open-source) | Teams already running Postgres, <5M vectors |
| Milvus (self-hosted) | Under $100/month at 100M | Self-hosted (Apache 2.0) | 100M+ vectors, Kubernetes expertise required |
The table tells you where each tool sits on the cost curve. It doesn’t tell you what happens when you cross a scale cliff — and that’s where the real decisions live.
Pinecone: The Lock-In Premium
Pinecone is the operational simplicity champion. You don’t run infrastructure, tune indexes, or worry about scaling. You insert vectors and query. That simplicity has a real cost, and I don’t just mean dollars.
The 2026 plan structure includes a free Starter tier with 2GB storage, 5 indexes, and 1M read units/month. Standard starts at $50/month minimum. Enterprise starts at $500/month minimum with a 99.95% SLA and HIPAA eligibility. The serverless model bills on storage, reads, writes, and egress with no idle compute cost — which sounds clean until you realize that per-read-unit charges compound steeply at high throughput.
The decisive tradeoff is vendor lock-in. Pinecone is the only major vector database with no self-hosting path, no open-source codebase, and a proprietary index format requiring full re-indexing to migrate away. If Pinecone changes pricing, gets acquired, or sunsets a feature, your exit cost is a complete re-embedding and re-indexing of your entire dataset. Public reporting indicates Pinecone revenue declined in 2025 versus 2024 — assess acquisition or pricing-change risk before committing long-term production workloads.
Where Pinecone wins decisively: uptime and operational simplicity. For a team without a dedicated database engineer, the 30-50% price premium over self-managed alternatives is worth it. Where it loses: cost at 100M+ scale and hybrid search quality. At 100M vectors, Pinecone Standard hits $700+/month while self-hosted Milvus or pgvector stays under $100/month with comparable performance.
Qdrant: The Performance Default With Contradictory Benchmarks
Qdrant is the most commonly recommended default for production RAG in 2026, and the pricing is genuinely attractive. Qdrant Cloud starts at ~$10-25/month with a ~1M vector (1 GB) free tier and charges $0.014/hr per node with no per-query fees. That per-node model, as opposed to per-query billing, means your costs scale with infrastructure rather than usage — which is dramatically cheaper for high-QIR workloads.
The benchmark picture is messier than the pricing. TokenMix’s 2026 benchmarks report Qdrant at ~2ms p99 latency with throughput up to 12,000 QPS — some of the lowest latencies among purpose-built vector databases. But ProPicked benchmarks show 42ms p99 at sustained 100 QPS with comparable recall. That’s a 20x variance across sources for the same database.
Here’s how to read that contradiction: Qdrant’s performance is highly dependent on workload characteristics, index configuration, and hardware. The ~2ms number likely reflects an optimized single-node setup with warm caches and low concurrency. The 42ms number reflects sustained load with realistic filtering. Both are real. Neither is the number you’ll see in production, which will land somewhere in between depending on your specific query patterns and filter selectivity.
What’s not contradictory: Qdrant’s filtering architecture. Metadata filtering is applied during the HNSW traversal rather than bolted on as a pre- or post-filter pass. This is a structural advantage for filtered search workloads, which describes most production RAG systems. If your queries combine vector similarity with metadata filters — and they almost certainly do — Qdrant’s filtering quality is a real differentiator that benchmark numbers alone don’t capture.
pgvector: The Boring Default That’s Usually Right
pgvector is a PostgreSQL extension, not a standalone database. It supports HNSW and IVFFlat indexing, is free to use with existing Postgres infrastructure, and is recommended for teams with under 5 million vectors who already run Postgres. That recommendation comes from WeekOneLabs’s comparison, and it’s the correct default for most early-stage RAG systems.
The scale ceiling is where opinions diverge. WeekOneLabs recommends pgvector only for under 5M vectors where query latency is acceptable at 5-50ms. Firecrawl’s guide suggests pgvector with pgvectorscale handles up to 100M vectors with competitive performance. That’s a 20x disagreement on the production ceiling.
The truth is probably workload-dependent. At 5M vectors with moderate filtering, pgvector on a well-tuned Postgres instance delivers acceptable latency for most RAG applications. At 50M+ vectors with complex filters and high concurrency, you’ll likely hit performance walls that require either significant Postgres tuning or migration to a purpose-built database. The AlloyDB columnar engine achieves up to 4x higher QPS for vector search compared to standard PostgreSQL HNSW — which suggests Google sees enough pgvector production usage to invest in accelerating it.
For teams already running PostgreSQL, pgvector with HNSW indexing is the correct default until you hit 50M+ vectors or require sub-10ms p99 latency. The operational simplicity of keeping vectors in your existing database — same query planner, same backup strategy, same replication setup — is worth more than the latency advantage a purpose-built database would give you. If you’re connecting AI agents to production Postgres, you should also be aware of the security realities of MCP servers with PostgreSQL — the default configurations can expose more access than you intend.
Milvus: The Graduation Point With Fuzzy Boundaries
Milvus is open-source under Apache 2.0, built for billion-scale distributed workloads with GPU acceleration, and requires Kubernetes expertise for production self-hosting. Milvus 3.0 was released on July 16, 2026 with lake-native data access to Amazon S3, Google BigLake, and Azure Data Lake Storage — meaning you can build indexes over data that stays in object storage without copying it into Milvus first.
The managed version is Zilliz Cloud, which charges $0.096 per CU-hour for compute and $0.02/GB/month for storage. Serverless auto-scaling runs at that rate. Dedicated plans start from 1 CU at $70/month. At 100M+ vectors, self-hosted Milvus on Kubernetes ($300-600/month) is 2-4x cheaper than Zilliz Dedicated ($600-1,200/month) — but that self-hosted estimate needs the $500-750/month DevOps overhead line to reflect reality.
The operational complexity threshold is where sources disagree. LeanOps states teams below 20M vectors are better served by Pinecone or Qdrant due to Milvus’s distributed overhead. Stork.AI recommends Milvus for hundreds of millions of vectors or more as the default graduation point. The gap between 20M and 100M is the fuzzy zone where Milvus’s distributed architecture is overkill but single-node solutions are straining.
Milvus separates storage, metadata, message queuing, and query/index nodes — each layer scales independently. That architecture is overkill for 1 million vectors and exactly right for 1 billion. The tradeoff is operational complexity requiring Kubernetes expertise, dedicated engineering resources, and careful capacity planning. If you’re evaluating Milvus, you should also consider how it fits into your broader AI infrastructure — our analysis of AI agent memory systems covers how retrieval architecture choices interact with agent performance.
Weaviate: Hybrid Search as the Core Differentiator
Weaviate is open-source under BSD-3 with built-in native hybrid search combining BM25 keyword and vector similarity in a single query. Weaviate Cloud starts at $25/month. The hybrid search implementation processes keyword and vector results simultaneously rather than as two separate passes you merge yourself — which is a genuine architectural advantage if hybrid search quality is your primary differentiator.
Weaviate also ships built-in vectorization modules, meaning you can insert raw text and let Weaviate handle embedding generation rather than managing a separate embedding pipeline. For teams that want production-grade RAG without stitching together a separate embedding service, this reduces operational complexity. The tradeoff is that Weaviate is not the outright fastest option at extreme scale.
The free tier situation across the market is worth noting. Pinecone offers ~1M vectors (2 GB). Qdrant offers ~1M vectors (1 GB). Zilliz offers ~5M vectors (5 GB). Weaviate offers a sandbox only. Chroma offers unlimited self-hosted. pgvector offers ~100K vectors (within 500 MB) on managed Postgres. If you’re prototyping, Chroma’s unlimited self-hosted option or Zilliz’s 5M free tier give you the most room to experiment.
Your Decision Framework: Three Questions That Actually Matter
Forget benchmark comparisons for a moment. Three questions narrow the field faster than any spec sheet.
Are you already on Postgres? If yes and you’re storing fewer than 5 million vectors, use pgvector. The operational simplicity of keeping vectors in your existing database is worth more than the latency advantage another system would give you. You inherit ACID transactions, point-in-time recovery, and the replication setup your team already understands.
What is your Query-to-Ingestion Ratio? If you’re doing few queries against a large dataset (low QIR), Pinecone’s serverless model with no idle compute cost is attractive. If you’re doing high-frequency queries (high QIR), per-query billing becomes punitive and self-hosted Qdrant with no per-query fees wins on cost. This is the metric vendor pricing pages are designed to obscure.
Are you above 100M vectors? If yes, you need Milvus’s distributed architecture or a very well-tuned pgvector setup. Below 20M vectors, Milvus’s distributed overhead is overkill. Between 20M and 100M is the decision zone where workload characteristics, filtering complexity, and latency requirements determine the winner.
The framework I’d use: start with pgvector if you run Postgres. Graduate to Qdrant when you need better filtering or lower latency at scale. Choose Weaviate when hybrid search quality is your core differentiator. Move to Milvus when you exceed 100M vectors and have Kubernetes expertise. Choose Pinecone only when zero operational burden outweighs cost efficiency and you can accept permanent vendor lock-in.
One open question worth tracking: as AlloyDB and other managed Postgres providers accelerate pgvector performance, does the pgvector scale ceiling move from 50M to 100M+ vectors? If it does, the purpose-built vector database market narrows considerably — and the scale cliff economics that currently justify Qdrant and Milvus may shift in ways that reshape the entire comparison.