This guidance applies to pod-based indexes only. With serverless indexes, you don’t configure any compute or storage resources, and you don’t manually manage those resources to meet demand, save on cost, or ensure high availability. Instead, serverless indexes scale automatically based on usage.

This page shows you how to change pod sizes, check the status of a pod size change, add replicas, and configure selective metadata indexing.

To learn about the concepts related to indexes, see Indexes.

​
Change pod sizes

The default pod size is x1. After index creation, you can increase the pod size for an index.

Increasing the pod size of your index does not result in downtime. Reads and writes continue uninterrupted during the scaling process. Currently, you cannot reduce the pod size of your indexes. Your number of replicas and your total number of pods remain the same, but each pod changes size. Resizing completes in about 10 minutes.

To change the pod size of an existing index, use the configure_index operation and append the new size to the pod_type parameter, separated by a period (.).

Example

The following example assumes that example-index has size x1 and changes the size to x2.

​
Check the status of a pod size change

To check the status of a pod size change, use the describe_index operation. The status field in the results contains the key-value pair "state":"ScalingUp" or "state":"ScalingDown" during the resizing process and the key-value pair "state":"Ready" after the process is complete.

The index fullness metric provided by describe_index_stats may be inaccurate until the resizing process is complete.

Example

The following example uses describe_index to get the index status of the index example-index. The status field contains the key-value pair "state":"ScalingUp", indicating that the resizing process is still ongoing.

​
Add replicas

You can increase the number of replicas for your pod-based index to increase throughput (QPS). All pod-based indexes start with replicas=1.

Example

The following example uses the configure_index operation to set the number of replicas for the index example-index to 4.

See the configure_index API reference for more details.

​
Selective metadata indexing

Serverless and starter indexes do not support selective metadata indexing. For fast operations on subsets of records in serverless indexes, use ID prefixes.

For pod-based indexes, Pinecone indexes all metadata fields by default. When metadata fields contains many unique values, pod-based indexes will consume significantly more memory, which can lead to performance issues, pod fullness, and a reduction in the number of possible vectors that fit per pod.

To avoid indexing high-cardinality metadata that is not needed for filtering your queries and keep memory utilization low, specify which metadata fields to index using the metadata_config parameter.

The value for the metadata_config parameter is a JSON object containing the names of the metadata fields to index.

JSON
{
    "indexed": [
        "metadata-field-1",
        "metadata-field-2",
        "metadata-field-n"
    ]
}

Example

The following example creates a pod-based index that only indexes the genre metadata field. Queries against this index that filter for the genre metadata field may return results; queries that filter for other metadata fields behave as though those fields do not exist.

Was this page helpful?