This page describes how costs are incurred in Pinecone. For the latest pricing details, see Pricing.
The Standard and Enterprise pricing plans include a monthly minimum usage committment:
Plan | Minimum usage |
---|---|
Standard | $50/month |
Enterprise | $500/month |
Beyond the monthly minimum, customers are charged for what they use each month.
Examples
Usage below monthly minimum
In this case, the August invoice would include line items for each service you used (totaling $20), plus a single line item covering the rest of the minimum usage commitment ($30).
Usage exceeds monthly minimum
In this case, the August invoice would only show line items for each service you used (totaling $100). Since your usage exceeds the minimum usage commitment, you are only charged for your actual usage and no additional minimum usage line item appears on your invoice.
Customers who signed up for the Standard or Enteprise plan before July 1, 2025 will continue to pay a monthly platform fee until September 1, 2025. After that date, the minimum usage commitment explained above will replace the platform fee.
Plan | Platform fee | Usage credits |
---|---|---|
Standard | $25/month | $15/month |
Enterprise | $500/month | $150/month |
Usage credits do not roll over from month to month. Platform fees do not apply to organizations on the Starter plan or with annual commits.
With serverless indexes, you pay for the amount of data stored and operations performed, based on three usage metrics: read units, write units, and storage.
For the latest serverless pricing rates, see Pricing.
Read units (RUs) measure the compute, I/O, and network resources consumed by the following read requests:
Read requests return the number of RUs used. You can use this information to monitor read costs.
The cost of a query scales linearly with the size of the targeted namespace. Specifically, a query uses 1 RU for every 1 GB of namespace size, with a minimum of 0.25 RUs per query.
For example, the following table contains the RU cost of searching indexes at different namespace sizes:
Records | Dense dimension | Avg. metadata size | Avg. record size | Namespace size | RUs |
---|---|---|---|---|---|
500,000 | 768 | 500 bytes | 3.57 KB | 1.78 GB | 1.78 |
1,000,000 | 1536 | 1000 bytes | 7.14 KB | 7.14 GB | 7.14 |
5,000,000 | 1024 | 15,000 bytes | 19.10 KB | 95.5 GB | 95.5 |
10,000,000 | 1536 | 1000 bytes | 7.14 KB | 71.4 GB | 71.4 |
Records | Dense dimension | Avg. metadata size | Avg. record size | Namespace size | RUs |
---|---|---|---|---|---|
500,000 | 768 | 500 bytes | 3.57 KB | 1.78 GB | 1.78 |
1,000,000 | 1536 | 1000 bytes | 7.14 KB | 7.14 GB | 7.14 |
5,000,000 | 1024 | 15,000 bytes | 19.10 KB | 95.5 GB | 95.5 |
10,000,000 | 1536 | 1000 bytes | 7.14 KB | 71.4 GB | 71.4 |
Records | Sparse non-zero values | Avg. metadata size | Avg. record size | Namespace size | RUs |
---|---|---|---|---|---|
500,000 | 10 | 500 bytes | 0.09 KB | 0.045 GB | 0.25 |
1,000,000 | 50 | 1000 bytes | 1.45 KB | 1.45 GB | 1.45 |
5,000,000 | 100 | 15,000 bytes | 15.9 KB | 79.5 GB | 79.5 |
10,000,000 | 50 | 1000 bytes | 1.45 KB | 14.5 GB | 14.5 |
Records | Dense dimension | Sparse non-zero values | Avg. metadata size | Avg. record size | Namespace size | RUs |
---|---|---|---|---|---|---|
500,000 | 768 | 10 | 500 bytes | 3.67 KB | 1.83 GB | 1.83 |
1,000,000 | 1536 | 50 | 1000 bytes | 7.34 KB | 7.34 GB | 7.34 |
5,000,000 | 1024 | 100 | 15,000 bytes | 19.44 KB | 97.2 GB | 97.2 |
10,000,000 | 1536 | 50 | 1000 bytes | 7.34 KB | 73.4 GB | 73.4 |
Parameters that affect the size of the query response, such as top_k
, include_metadata
, and include_values
, are not relevant for query cost; only the size of the namespace determines the number of RUs used.
A fetch request uses 1 RU for every 10 records fetched, for example:
Fetched records | RUs |
---|---|
10 | 1 |
50 | 5 |
107 | 11 |
Specifying a non-existent ID or adding the same ID more than once does not increase the number of RUs used. However, a fetch request will always use at least 1 RU.
List has a fixed cost of 1 RU per call, with up to 100 records per call.
Write units (WUs) measure the storage and compute resources used by the following write requests:
An upsert request uses 1 WU for each 1 KB of the request, with a minimum of 5 WUs per request. When an upsert modifies an existing record, the request uses 1 WU for each 1 KB of the existing record as well.
For example, the following table shows the WUs used by upsert requests at different batch sizes and record sizes, assuming all records are new:
Records per batch | Dimension | Avg. metadata size | Avg. record size | WUs |
---|---|---|---|---|
1 | 768 | 100 bytes | 3.2 KB | 5 |
2 | 768 | 100 bytes | 3.2 KB | 7 |
10 | 1024 | 15,000 bytes | 19.10 KB | 191 |
100 | 768 | 500 bytes | 3.57 KB | 357 |
1000 | 1536 | 1000 bytes | 7.14 KB | 7140 |
An update requests uses 1 WU for each 1 KB of the new and existing record, with a minimum of 5 WUs per request.
For example, the following table shows the WUs used by an update at different record sizes:
New record size | Previous record size | WUs |
---|---|---|
6.24 KB | 6.50 KB | 13 |
19.10 KB | 15 KB | 25 |
3.57 KB | 5 KB | 9 |
7.14 KB | 10 KB | 18 |
3.17 KB | 3.17 KB | 7 |
A delete requests uses 1 WU for each 1 KB of the records deleted, with a minimum of 5 WUs per request.
For example, the following table shows the WUs used by delete requests at different batch sizes and record sizes:
Records per batch | Dimension | Avg. metadata size | Avg. record size | WUs |
---|---|---|---|---|
1 | 768 | 100 bytes | 3.2 KB | 5 |
2 | 768 | 100 bytes | 3.2 KB | 7 |
10 | 1024 | 15,000 bytes | 19.10 KB | 191 |
100 | 768 | 500 bytes | 3.57 KB | 357 |
1000 | 1536 | 1000 bytes | 7.14 KB | 7140 |
Specifying a non-existent ID or adding the same ID more than once does not increase WU use.
Deleting a namespace or deleting all records in a namespace using deleteAll
uses 5 WUs.
Storage costs are based on the size of an index on a per-Gigabyte (GB) monthly rate. For the latest storage pricing rates, see Pricing.
The size of an index is defined as the total size of its records across all namespaces.
The size of a single record is defined as the sum of the following components:
Sparse vector size is relevant only for sparse indexes and hybrid indexes.
The following tables demonstrate index sizes at different record counts:
Records | Dense dimension | Avg. metadata size | Avg. record size | Namespace size |
---|---|---|---|---|
500,000 | 768 | 500 bytes | 3.57 KB | 1.78 GB |
1,000,000 | 1536 | 1000 bytes | 7.14 KB | 7.14 GB |
5,000,000 | 1024 | 15,000 bytes | 19.10 KB | 95.5 GB |
10,000,000 | 1536 | 1000 bytes | 7.14 KB | 71.4 GB |
Records | Dense dimension | Avg. metadata size | Avg. record size | Namespace size |
---|---|---|---|---|
500,000 | 768 | 500 bytes | 3.57 KB | 1.78 GB |
1,000,000 | 1536 | 1000 bytes | 7.14 KB | 7.14 GB |
5,000,000 | 1024 | 15,000 bytes | 19.10 KB | 95.5 GB |
10,000,000 | 1536 | 1000 bytes | 7.14 KB | 71.4 GB |
Records | Sparse non-zero values | Avg. metadata size | Avg. record size | Namespace size |
---|---|---|---|---|
500,000 | 10 | 500 bytes | 0.09 KB | 0.045 GB |
1,000,000 | 50 | 1000 bytes | 1.45 KB | 1.45 GB |
5,000,000 | 100 | 15,000 bytes | 15.9 KB | 79.5 GB |
10,000,000 | 50 | 1000 bytes | 1.45 KB | 14.5 GB |
Records | Dense dimension | Sparse non-zero values | Avg. metadata size | Avg. record size | Namespace size |
---|---|---|---|---|---|
500,000 | 768 | 10 | 500 bytes | 3.67 KB | 1.83 GB |
1,000,000 | 1536 | 50 | 1000 bytes | 7.34 KB | 7.34 GB |
5,000,000 | 1024 | 100 | 15,000 bytes | 19.44 KB | 97.2 GB |
10,000,000 | 1536 | 50 | 1000 bytes | 7.34 KB | 73.4 GB |
For each pod-based index, billing is determined by the per-minute price per pod and the number of pods the index uses, regardless of index activity. The per-minute price varies by pod type, pod size, account plan, and cloud region. For the latest pod-based index pricing rates, see Pricing.
Total cost depends on a combination of factors:
The following equation calculates the total costs accrued over time:
To see a calculation of your current usage and costs, go to Settings > Usage in the Pinecone console.
Example
While our pricing page lists rates on an hourly basis for ease of comparison, this example lists prices per minute, as this is how Pinecone calculates billing.
An example application has the following requirements:
top_k
= 10Based on these requirements, the organization chooses to configure the project to use the Standard billing plan to host one p1.x2
pod with three replicas and a collection containing 1 GB of data. This project runs continuously for the month of January on the Standard plan. The components of the total cost for this example are given in Table 1 below:
Table 1: Example billing components
Billing component | Value |
---|---|
Number of pods | 1 |
Number of replicas | 3 |
Pod size | x2 |
Total pod count | 6 |
Minutes in January | 44,640 |
Pod-minutes (pods * minutes) | 267,840 |
Pod price per minute | $0.0012 |
Collection storage | 1 GB |
Collection storage minutes | 44,640 |
Price per storage minute | $0.00000056 |
The invoice for this example is given in Table 2 below:
Table 2: Example invoice
Product | Quantity | Price per unit | Charge |
---|---|---|---|
Collections | 44,640 | $0.00000056 | $0.025 |
P2 Pods (AWS) | 0 | $0.00 | |
P2 Pods (GCP) | 0 | $0.00 | |
S1 Pods | 0 | $0.00 | |
P1 Pods | 267,840 | $0.0012 | $514.29 |
Amount due $514.54
Importing from object storage is the most efficient and cost-effective method to load large numbers of records into an index. The cost of an import is based on the size of the records read, whether the records were imported successfully or not.
If the import operation fails (e.g., after encountering a vector of the wrong dimension in an import with on_error="abort"
), you will still be charged for the records read. However, if the import fails because of an internal system error, you will not incur charges. In this case, the import will return the error message "We were unable to process your request. If the problem persists, please contact us at https://support.pinecone.io"
.
For the latest import pricing rates, see Pricing.
A backup is a static copy of a serverless index. Both the cost of storing a backup and restoring an index from a backup is based on the size of the index. For the latest backup and restore pricing rates, see Pricing.
Pinecone hosts several embedding models so it’s easy to manage your vector storage and search process on a single platform. You can use a hosted model to embed your data as an integrated part of upserting and querying, or you can use a hosted model to embed your data as a standalone operation.
Embedding costs are determined by how many tokens are in a request. In general, the more words contained in your passage or query, the more tokens you generate.
For example, if you generate embeddings for the query, “What is the maximum diameter of a red pine?”, Pinecone Inference generates 10 tokens, then converts them into an embedding. If the price per token for your billing plan is $.08 per million tokens, then this API call costs $.00001.
To learn more about tokenization, see Choosing an embedding model. For the latest embed pricing rates, see Pricing.
Embedding requests returns the total tokens generated. You can use this information to monitor and manage embedding costs.
Pinecone hosts several reranking models so it’s easy to manage two-stage vector retrieval on a single platform. You can use a hosted model to rerank results as an integrated part of a query, or you can use a hosted model to rerank results as a standalone operation.
Reranking costs are determined by the number of requests to the reranking model. For the latest rerank pricing rates, see Pricing.
For details on how costs are incurred in Pinecone Assistant, see Assistant pricing.
This page describes how costs are incurred in Pinecone. For the latest pricing details, see Pricing.
The Standard and Enterprise pricing plans include a monthly minimum usage committment:
Plan | Minimum usage |
---|---|
Standard | $50/month |
Enterprise | $500/month |
Beyond the monthly minimum, customers are charged for what they use each month.
Examples
Usage below monthly minimum
In this case, the August invoice would include line items for each service you used (totaling $20), plus a single line item covering the rest of the minimum usage commitment ($30).
Usage exceeds monthly minimum
In this case, the August invoice would only show line items for each service you used (totaling $100). Since your usage exceeds the minimum usage commitment, you are only charged for your actual usage and no additional minimum usage line item appears on your invoice.
Customers who signed up for the Standard or Enteprise plan before July 1, 2025 will continue to pay a monthly platform fee until September 1, 2025. After that date, the minimum usage commitment explained above will replace the platform fee.
Plan | Platform fee | Usage credits |
---|---|---|
Standard | $25/month | $15/month |
Enterprise | $500/month | $150/month |
Usage credits do not roll over from month to month. Platform fees do not apply to organizations on the Starter plan or with annual commits.
With serverless indexes, you pay for the amount of data stored and operations performed, based on three usage metrics: read units, write units, and storage.
For the latest serverless pricing rates, see Pricing.
Read units (RUs) measure the compute, I/O, and network resources consumed by the following read requests:
Read requests return the number of RUs used. You can use this information to monitor read costs.
The cost of a query scales linearly with the size of the targeted namespace. Specifically, a query uses 1 RU for every 1 GB of namespace size, with a minimum of 0.25 RUs per query.
For example, the following table contains the RU cost of searching indexes at different namespace sizes:
Records | Dense dimension | Avg. metadata size | Avg. record size | Namespace size | RUs |
---|---|---|---|---|---|
500,000 | 768 | 500 bytes | 3.57 KB | 1.78 GB | 1.78 |
1,000,000 | 1536 | 1000 bytes | 7.14 KB | 7.14 GB | 7.14 |
5,000,000 | 1024 | 15,000 bytes | 19.10 KB | 95.5 GB | 95.5 |
10,000,000 | 1536 | 1000 bytes | 7.14 KB | 71.4 GB | 71.4 |
Records | Dense dimension | Avg. metadata size | Avg. record size | Namespace size | RUs |
---|---|---|---|---|---|
500,000 | 768 | 500 bytes | 3.57 KB | 1.78 GB | 1.78 |
1,000,000 | 1536 | 1000 bytes | 7.14 KB | 7.14 GB | 7.14 |
5,000,000 | 1024 | 15,000 bytes | 19.10 KB | 95.5 GB | 95.5 |
10,000,000 | 1536 | 1000 bytes | 7.14 KB | 71.4 GB | 71.4 |
Records | Sparse non-zero values | Avg. metadata size | Avg. record size | Namespace size | RUs |
---|---|---|---|---|---|
500,000 | 10 | 500 bytes | 0.09 KB | 0.045 GB | 0.25 |
1,000,000 | 50 | 1000 bytes | 1.45 KB | 1.45 GB | 1.45 |
5,000,000 | 100 | 15,000 bytes | 15.9 KB | 79.5 GB | 79.5 |
10,000,000 | 50 | 1000 bytes | 1.45 KB | 14.5 GB | 14.5 |
Records | Dense dimension | Sparse non-zero values | Avg. metadata size | Avg. record size | Namespace size | RUs |
---|---|---|---|---|---|---|
500,000 | 768 | 10 | 500 bytes | 3.67 KB | 1.83 GB | 1.83 |
1,000,000 | 1536 | 50 | 1000 bytes | 7.34 KB | 7.34 GB | 7.34 |
5,000,000 | 1024 | 100 | 15,000 bytes | 19.44 KB | 97.2 GB | 97.2 |
10,000,000 | 1536 | 50 | 1000 bytes | 7.34 KB | 73.4 GB | 73.4 |
Parameters that affect the size of the query response, such as top_k
, include_metadata
, and include_values
, are not relevant for query cost; only the size of the namespace determines the number of RUs used.
A fetch request uses 1 RU for every 10 records fetched, for example:
Fetched records | RUs |
---|---|
10 | 1 |
50 | 5 |
107 | 11 |
Specifying a non-existent ID or adding the same ID more than once does not increase the number of RUs used. However, a fetch request will always use at least 1 RU.
List has a fixed cost of 1 RU per call, with up to 100 records per call.
Write units (WUs) measure the storage and compute resources used by the following write requests:
An upsert request uses 1 WU for each 1 KB of the request, with a minimum of 5 WUs per request. When an upsert modifies an existing record, the request uses 1 WU for each 1 KB of the existing record as well.
For example, the following table shows the WUs used by upsert requests at different batch sizes and record sizes, assuming all records are new:
Records per batch | Dimension | Avg. metadata size | Avg. record size | WUs |
---|---|---|---|---|
1 | 768 | 100 bytes | 3.2 KB | 5 |
2 | 768 | 100 bytes | 3.2 KB | 7 |
10 | 1024 | 15,000 bytes | 19.10 KB | 191 |
100 | 768 | 500 bytes | 3.57 KB | 357 |
1000 | 1536 | 1000 bytes | 7.14 KB | 7140 |
An update requests uses 1 WU for each 1 KB of the new and existing record, with a minimum of 5 WUs per request.
For example, the following table shows the WUs used by an update at different record sizes:
New record size | Previous record size | WUs |
---|---|---|
6.24 KB | 6.50 KB | 13 |
19.10 KB | 15 KB | 25 |
3.57 KB | 5 KB | 9 |
7.14 KB | 10 KB | 18 |
3.17 KB | 3.17 KB | 7 |
A delete requests uses 1 WU for each 1 KB of the records deleted, with a minimum of 5 WUs per request.
For example, the following table shows the WUs used by delete requests at different batch sizes and record sizes:
Records per batch | Dimension | Avg. metadata size | Avg. record size | WUs |
---|---|---|---|---|
1 | 768 | 100 bytes | 3.2 KB | 5 |
2 | 768 | 100 bytes | 3.2 KB | 7 |
10 | 1024 | 15,000 bytes | 19.10 KB | 191 |
100 | 768 | 500 bytes | 3.57 KB | 357 |
1000 | 1536 | 1000 bytes | 7.14 KB | 7140 |
Specifying a non-existent ID or adding the same ID more than once does not increase WU use.
Deleting a namespace or deleting all records in a namespace using deleteAll
uses 5 WUs.
Storage costs are based on the size of an index on a per-Gigabyte (GB) monthly rate. For the latest storage pricing rates, see Pricing.
The size of an index is defined as the total size of its records across all namespaces.
The size of a single record is defined as the sum of the following components:
Sparse vector size is relevant only for sparse indexes and hybrid indexes.
The following tables demonstrate index sizes at different record counts:
Records | Dense dimension | Avg. metadata size | Avg. record size | Namespace size |
---|---|---|---|---|
500,000 | 768 | 500 bytes | 3.57 KB | 1.78 GB |
1,000,000 | 1536 | 1000 bytes | 7.14 KB | 7.14 GB |
5,000,000 | 1024 | 15,000 bytes | 19.10 KB | 95.5 GB |
10,000,000 | 1536 | 1000 bytes | 7.14 KB | 71.4 GB |
Records | Dense dimension | Avg. metadata size | Avg. record size | Namespace size |
---|---|---|---|---|
500,000 | 768 | 500 bytes | 3.57 KB | 1.78 GB |
1,000,000 | 1536 | 1000 bytes | 7.14 KB | 7.14 GB |
5,000,000 | 1024 | 15,000 bytes | 19.10 KB | 95.5 GB |
10,000,000 | 1536 | 1000 bytes | 7.14 KB | 71.4 GB |
Records | Sparse non-zero values | Avg. metadata size | Avg. record size | Namespace size |
---|---|---|---|---|
500,000 | 10 | 500 bytes | 0.09 KB | 0.045 GB |
1,000,000 | 50 | 1000 bytes | 1.45 KB | 1.45 GB |
5,000,000 | 100 | 15,000 bytes | 15.9 KB | 79.5 GB |
10,000,000 | 50 | 1000 bytes | 1.45 KB | 14.5 GB |
Records | Dense dimension | Sparse non-zero values | Avg. metadata size | Avg. record size | Namespace size |
---|---|---|---|---|---|
500,000 | 768 | 10 | 500 bytes | 3.67 KB | 1.83 GB |
1,000,000 | 1536 | 50 | 1000 bytes | 7.34 KB | 7.34 GB |
5,000,000 | 1024 | 100 | 15,000 bytes | 19.44 KB | 97.2 GB |
10,000,000 | 1536 | 50 | 1000 bytes | 7.34 KB | 73.4 GB |
For each pod-based index, billing is determined by the per-minute price per pod and the number of pods the index uses, regardless of index activity. The per-minute price varies by pod type, pod size, account plan, and cloud region. For the latest pod-based index pricing rates, see Pricing.
Total cost depends on a combination of factors:
The following equation calculates the total costs accrued over time:
To see a calculation of your current usage and costs, go to Settings > Usage in the Pinecone console.
Example
While our pricing page lists rates on an hourly basis for ease of comparison, this example lists prices per minute, as this is how Pinecone calculates billing.
An example application has the following requirements:
top_k
= 10Based on these requirements, the organization chooses to configure the project to use the Standard billing plan to host one p1.x2
pod with three replicas and a collection containing 1 GB of data. This project runs continuously for the month of January on the Standard plan. The components of the total cost for this example are given in Table 1 below:
Table 1: Example billing components
Billing component | Value |
---|---|
Number of pods | 1 |
Number of replicas | 3 |
Pod size | x2 |
Total pod count | 6 |
Minutes in January | 44,640 |
Pod-minutes (pods * minutes) | 267,840 |
Pod price per minute | $0.0012 |
Collection storage | 1 GB |
Collection storage minutes | 44,640 |
Price per storage minute | $0.00000056 |
The invoice for this example is given in Table 2 below:
Table 2: Example invoice
Product | Quantity | Price per unit | Charge |
---|---|---|---|
Collections | 44,640 | $0.00000056 | $0.025 |
P2 Pods (AWS) | 0 | $0.00 | |
P2 Pods (GCP) | 0 | $0.00 | |
S1 Pods | 0 | $0.00 | |
P1 Pods | 267,840 | $0.0012 | $514.29 |
Amount due $514.54
Importing from object storage is the most efficient and cost-effective method to load large numbers of records into an index. The cost of an import is based on the size of the records read, whether the records were imported successfully or not.
If the import operation fails (e.g., after encountering a vector of the wrong dimension in an import with on_error="abort"
), you will still be charged for the records read. However, if the import fails because of an internal system error, you will not incur charges. In this case, the import will return the error message "We were unable to process your request. If the problem persists, please contact us at https://support.pinecone.io"
.
For the latest import pricing rates, see Pricing.
A backup is a static copy of a serverless index. Both the cost of storing a backup and restoring an index from a backup is based on the size of the index. For the latest backup and restore pricing rates, see Pricing.
Pinecone hosts several embedding models so it’s easy to manage your vector storage and search process on a single platform. You can use a hosted model to embed your data as an integrated part of upserting and querying, or you can use a hosted model to embed your data as a standalone operation.
Embedding costs are determined by how many tokens are in a request. In general, the more words contained in your passage or query, the more tokens you generate.
For example, if you generate embeddings for the query, “What is the maximum diameter of a red pine?”, Pinecone Inference generates 10 tokens, then converts them into an embedding. If the price per token for your billing plan is $.08 per million tokens, then this API call costs $.00001.
To learn more about tokenization, see Choosing an embedding model. For the latest embed pricing rates, see Pricing.
Embedding requests returns the total tokens generated. You can use this information to monitor and manage embedding costs.
Pinecone hosts several reranking models so it’s easy to manage two-stage vector retrieval on a single platform. You can use a hosted model to rerank results as an integrated part of a query, or you can use a hosted model to rerank results as a standalone operation.
Reranking costs are determined by the number of requests to the reranking model. For the latest rerank pricing rates, see Pricing.
For details on how costs are incurred in Pinecone Assistant, see Assistant pricing.