x1
. You can increase the size to x2
, x4
, or x8
. Moving up to the next size effectively doubles the capacity of the index. If you need to scale by smaller increments, then consider horizontal scaling.
Increasing the pod size of your index does not result in downtime. Reads and writes continue uninterrupted during the scaling process, which completes in about 10 minutes. You cannot reduce the pod size of your indexes.
The number of base pods you specify when you initially create the index is static and cannot be changed. For example, if you start with 10 pods of p1.x1
and vertically scale to p1.x2
, this equates to 20 pods worth of usage. Pod types (performance versus storage pods) also cannot be changed with vertical scaling. If you want to change your pod type while scaling, then horizontal scaling is the better option.
You can only scale index sizes up and cannot scale them back down.
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 docs-example
. The status
field contains the key-value pair "state":"ScalingUp"
, indicating that the resizing process is still ongoing.
configure_index
endpoint to increase the number of replicas for your index: