Pinecone Quota Tiers and Limits (2026): Starter, Standard, and Enterprise

The most common support question about Pinecone's free tier is not about capacity — it is about the seven-day inactivity pause. If no read or write operations are made against a Starter index for seven consecutive days, Pinecone automatically pauses the index. The index is not deleted; your vectors and metadata are preserved. However, all queries and upserts will return an error until you manually resume the index through the console or API.

The practical consequence for developers is that a demo application, a side project, or a staging environment that goes unused over a long weekend can silently stop working. Monitoring that checks index health periodically will catch this, but many teams do not add that check until after they have already experienced an unexpected outage. The Pinecone console shows a 'Paused' badge on affected indexes, but if you are not actively watching the console, the first signal is usually a 503 or a 'Index not ready' error in your application logs.

There are two reliable prevention strategies. The first is a lightweight keep-alive script — a cron job that issues a trivial query (such as a nearest-neighbor search for a single dummy vector) every five or six days. This resets the inactivity timer without consuming meaningful quota. The second is simply upgrading to Standard before your application goes into production; Standard accounts have no inactivity policy. If your project is genuinely experimental and you want to stay on Starter, the keep-alive cron is the correct answer. There is no setting in the Pinecone console to disable the inactivity policy on a free account.

Pinecone's serverless architecture, which became the default in 2024 and is the only recommended architecture for new projects as of 2026, bills on three dimensions: storage consumed (GB-months), write units (WU) consumed during upserts and updates, and read units (RU) consumed during queries. Understanding each dimension separately is important because the dominant cost driver varies significantly by workload type.

Storage is straightforward: you pay $0.33 per GB-month. A 768-dimensional float32 vector occupies roughly 3 KB of raw vector data. One million such vectors require approximately 3 GB of raw storage, which translates to about $1.00/month in storage costs alone. However, Pinecone stores metadata alongside vectors, and metadata storage is included in the same GB-month rate. If your metadata averages 1 KB per vector, one million vectors add another 1 GB of storage cost. The actual bill also reflects index overhead, which Pinecone does not fully document but which empirical measurements suggest adds 20-40% to raw vector size.

Write units are charged at $0.33 per one million units. A single upsert of a 768-dimensional vector with modest metadata consumes approximately one write unit, though the exact definition of a write unit is tied to vector dimensions and payload size in ways that Pinecone documents at a high level rather than with a precise formula. For teams doing bulk initial indexing, this cost is typically incurred once and is relatively small — indexing one million vectors at one WU each costs $0.33. Ongoing writes from a production pipeline that indexes a few thousand new documents per day add negligible cost. Read units are the more significant ongoing expense at $8.25 per one million units. A single top-k=10 query against a 768-dimensional index consumes roughly one read unit, meaning one million daily queries would cost $8.25/day or roughly $250/month. Teams with high query volume should model this carefully before assuming serverless is cheaper than the legacy pod model. The vector DB cost calculator provides a side-by-side estimate.

One practical note: serverless read unit costs are sensitive to top-k values and metadata filter complexity. A query with a tight metadata filter that eliminates most of the index will generally consume fewer read units than a broad scan. Pinecone's documentation recommends using metadata filters aggressively to reduce both latency and cost, which is good architectural advice independent of budget concerns.

Pinecone namespaces are a partitioning mechanism within a single index. Each namespace operates as an isolated sub-index: upserts, queries, and deletes within a namespace do not cross namespace boundaries unless you explicitly query across namespaces. The common use cases for namespaces include multi-tenant SaaS applications (one namespace per tenant), document-type segregation (one namespace for product manuals, another for support tickets), and A/B testing of embedding models (old embeddings in namespace A, new embeddings in namespace B during a migration window).

The Starter tier caps namespaces at 200 per index. For single-tenant applications or small multi-tenant systems, this limit is irrelevant. However, SaaS products that provision one namespace per customer will hit this ceiling at 200 customers — a point that many early-stage founders do not anticipate. When a 201st namespace creation is attempted on a Starter account, the API returns an error rather than silently truncating or consolidating. This means the failure is detectable but disruptive if it reaches production without a guard.

Standard and Enterprise accounts have no documented namespace limit. Pinecone's internal architecture handles namespaces efficiently because they share the same underlying index structure; adding a namespace does not provision new compute resources. The practical ceiling on Standard is a function of your index's overall size and query patterns rather than a hard quota. Teams building multi-tenant systems should plan their namespace strategy with the RAG architecture decision tree in mind — namespaces solve tenant isolation cleanly, but they are not the right tool for completely separating embedding model versions across large-scale indexes where a separate index-per-model-version approach may be preferable.

Every vector in Pinecone can carry an associated metadata payload — an arbitrary JSON object stored alongside the embedding. This metadata is used for both display (returning source text or document IDs in query results) and filtering (restricting queries to vectors that match specific metadata conditions). The hard limit is 40 KB of metadata per vector. This is generous for most RAG use cases where metadata contains document identifiers, short text snippets, and categorical labels, but teams that attempt to store full document text in metadata will hit this ceiling.

