Pinecone Pricing in 2026: What You Actually Pay

Pinecone is the vector database most retrieval-augmented-generation (RAG) apps reach for first, and its pricing is quietly one of the most misread meters in the AI stack. The rates look small. The bill often is not. This is a worked teardown of what Pinecone actually costs in 2026, with three real 30-day bills and the one design decision that moves the number more than anything else.

How Pinecone pricing works in 2026

Pinecone serverless is usage-based. You pay for what you store and what you read and write, on top of a plan floor. Here are the current plans (Pinecone pricing, 2026).

On Standard, the pay-as-you-go rates are the ones that decide your bill:

• Read units: $16 per million
• Write units: $4 per million
• Storage: $0.33 per GB per month
• Egress: $0.10 per GB after the first 100 GB

Enterprise raises the unit rates (reads run $24 to $27 per million, writes $6 to $6.75) in exchange for an SLA and dedicated read nodes. Most teams live on Standard, so every bill below uses Standard rates.

The word "minimum" matters. On Standard, if your metered usage lands at $18 for the month, you are billed $50. The floor is a floor, not a credit.

The part nobody explains: reads scale with namespace size, not query count

This is where most Pinecone estimates go wrong. A read unit is not "one query." Per Pinecone's own docs, a query costs one read unit for every 1 GB of namespace size, with a floor of 0.25 read units per query (Pinecone docs, understanding cost, 2026).

Read that again. The cost of a search is set by how big the namespace is, not by how many results you ask for. top_k, include_metadata, and include_values do not change the read-unit count. A top_k=1 query and a top_k=100 query against the same 10 GB namespace both cost 10 read units.

Writes work differently: one write unit per 1 KB of the upsert request, with a floor of 5 write units per request. Pinecone's own example: a single 768-dimension record (about 3.2 KB) costs 5 write units; a batch of 100 such records costs 357 write units total. Bigger vectors and fatter metadata mean more KB per record, which means more write units.

So the two levers on your bill are:

1. Namespace size in GB (drives every read).
2. How much data you write, and how well you batch it (drives every write).

Neither is your raw query count. That is the trap.

Three real Pinecone bills (worked math)

Let me price three concrete workloads. Assume 768-dimension embeddings at roughly 3.2 KB per stored record unless noted, which is Pinecone's own reference size.

Bill 1: the hobby RAG app runs free

You scraped 20,000 documents, chunked them into 200,000 vectors, and you run a personal search bot.

• Storage: 200,000 x 3.2 KB = about 0.64 GB. Under the 2 GB free ceiling.
• Index build (one time): 200,000 records, batched 100 per request = 2,000 upsert requests x 357 WU = 714,000 write units. Under the 2M free monthly writes.
• Queries: 3,000 per month. Namespace is 0.64 GB, so each query costs 0.64 RU. 3,000 x 0.64 = 1,920 read units. Under the 1M free monthly reads.

Monthly cost: $0. A genuinely small RAG project fits the free Starter tier and pays nothing. This is the honest good-news case, and it is why Pinecone still shows up in so many side projects.

The catch is the cliff. The moment you cross any single free ceiling (2 GB storage, 1M reads, 2M writes, or 1 GB egress) you cannot buy a small overage. You move to Standard and its $50 minimum, or to the $20 Builder plan if you fit its wider ceilings. There is no smooth $3 step. That jump is exactly what people mean on Reddit when they say the new minimum "nuked my hobby project."

Bill 2: the production single-corpus RAG app

Now a real product: a support assistant over one shared knowledge base.

• 3,000,000 chunks at 1536 dimensions (OpenAI text-embedding-3-small), about 6.5 KB each. Storage: 3M x 6.5 KB = about 20 GB, in one namespace because every question searches the whole corpus.
• Storage: 20 GB x $0.33 = $6.60
• Reads: 300,000 queries per month (about 10,000 per day). The namespace is 20 GB, so each query costs 20 RU. 300,000 x 20 = 6,000,000 read units x $16 per million = $96.00
• Writes: refresh 300,000 chunks per month. 300,000 / 100 per batch = 3,000 requests x 650 WU (100 records x 6.5 KB) = 1,950,000 write units x $4 per million = $7.80

