Vector database cost: Pinecone, Weaviate, and pgvector at scale

Vector Storage Stopped Being Free

In 2024 the vector database was a curiosity. In 2025 it was a feature. In 2026 it is a cost line. Every product team that has shipped semantic search, RAG-backed chat, document Q&A, or recommendation systems is now running embedding workloads continuously, storing the resulting vectors somewhere, and querying them on every user request. The bill for that storage and that query path has grown faster than the bill for the model inference behind it, because inference is metered and indexed storage is not.

The 2026 vector-database market has five real options at scale: Pinecone (managed, serverless, the cost-leader story), Weaviate (open-source-and-managed, hybrid-search positioning), Qdrant (open-source-and-managed, performance-positioning), Milvus / Zilliz (open-source-and-managed, scale-positioning), and pgvector (Postgres extension, “your existing database” positioning). They all scale; they scale at very different prices; and the cost difference at production-RAG volume is large enough that the choice is a CFO-visible decision in 2026.

Here is the cost-optimization playbook for vector storage at scale, the per-vendor pricing structure that drives the bill, and the cost-agent pattern that keeps the bill from running away during an embedding regression.

What Drives the Bill: The Five Cost Levers

Five technical decisions move vector-database cost more than anything else. Most teams optimize one or two and leave the others on default.

Dimensionality. A 1536-dimensional vector (OpenAI text-embedding-3-small, default) costs three times the storage of a 512-dimensional vector and roughly three times the index build time. The 2026 generation of embedding models supports configurable dimensionality (Matryoshka representation learning) at minimal recall cost. Teams running 1536-d embeddings on text-embedding-3-small for retrieval that does not need the full dimensionality are paying three-times-required storage. Drop to 512-d or 768-d after measuring recall, and the cost drops proportionally.

Quantization. Float-32 vectors are the default; float-16 cuts storage in half at negligible recall cost; binary quantization (one bit per dimension) cuts storage by 32x with a meaningful recall drop that is recoverable with a re-rank step. Pinecone serverless, Weaviate, and Qdrant all support binary quantization with a re-rank pass in 2026. The cost-and-recall trade is now a tunable, not an architectural decision.

Index type. HNSW (hierarchical navigable small world) is the default everywhere because it is fast and recall-accurate; it also has the highest memory overhead. IVF-PQ (inverted file with product quantization) is dramatically cheaper at the cost of recall and tuning complexity. Disk-resident indexes (DiskANN, the Pinecone serverless storage tier) are cheaper still and excellent for cold or rarely-queried data. The right answer is usually a tiered index — HNSW for hot, DiskANN or IVF-PQ for cold — but most teams run HNSW for everything because the cost differential was not visible in the bill until 2026.

Vector count and shard topology. Pinecone serverless prices on storage and read/write units; Weaviate, Qdrant, and Milvus on cluster infrastructure plus replicated storage. The cost per million vectors looks similar at small scale; at 100M+ vectors the cluster-priced options start to win on per-unit cost, and at 1B+ vectors the gap widens further. The inflection point depends on query volume more than vector count.

Query volume and freshness. A read-heavy, eventual-consistency RAG workload is structurally cheap on Pinecone serverless because reads are metered. A write-heavy workload (continuous re-indexing of changing documents) is structurally cheap on a self-hosted cluster because writes are not metered. The crossover point is the freshness requirement: how stale can the index be? Teams that can tolerate ten-minute staleness can batch updates and unlock dramatically lower cost across all five vendors.

See the IAN team run on your cloud. We connect to your AWS account via a scoped read-only role, run the Observe-tier agents, and leave you with a concrete audit report — cost waste, security exposure, compliance gaps, and a labor-offset estimate. You keep the findings regardless of next steps. Get a free infrastructure audit →

The Five-Vendor 2026 Pricing Landscape

Pinecone (serverless). The 2024 serverless launch reframed Pinecone’s cost story from “expensive on dedicated pods” to “cheapest-at-low-scale, predictable-at-high-scale.” Read units, write units, storage GB, all metered. Strong fit for read-heavy RAG workloads with predictable query patterns; weaker fit for write-heavy continuous-ingestion workloads. The 2026 Pinecone bill shape has fewer surprises than the 2023 dedicated-pod bill, but cost-attribution by application or tenant still requires careful namespace usage.

Weaviate. Strongest hybrid-search story (vector + BM25 fused) and competitive pricing on the managed cloud product. The self-hosted option remains the cheapest-per-vector at scale among the open-source competitors when the platform team has the operational capacity. Strong fit for hybrid retrieval; weaker on pure-vector throughput at the very top end.

Qdrant. Performance-positioning, written in Rust, strong on the latency-and-throughput envelope. Managed cloud is competitive; self-hosted is excellent for teams that already run a Rust-friendly platform. Strong fit for low-latency-required workloads; less ecosystem breadth than Weaviate or Pinecone.

Milvus / Zilliz. Scale-positioning, the standard answer for billion-vector workloads. Zilliz Cloud (managed Milvus) competes with Pinecone serverless at the high end. Strong fit for very large vector counts; over-engineered for sub-100M-vector workloads.

pgvector (Postgres extension). The 2024-2025 maturation of pgvector — HNSW index support, parallel index build, performance improvements that closed the gap with dedicated vector DBs — made “just use Postgres” a real production answer for most teams under 100M vectors. The cost story is “you are already paying for Postgres.” Strong fit for teams whose existing data lives in Postgres and who are not at the very top of the scale curve; weaker at billion-vector scale and very high query throughput.

