Understanding cost

This page describes how costs are incurred for Pinecone Database, Pinecone Inference, and Pinecone Assistant.

Pinecone Database pricing is calculated on a per-index basis, not per project or organization; if you run more than one index in a project, you’ll be charged for each index based on its size or usage. Likewise, Pinecone Assistant pricing is calculated on a per-assistant basis. Pinecone Inference pricing is based on usage.

For the latest pricing details, please see our pricing page.

​

Platform fee

Your plan determines the features, quotas, support, and usage credits you have access to. Aside from your platform subscription fee, all Pinecone usage is pay-as-you-go for only what you use.

Please note that usage credits do not roll over from month to month. Platform fees do not apply to organizations with annual commitments.

​

Serverless indexes

With serverless indexes, you don’t configure or manage any compute or storage resources. Instead, based on a breakthrough architecture, serverless indexes scale automatically based on usage, and you pay only for the amount of data stored and operations performed, based on three usage metrics:

• Read units (RUs): Read units measure the resources consumed by read operations such as query, fetch, and list.

• Write units (WUs): Write units measure the resources used by write operations such as upsert, update, and delete.

• Storage: The size of an index on a per-Gigabyte (GB) hourly rate.

​

Read units

Read operations consume read units (RUs). Read units measure the compute, I/O, and network resources used during the read process.

The following operations consume RUs:

• Fetch
• Query
• List

The number of RUs used by a specific request is always included in its response. For a demonstration of how to use read units to inspect read costs, see this notebook.

​

Fetch

A fetch request uses 1 RU for every 10 fetched records.

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.

​

Query

The number of RUs used by a query is proportional to the following factors:

• Record count: The number of vectors contained in the target index. Only vectors stored in the relevant namespace are used.
• Record size: Higher dimensionality or larger metadata increases the size of each scanned vector.

Because serverless indexes organize vectors in similarity-based clusters, only a fraction of each index will be read for each query. The number of RUs a query uses therefore increases much more slowly than the index size.

The following table contains the RU cost of a query at different namespace sizes and record dimensionality, assuming an average metadata size around 500 bytes:

Scanning a namespace has a minimal cost of 5 RUs.

When either include_metadata or include_values are specified, an internal fetch call retrieves the full record values for the IDs returned in the initial scan. This stage consumes RUs equal to a matching fetch call - 1 RU per 10 records in the result set.

Hybrid retrieval searches over more data and incurs additional RUs. This additional cost is a factor of the size of the namespace you search and the number of non-zero sparse dimensions. Similar costs are incurred for sparse-only searches. For example, for sparse vectors with 100 non-zero sparse dimensions, approximate RUs consumed for sparse vectors are as follows:

​

List

List has a fixed cost of 1 RU per call, with an additional 1 RU per paginated call.

​

Write units

Write operations consume write units (WUs). Write units measure the storage and compute resources used to persist a record, make it available for querying, and update the index to reflect its addition.

The following operations consume WUs:

• Upsert
• Update
• Delete

​

Upsert

When upserting a new record, the number of WUs used is proportional to the total size of the record, with a minimum of 1 WU. When an upsert modifies an existing record, the number of WUs used is proportional to the total size of both the new and previous versions of the record.

The following table contains the WU cost of an upsert request at different batch sizes and record dimensionality, assuming all records are new and have an average metadata size around 500 bytes:

​

Update

The number of WUs used when updating a record is proportional to the total size of both the new and previous versions of the record, with a minimum of 1 WU.

The following table contains the WU cost of an update request at different dimensionalities and metadata sizes, with WUs based on the new and previous metadata size:

​

Delete

The number of WUs used by a delete request is proportional to the total size of records it deletes, with a minimum of 1 WU.

The following table contains the WU cost of a delete request at different batch sizes and record dimensionality, assuming an average metadata size around 500 bytes:

Specifying a non-existent ID or adding the same ID more than once does not increase WU use.

Deleting all records in a namespace using the deleteAll flag always consumes 1 WU.

​

Imports and storage

The size of an index is defined as the total size of its vectors across all namespaces. The size of a single vector is defined as the sum of three components:

• ID size
• Embedding size (equal to 4 times the vector’s dimensions)
• Total metadata size (equal to the total size of all metadata fields)

The following table demonstrates a typical index size at different vector counts and dimensionality:

​

Monitoring usage

• Index-level monitoring: In the Pinecone console, you can track usage and performance metrics for each index.

• Operation-level monitoring: The response to read operations like query, fetch, and list include the number of read units consumed.

​

Pod-based indexes

​

Cost calculation

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.

Total cost depends on a combination of factors:

• Pod type. Each pod type has different per-minute pricing.
• Number of pods. This includes replicas, which duplicate pods.
• Pod size. Larger pod sizes have proportionally higher costs per minute.
• Total pod-minutes. This includes the total time each pod is running, starting at pod creation and rounded up to 15-minute increments.
• Cloud provider. The cost per pod-type and pod-minute varies depending on the cloud provider you choose for your project.
• Collection storage. Collections incur costs per GB of data per minute in storage, rounded up to 15-minute increments.
• Plan. The free plan incurs no costs; the Standard or Enterprise plans incur different costs per pod-type, pod-minute, cloud provider, and collection storage.

The following equation calculates the total costs accrued over time:

(Number of pods) * (pod size) * (number of replicas) * (minutes pod exists) * (pod price per minute) 
+ (collection storage in GB) * (collection storage time in minutes) * (collection storage price per GB per minute)

To see a calculation of your current usage and costs, go to Settings > Usage in the Pinecone console.

​

Pricing

For pod-based index pricing rates, see our pricing page.

​

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:

• 1,000,000 vectors with 1536 dimensions
• 150 queries per second with top_k = 10
• Deployment in an EU region
• Ability to store 1GB of inactive vectors

Based 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

The invoice for this example is given in Table 2 below:

Table 2: Example invoice

Amount due $514.54

​

Pinecone Inference

Pinecone Inference is a service that gives you access to embedding models and reranking models hosted on Pinecone’s infrastructure.

​

Embed

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 up-to-date embed pricing, see Pricing.

​

Rerank

Reranking costs are determined by the number of requests to the reranking model. For up-to-date rerank pricing, see Pricing.

​

Pinecone Assistant

The cost of using Pinecone Assistant is determined by the following factors:

See Pricing for up-to-date pricing information.

​

Cost controls

Pinecone offers tools to help you understand and control your costs.

• Monitoring usage. You can use the usage dashboard in the Pinecone console to monitor your Pinecone usage and costs as these accrue.

• Pod limits. For pod-based indexes, project owners can set limits for the total number of pods across all indexes in the project. The default pod limit is 5.

​

See also

• Monitoring usage
• Managing cost
• Pricing