Metered total: $6.60 + $96.00 + $7.80 = $110.40 per month. Well over the $50 floor, so you are billed about $110.

Look at the split: reads are 87 percent of the bill, and they scale with corpus size. Double the corpus to 40 GB and those same 300,000 queries cost $192 in reads, with no change in traffic. Your users did nothing different. Your index got bigger.

Bill 3: the multi-tenant SaaS at 50 million vectors

A B2B product where every customer searches only their own documents.

• 2,000 tenants x 25,000 vectors each = 50,000,000 vectors at 768 dimensions. Each tenant gets its own namespace of about 0.08 GB.
• Storage: 50M x 3.2 KB = about 160 GB x $0.33 = $52.80
• Reads: 2,000,000 queries per month, each scoped to one 0.08 GB namespace. That is below the 0.25 RU floor, so each query costs the 0.25 RU minimum. 2M x 0.25 = 500,000 read units x $16 per million = $8.00
• Writes: 1,000,000 records updated per month. 1M / 100 = 10,000 requests x 357 WU = 3,570,000 write units x $4 per million = $14.28

Metered total: $52.80 + $8.00 + $14.28 = $75.08 per month for 50 million vectors and 2 million monthly queries.

Now the same data with a single mistake. Put all 50 million vectors in one 160 GB namespace and every query costs 160 RU. 2,000,000 x 160 = 320,000,000 read units x $16 per million = $5,120 per month in reads alone. Same vectors, same traffic, a 640x swing in the read bill. The architecture is the pricing.

Effective cost per 1,000 queries, by namespace size

Here is the whole read model on one line. Standard reads are $16 per million read units, and a query costs one RU per GB of the namespace it hits.

A search against a 100 GB namespace costs 400 times what the same search costs against a 0.25 GB namespace. If you remember one row from this article, remember this table.

The cheaper lever: design your namespaces

Because reads are priced by namespace GB, your query design changes the bill more than any discount does.

1. Partition into small namespaces whenever queries are naturally scoped. Per tenant, per project, per document set. Bill 3 is the proof: scoping turned a potential $5,120 read bill into $8.
2. If you have one shared corpus that every query must search in full, you cannot partition it away. Shrink the GB instead: use a smaller embedding dimension (a 768-dim or Matryoshka-truncated 512-dim vector roughly halves storage and the read bill versus 1536-dim), or quantize. Test recall before and after; smaller vectors can cost accuracy.
3. Cache identical and popular queries in your own app. A repeated question you answer from cache is a read unit you never pay Pinecone.
4. Batch upserts at 100-plus records per request so you amortize the 5-WU floor. Thousands of one-record upserts waste that floor on every call.
5. For steady, large, predictable workloads, ask about committed-use contracts on Standard or Enterprise before you just eat pay-as-you-go.

None of these are tricks. They are the difference between a bill that tracks your data and a bill that tracks your mistakes.

Where Pinecone loses, and the alternatives worth pricing

Pinecone's honest weak spot in 2026 is the low end. The $50 Standard minimum means a project doing $6 of real work can owe $50, and the free-to-paid cliff is abrupt. That is why the vector-database subreddits are full of migration posts (r/vectordatabase, 2026).

If the minimum stings, price these against your own numbers:

Qdrant, Weaviate, and Zilliz (managed Milvus) all offer cost-controlled managed and self-hosted paths at scale (Qdrant Cloud pricing, 2026). pgvector, the Postgres extension, is the pragmatic pick for small-to-mid workloads when you already run a SQL database; if you are pricing a serverless Postgres to host it, our neon-pricing-2026 teardown does the same worked-bill math for Neon. And since most RAG bills are really two meters, the vector store plus the embedding calls, pair this with our openai-api-pricing-2026 breakdown before you commit. Chroma remains the easy local-and-dev default.

Pinecone still wins on operational simplicity and query latency at scale, which is a real reason teams pay the floor. Just make sure you are paying it because the ops savings are worth $50-plus, not because a single un-partitioned namespace quietly turned your read bill into rent.