The decision in 2026 is rarely between the most expensive and the cheapest option. It is between two or three viable options whose cost differs by 2-5x at the team’s actual scale. The cost-optimization win comes from picking the right one and tuning the five levers, not from switching vendors after the fact.

The pgvector vs. Managed Vector DB Inflection Point

The most consequential vector-database decision a team makes in 2026 is whether to run pgvector on the existing Postgres or to adopt a dedicated vector database. The inflection point has moved up considerably.

Stay on pgvector when:

• Total vector count is under 10M (well within pgvector’s comfort zone in 2026).
• Query volume is under ~50 QPS sustained.
• Vector workloads are application-attached (per-tenant filters, joined to relational data, transactional consistency required).
• Platform team has Postgres operational maturity.

Move to a dedicated vector DB when:

• Total vector count crosses 100M and query latency starts to drift.
• Hybrid search (vector + lexical fused with rich scoring) is a first-class requirement and pgvector’s current hybrid story is insufficient.
• Vector workload has materially different scaling characteristics from the rest of the database (write spikes during re-indexing, read spikes during product launches) and is hurting Postgres performance for everything else.
• Cost of running Postgres large enough to host the vector workload has grown to the point that a dedicated vector DB is cheaper than upsizing Postgres.

The 10M-to-100M range is the gray zone. The right answer there depends more on operational maturity and team preference than on any technical factor. Teams that pick pgvector in this range tend to stay there longer than they expected; teams that pick a dedicated vector DB in this range tend to discover the operational tax was bigger than the perceived savings. Both are defensible.

The AI-Feature Cost-Attribution Problem

Vector-database cost is the easy part of AI-feature cost attribution. The hard part is the full stack: the embedding-model inference cost, the LLM inference cost on retrieval-augmented prompts, the vector storage, the vector query cost, the re-rank pass cost, and the supporting data infrastructure. A single user-facing AI feature in 2026 has five-to-seven cost components, attributable to the feature only if the platform team has the attribution discipline.

The pattern that works:

• Tag every embedding job with the feature, the tenant, and the model used. Embedding cost attributes cleanly when the tags are consistent.
• Tag every vector index and namespace with the feature and tenant. Storage cost attributes cleanly when the namespacing is consistent.
• Tag every retrieval query with the feature and tenant via metadata filters. Query cost attributes cleanly when the metadata is consistent.
• Tag every LLM call with the feature, tenant, and prompt version. Inference cost attributes cleanly when the LLM client is wrapped at the application boundary.

The four tagging disciplines are not optional; they are the precondition for any AI-feature cost-attribution work. Teams that try to back-fill attribution after the fact spend more time on the back-fill than they would have spent on the discipline up front.

What an Active Cost Agent Adds on Top

The vector-database bill is volatile in a way that traditional infrastructure bills are not. A re-indexing job that should have batched 1M vectors batches 100M instead because a config flag flipped. A new feature ships and the embedding cost goes from $200/day to $4,000/day overnight because the team did not realize a default model dimensionality changed. A namespace fills up and the storage tier silently scales.

An active cost agent watches the vector-DB bill the same way it watches the cloud bill, and acts on the same active-operational-layer pattern:

• Continuous attribution. Re-runs the per-feature, per-tenant cost allocation hourly across the full AI stack (embedding inference + vector storage + query cost + LLM inference). Cost regressions are noticed in hours, not invoice cycles.
• Regression detection. When a tenant’s allocated cost jumps, the agent investigates the cause — new embedding job deployed, dimensionality change, query-volume spike, namespace bloat — and produces a rooted summary, not a “your AI cost went up” alert.
• Reversible cleanup, autonomous. Right-sizing oversized index configs, applying TTL on dev-environment vector namespaces, pausing test embedding jobs left running. The savings show up on the next bill.
• Irreversible cleanup, gated. Deleting production vector namespaces, decommissioning indexes, changing tenant tier — always escalates to the human approver with full context.
• Cost-attribution dashboard. Generated from the agent’s own attribution graph, not maintained by hand.

The Three-Phase Rollout

Phase 1 — Get attribution right. Tag embedding jobs, indexes, namespaces, queries, and LLM calls consistently with feature and tenant. Stand up a per-feature cost dashboard against the existing vector-DB billing export. One to four weeks for an existing AI workload.

Phase 2 — Tune the five cost levers. Measure recall-vs-cost on dimensionality, quantization, and index type for each feature. Move workloads to the appropriate vendor for their read/write/freshness shape. Expect 30-60% cost reduction at this phase for most teams that have not tuned before.

Phase 3 — Layer the cost agent. Continuous attribution across the full AI stack, regression detection, autonomous reversible cleanup. The win compounds as the agent learns the team’s AI workload patterns and the workload patterns themselves stabilize.

How IAN Helps

IAN’s cost agent runs continuous attribution against vector databases the same way it runs continuous attribution against the rest of the cloud bill — Pinecone, Weaviate, Qdrant, Milvus / Zilliz, and pgvector workloads all attributed by feature and tenant in one place. The active operational layer pattern applies: agents do the right-sizing, the lifecycle, and the regression investigation; humans approve the irreversible cleanup; the audit trail is the artifact.

Because IAN is BYOK on the model side, the agent operating against a customer’s vector workload uses the customer’s existing Claude or model contract for any inference it does on behalf of the cost-attribution analysis. The AI-stack cost-optimization work that used to be a half-FTE on the platform team becomes a continuous service running in the background, with the cost-attribution dashboard generated as a side effect of the agent’s attribution graph.

Get a free infrastructure audit → | See pricing →