Costs

This page describes how costs are incurred in Pinecone for both serverless and pod-based indexes.

Pinecone pricing is always done on a per-index basis, not per project or account. So, if you run more than one index in a project, you’ll be charged for each based on its size or usage. For the latest pricing details, please see our pricing page.

​

Serverless indexes

With serverless indexes, you don’t configure or manage any compute or storage resources. Instead, based on a breakthough 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: You’re billed for the size of an index on a per-GB rate, with the exact rate of each unit determined based on your cloud provider, region, and plan (see our pricing page).

​

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 RU. This additional cost is a factor of the size of the namespace you search and the number of non-zero sparse dimensions. For example, for sparse vectors with 100 non-zero sparse dimensions, approximate RU consumed for sparse and dense vectors combined 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 clustered index to reflect its addition.

The following operations consume WUs:

• Upsert
• Update
• Delete

​

Upsert

The number of WUs used by an upsert request is proportional to the total size of records it writes and/or modifies, with a minimum of 1 WU.

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

​

Update

The number of WUs used when updating a record is proportional to the total size of the new or previous version of the record, whichever is larger, 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 or previous metadata size, whichever is larger:

​

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 an entire namespace using the deleteAll flag always consumes 1 WU.

​

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

​

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