Skip to main content
Operation limits are restrictions on the size, number, or other characteristics of operations in Pinecone. Operation limits are fixed and don’t vary based on pricing plan. If one of these limits is blocking you, contact Support with details about your use case. There’s often a workaround.

​
Upsert limits

The limit for text is lower because Pinecone converts that text to vectors at upsert time with integrated embedding, and 96 is the max batch size of the hosted embedding models doing the conversion. The 40 KB filterable metadata limit doesn’t apply to full_text_search text fields.

​
Import limits

If your import exceeds these limits, you’ll get an error specifying the limit exceeded. See Troubleshooting for details.
The total input data size limit does not apply to indexes with dedicated read nodes. Bulk import supports indexes without a schema definition (Parquet files) and indexes with document schemas (JSONL files). Semantic-text (auto-embedded) fields are not yet supported in document schemas.

​
Query limits

The query result size is affected by the dimension of the dense vectors and whether or not dense vector values and metadata are included in the result.
If a query fails due to exceeding the 4MB result size limit, choose a lower top_k value, or use include_metadata=False or include_values=False to exclude metadata or values from the result. For better performance, especially with higher top_k values, avoid including vector values unless you need them.

​
Fetch limits

Fetch by ID limits: Fetch by metadata limits: To retrieve more than 10,000 matching records, paginate through results using the paginationToken parameter. See Fetch records by metadata.

​
Delete limits

​
Metadata filter limits

The following limits apply to metadata filter expressions used in query, delete, update, and fetch operations. When you exceed this limit, the request returns a 400 - BAD_REQUEST error.

​
Rationale

Large $in operators can impact query performance and cost. Filters with thousands of values increase request payload size and end-to-end latency. Additionally, using large filters typically indicates a shared namespace architecture, which increases query costs. Queries scan the entire namespace regardless of filters.

​
Alternative approaches

If you need to filter by more than 10,000 values, consider these alternatives:
  • Use namespaces for tenant isolation: Instead of filtering by tenant IDs within a single namespace, create separate namespaces for each tenant or tenant group. This can also reduce query costs. See Design for multi-tenancy.
  • Use broader access control groups: Instead of filtering by individual user IDs, filter by organization, project, or role. This reduces the number of values in your $in filter. See Design for multi-tenancy.
  • Post-filter client-side: Retrieve a larger top K without filtering (for example, top 1000), then filter results client-side.
  • Run multiple queries: Split your filter into multiple queries with smaller $in operators and combine the results client-side.
To avoid hitting this limit in production, validate the size of your $in and $nin arrays in your application code before making the request to Pinecone.