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

Migration is supported for pod-based indexes on GCP and AWS with less than 25 million records and 20,000 namespaces. This is a limitation of the current migration tool, not Pinecone’s serverless architecture, which provides virtually limitless data scalability.

This feature is in public preview.

Limitations

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. If you are blocked by these limitations, contact Pinecone Support.

Depending on your usage of the SDK, there may be other changes to make. For a comprehensive list, see the Python SDK v3 migration guide, Node.js SDK v2 migration guide, or Java SDK v1 migration guide.

Benefits

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

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

How it works

To migrate a pod-based index to serverless, you just click a few buttons in the Pinecone console, but behind-the-scenes, it’s a 2-step process:

1

Save the pod-based index as a collection

2

Create a new serverless index from the collection

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 click ellipsis (…) menu > 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 SDKs

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

  1. Check your SDK version:

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

    If you are using the .NET SDK, add a package reference to your project file:

    C#
    dotnet add package Pinecone.Client 
    

4. Adapt existing code

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

Serverless indexes do not support some features, as outlined in Limitations. If you were relying on these features for your pod-based index, you’ll need to adapt your code.

  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.

    The list_indexes operation now returns a response like the following:

  3. Describing an index now returns a description of an index in a different format. It also returns the index host 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.

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