Vespa Cloud This content is applicable to Vespa Cloud deployments.

Reindexing on Vespa Cloud

When the indexing pipeline of an application changes, Vespa may need to reindex stored data so the index reflects the new specification. On Vespa Cloud this is handled for you: reindexing is enabled and started automatically as part of your deployment, and you can follow, pause, resume, re-trigger, and tune it from the Vespa Cloud console. There is no need to call the reindex endpoint and redeploy manually as you would in a self-managed deployment.

This page describes the Vespa Cloud workflow. See Reindexing for the underlying concepts, reindexing states, and schema-change use cases that apply to all deployments.

How reindexing is triggered

When you deploy a change that requires reindexing (see changes that require reindexing for the full list), Vespa Cloud enables and starts reindexing automatically once the deployment has converged on the new configuration. This replaces the manual procedure in a self-managed deployment, where reindexing is enabled through the reindex endpoint and started with another redeployment.

Only the stored document fields are re-fed; all derived fields are recomputed. Reindexing runs in the background, but how much it affects the cluster depends on the available resources and the current load. You control this trade-off with the reindexing speed: a lower speed uses fewer resources and has less impact on concurrent feed and queries, while a higher speed completes sooner at the cost of higher load. Until reindexing completes, affected fields may be empty or carry annotations that do not match the new configuration.

Controlling reindexing from the console

Reindexing is managed from the Reindexing tab of a deployment in the Vespa Cloud console. To open it, select the deployment (for example default.aws-us-east-1c) under the application in the sidebar, then select the Reindexing tab. If the application has more than one content cluster, choose the cluster to work with under Content cluster.

The table lists the document types in the cluster with the current reindexing state, speed, progress, and start and end times. Use the filters in the column headers to narrow the list.

The Reindexing tab of a deployment, with one document type selected

Select one or more document types, then click:

  • Reindex: trigger a fresh reindexing, for example after deploying a document processor that transforms data, or to re-run an earlier reindexing.
  • Pause and Resume: temporarily halt an ongoing reindexing, and resume it later from where it stopped.

Disable reindexing, to the right of the description, turns off reindexing for the content cluster.

When you click Reindex, a confirmation dialog lists the schemas to reindex. The reindexing speed defaults to Balanced, which is recommended for most cases. To change it, expand Customize reindexing speed and choose Conservative or Aggressive. The speed balances time to completion against resource usage: a more aggressive speed completes reindexing sooner but consumes more of the cluster's resources, while a more conservative speed reduces the impact on concurrent feed and queries. Click Yes, reindex to start.

Dialog for confirming reindexing of the selected schemas and customizing the reindexing speed

Monitoring progress

After you confirm, the selection is cleared and the Reindexing tab shows live progress for each document type: the state (pending, running, successful, or failed), the speed, a completion percentage, and the start and end times.

The Reindexing tab after confirming reindexing

In addition, a running reindexing is shown as a Reindexing annotation on the metric charts. See Monitoring for details. This makes it easy to correlate reindexing with any change in feed or query latency while it runs.