Migrate a pod-based index to serverless

This page shows you how to migrate a pod-based index to serverless using the Pinecone console.

If you have questions about this process, or run into any issues, contact Pinecone Support.

​

Benefits

Serverless indexes have many advantages over pod-based indexes, including:

• Up to 50x reduced cost through the separation of reads, writes, and storage.
• Usage-based pricing ensures you are charged only for what you use, with no minimum fees.
• No capacity planning or management; serverless indexes scale automatically based on usage.

Also note that the migration process is free; the standard costs of upserting records to a new serverless index are not applied.

​

Limitations

• Serverless migration is limited to pod-based indexes with less than 25 million records and 20,000 namespaces.
• The pod-based indexes must be hosted on AWS or GCP. It is not currently possible to migrate pod-based indexes on Azure.
• The migration process creates serverless indexes on AWS only, regardless of the cloud where the pod-based indexes are hosted. This means that pod-based indexes on GCP will be migrated to serverless indexes on AWS.

If you are blocked by any of these limits, contact Pinecone Support.

​

How it works

Migrating a pod-based index to serverless is a 2-step process:

After migration, you will have both a new serverless index and the original pod-based index. Once you’ve switched your workload to the serverless index, you can delete the pod-based index to avoid paying for unused resources.

​

1. Prepare for migration

Migrating a pod-based index to serverless can take anywhere from a few minutes to several hours, depending on the size of the index. During that time, you can continue reading from the pod-based index. However, all upserts, updates, and deletes to the pod-based index will not automatically be reflected in the new severless index, so be sure to prepare in one of the following ways:

• Pause write traffic: If downtime is acceptable, pause traffic to the pod-based index before starting migration. After migration, you will start sending traffic to the serverless index.

• Log your writes: If you need to continue reading from the pod-based index during migration, send read traffic to the pod-based index, but log your writes to a temporary location outside of Pinecone (e.g., S3). After migration, you will replay the logged writes to the new serverless index and start sending all traffic to the serverless index.

​

2. Start migration

1. In the Pinecone console, go to your pod-based index and select Migrate to serverless:

   
   The dropdown will not display Migrate to serverless if the index has any of the listed limitations.

2. To save the legacy index and create a new serverless index now, follow the prompts.

   Depending on the size of the index, migration can take anywhere from a few minutes to several hours. While migration is in progress, you’ll see the yellow Initializing status:

   

   When the new serverless index is ready, the status will change to green:

   

​

3. Update clients

If you are using an older version of the Python, Node.js, or Java client, you must update the client to work with serverless indexes.

1. Check your client version:

2. If your client version is less than 3.0.0 for Python, 2.0.0 for Node.js, or 1.0.0 for Java, upgrade the client as follows:

​

4. Adapt existing code

You must make some minor code changes to work with serverless indexes.

1. Change how you import the Pinecone library and authenticate and initialize the client:

2. Listing indexes now fetches a complete description of each index. If you were relying on the output of this operation, you’ll need to adapt your code.

3. Describing an index now returns a description of an index in a different format. It also returns the index endpoint needed to run data plane operations against the index. If you were relying on the output of this operation, you’ll need to adapt your code.

4. Serverless indexes do not support the following features. If you were relying on these features for your pod-based index, you’ll need to adapt your code.

   • Creating collections from serverless indexes

   • Migrating pod-based indexes to serverless indexes

     • Serverless migration is limited to pod-based indexes with less than 25 million records and 20,000 namespaces.
     • The pod-based indexes must be hosted on AWS or GCP. It is not currently possible to migrate pod-based indexes on Azure.
     • The migration process creates serverless indexes on AWS only, regardless of the cloud where the pod-based indexes are hosted. This means that pod-based indexes on GCP will be migrated to serverless indexes on AWS.

   • Deleting records by metadata

     • Instead, you can delete records by ID prefix.

   • Selective metadata indexing

     • Because high-cardinality metadata in serverless indexes does not cause high memory utilization, this operation is not relevant.

   • Configuring indexes

     • Because serverless indexes scale automatically based on usage, this operation is not relevant

   • Filtering index statistics by metadata

   • Metrics

   • Private endpoints

     • This feature is available on AWS only.

​

5. Use your new index

When you’re ready to cutover to your new serverless index:

1. Your new serverless index has a different name and unique endpoint than your pod-based index. Update your code to target the new serverless index:

2. Reinitialize your clients.

3. If you logged writes to the pod-based index during migration, replay the logged writes to your serverless index.

4. Delete the pod-based index to avoid paying for unused resources.

   It is not possible to save a serverless index as a collection, so if you want to retain the option to recreate your pod-based index, be sure to keep the collection you created earlier.

​

See also

• Quotas and limits
• Serverless architecture
• Understanding serverless cost