Pinecone Free Tier Limits in 2026: What You Actually Get
By Ergini, Software & AI Developer
TL;DR
Pinecone's free Starter plan gives you 2 GB of storage, up to 5 indexes with 100 namespaces each, 2 million write units and 1 million read units per month, in the AWS us-east-1 region only, on one project with up to two users. At 1536 dimensions that works out to roughly 300,000 vectors, which is comfortably enough to prototype and usually not enough to launch. The limit that actually catches people is read units rather than storage, because a chatty application burns through them long before the 2 GB fills.
The limits, as of August 2026
Pinecone's free plan is called Starter. Here is what it includes. These figures were checked in August 2026; Pinecone revises its plans periodically, so confirm against their current documentation before making a decision that depends on an exact number.
| Limit | Starter (free) |
|---|---|
| Storage | 2 GB |
| Indexes | Up to 5 |
| Namespaces per index | 100 |
| Write units | 2 million per month, reset monthly |
| Read units | 1 million per month, reset monthly |
| Region | AWS us-east-1 only |
| Projects and users | 1 project, up to 2 users |
What 2 GB means in vectors
Roughly 300,000 vectors at 1536 dimensions, which is what OpenAI text-embedding-3-small produces and therefore the most common case. The relationship is close to linear in dimensions, so the same 2 GB holds roughly twice as many 768-dimension vectors and roughly half as many 3072-dimension ones.
Two things inflate storage beyond the naive calculation. Metadata counts toward the total, so if you are storing the source text alongside each vector, which is good practice, that text is consuming your quota. And indexes carry overhead of their own, so five small indexes hold less total data than one large one.
This is also a good moment to check whether you need 1536 dimensions at all. Several current embedding models support dimension truncation, so you can cut the vector size and roughly double your capacity for a small and measurable loss in retrieval quality. The mechanics are covered in how to choose an embedding model.
Read units are the limit that actually bites
This is the part people get wrong, so it is worth stating carefully. Read units and write units are consumption metrics, not request counts. A query consumes read units in proportion to how much data it has to scan, which means a query against a large namespace is more expensive than the identical query against a small one.
The consequence is that 1 million read units per month is emphatically not 1 million queries. Depending on your index size and query pattern it might be a small fraction of that. Teams size themselves against the 2 GB storage ceiling, conclude they have plenty of headroom, and then run out of read units two weeks into the month with a mostly-empty index.
The failure is also badly timed. It tends to arrive during a demo or a first burst of real traffic, because that is when query volume spikes. If you intend to put the free tier in front of anyone, model read units before you model storage.
Three constraints beyond the quotas
Region lock. Starter runs in AWS us-east-1 and nowhere else. If you have any EU data residency requirement, the free tier is not an option and no amount of quota headroom changes that. This is the single most common reason my European clients cannot prototype on it, and it is worth discovering before you have loaded a corpus rather than after. It usually pushes the conversation toward an EU-resident architecture from the start.
Hard stop, not graceful degradation. Quotas reset monthly. Exceeding them stops the operation rather than slowing it, so your application errors instead of getting sluggish. Build for that, which mostly means handling the error path deliberately rather than assuming the vector store is always available.
No support commitment. Reasonable for a free tier, and worth naming, because it is one more reason the Starter plan is a prototyping environment and not a production one.
When you outgrow it
Three options, and the one people skip is usually the cheapest.
Upgrade Pinecone. Least work, and reasonable if the product is working and you value not touching the data layer while you grow. You are paying for managed operations, which is a legitimate purchase.
Move to pgvector. If you already run Postgres, and most applications do, pgvector often costs less than the next Pinecone tier while removing an entire service from your architecture. Below a few million vectors it performs perfectly well, and hybrid search comes almost free because Postgres full-text search is right there. The full comparison is in pgvector vs Pinecone, and it is the option I recommend most often, including on self-hosted EU deployments where the region lock rules Pinecone out anyway.
Move to a different managed vector database. Several have more generous entry tiers or better regional coverage. Worth comparing if you want managed operations but Pinecone's pricing or regions do not fit. The landscape is covered in the vector database comparison.
Frequently asked questions
What are the Pinecone free tier limits?
2 GB storage, up to 5 indexes with 100 namespaces each, 2 million write units and 1 million read units per month, AWS us-east-1 only, 1 project with up to 2 users. Verified August 2026.
How many vectors fit?
Around 300,000 at 1536 dimensions, scaling close to linearly with dimension count. Metadata counts toward the 2 GB.
What is a read unit?
A consumption metric proportional to how much data a query scans, not a count of queries. One million read units is not one million queries.
Which limit is hit first?
Read units, nearly always, and usually during a demo or a first burst of real traffic rather than gradually.
Can I run production on it?
Not sensibly. The us-east-1 region lock, the hard monthly quota stop, and the absence of a support commitment make it a prototyping environment.
Bottom line
The Pinecone free tier is a good prototyping environment and a poor production one. Size yourself on read units rather than storage, check the us-east-1 region lock against your compliance requirements before you load anything, and when you outgrow it, price pgvector on Postgres you already run before you assume the upgrade is the obvious next step.