A more subtle limit applies to indexed metadata fields. Pinecone distinguishes between metadata fields that are indexed (available for filtering in queries) and fields that are stored but not indexed (returned in results but not filterable). Not all metadata fields are automatically indexed; Pinecone uses a selective indexing approach that affects query performance and storage overhead. The documentation recommends configuring the `metadata_config` on index creation to specify which fields will be indexed, and notes that indexing too many fields — particularly high-cardinality string fields — can degrade query performance and increase storage costs.

A common mistake is storing large text chunks in metadata under the assumption that this avoids the need for a separate document store. This works at small scale but creates two problems: metadata payloads approaching the 40KB limit will cause upsert failures for longer documents, and large metadata payloads increase the cost of both write and read operations. The standard production pattern for RAG systems is to store only identifiers and short filter-relevant attributes in Pinecone metadata, and retrieve full document content from a separate store (PostgreSQL, S3, or Redis) keyed on the document ID returned by Pinecone. This architecture is covered in detail in the RAG with Pinecone tutorial.

Pinecone originally offered only pod-based indexes, where you paid for reserved compute capacity sized by pod type (s1, p1, p2) and pod count. Pod-based indexes offered predictable latency and cost but required upfront sizing decisions, and scaling required manual pod resizing or index recreation. As of 2026, Pinecone classifies pod-based indexes as a legacy architecture and does not recommend them for new projects. Serverless is the current standard for all new index creation.

The key differences between the two architectures matter for teams still running pod-based indexes or evaluating a migration. Pod-based indexes bill per hour regardless of query volume — a p1.x1 pod costs a fixed monthly amount whether you run one query or one million. Serverless bills purely on consumption. For low-query-volume applications that maintain large indexes (such as internal knowledge bases with infrequent but high-value queries), pod pricing could be lower than serverless. However, Pinecone has not published a sunset date for pod-based indexes, and teams on pods should track announcements from Pinecone carefully. Continuing to build new features on a deprecated architecture is a technical debt decision that should be deliberate, not accidental.

Migration from pod to serverless is not a one-click operation. It requires creating a new serverless index, re-upserting all vectors (which incurs write unit costs), re-pointing application queries to the new index endpoint, and validating query results for consistency. For indexes with tens of millions of vectors, this migration can take hours and requires careful coordination to avoid serving stale results during the cutover. Pinecone's documentation provides migration tooling, but there is no zero-downtime migration path available through the API alone — blue-green index strategies (writing to both old and new during migration) are the standard approach for production systems.

Pinecone's Enterprise tier is a custom-priced contract that removes the constraints of Standard and adds compliance, security, and deployment flexibility features. The most operationally significant additions are: a documented uptime SLA (Standard provides an SLA, but Enterprise SLAs include stronger remedies and more granular commitments), SOC 2 Type II certification documentation available for vendor reviews, and BYOC (Bring Your Own Cloud) deployment.

BYOC is the feature that unlocks Pinecone for organizations with data residency requirements. Under BYOC, Pinecone's control plane manages the service orchestration, but the actual vector data and index storage runs within the customer's own AWS, GCP, or Azure account. This means vector data never leaves the customer's cloud tenancy. It satisfies the data residency and data sovereignty requirements that appear in GDPR Article 46 DPA clauses, HIPAA BAAs, and FedRAMP-adjacent workloads. Note that BYOC is not the same as self-hosting — the control plane and management layer remain Pinecone-operated; only the data plane runs in your cloud. Organizations that need fully air-gapped, fully self-managed deployments (government classified environments, for example) should evaluate Pinecone's on-premises offering or alternatives like Qdrant Private Cloud.

Enterprise pricing is negotiated directly with Pinecone's sales team and is not published. Based on community reports and sales materials, entry-level Enterprise contracts typically start well above the Standard consumption pricing for equivalent workloads. The value proposition is not cost reduction but rather compliance certification, dedicated support response times, and BYOC. If your organization does not have a legal or compliance requirement driving the decision, Standard with support tickets is usually adequate. If a security review or a data processing agreement requires documented SOC 2 or SLA remedies, Enterprise is the only tier that provides them.

All figures in this document are sourced from pinecone.io/pricing and docs.pinecone.io/reference/quotas-and-limits, last verified in June 2026. Pinecone has updated pricing and limits several times in the past two years — the move from pod-based to serverless billing changed the fundamental pricing model, and specific unit prices (per-GB storage, per-million read units, per-million write units) have been adjusted. The figures here were accurate at time of writing, but should be confirmed against the official pricing page before making procurement decisions.

The 40KB metadata limit, the 200-namespace Starter cap, and the seven-day inactivity pause are all documented in Pinecone's official limits reference and have been stable across multiple documentation versions. The serverless unit pricing ($0.33/GB-month, $0.33/M write units, $8.25/M read units) reflects the current published rates but is the most likely figure to have changed if you are reading this significantly after June 2026. The enterprise pricing section deliberately contains no specific dollar figures because Pinecone does not publish them and any third-party estimate would be unreliable.

Pinecone's changelog and status page (status.pinecone.io) are the authoritative sources for limit changes. For teams building systems with hard dependencies on specific Pinecone limits, subscribing to Pinecone's changelog or monitoring their documentation RSS feed is worthwhile. Limit increases are generally announced with advance notice; limit reductions or deprecations (like the pod-based architecture transition) have historically come with longer lead times.