This page shows you how to configure an existing index.

For serverless indexes, you can configure only index deletion protection. For pod-based indexes, you can configure the pod size, number of replicas, and index deletion protection.

It is not possible to change the pod type of an index. However, you can create a collection from an index and then create a new index with a different pod type from the collection.

Change pod sizes

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.

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

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.

To check the status of a pod size change, use the describe_index endpoint. 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

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.

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 endpoint 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

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.

Since high-cardinality metadata does not cause high memory utilization in serverless indexes, selective metadata indexing is not supported.

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.

Prevent index deletion

When configuring a serverless or pod-based index, you can protect the index from accidental deletion by setting the deletion_protection parameter to enabled. For more details, see Prevent index deletion.

Tag an index

When configuring an index, you can tag the index to help with index organization and management. For more details, see Tag an index.