Skip to main content

When to scale

Dedicated read nodes don’t yet scale automatically. You decide when to scale, guided by two signals: Diagnose which one you’re facing before you scale. Adding shards won’t relieve query latency that’s driven by CPU saturation, and adding replicas won’t create room on a shard that’s running out of space.

Add or remove replicas

CPU usage reflects query pressure. As query load outgrows what your replicas can serve, query latency climbs and throughput drops. Pinecone exposes CPU usage as the pinecone_db_drn_cpu_usage_percent metric, reported per shard. To collect it, monitor your index with Prometheus. Alert on the highest value across your shards rather than the index-wide average, which can look healthy while a single shard is already saturated:
Add a replica when this exceeds 80%. Averaging over a window keeps a brief spike from triggering a scale-up, so shorten or lengthen the window to suit how quickly your traffic shifts. Throughput scales approximately linearly with replicas. For high availability, allocate n+1 replicas, where n is the minimum number of replicas required to serve your expected throughput at your target latency. See Number of replicas.
If you’d rather reduce per-query compute than add replicas, you can also tune query-time search parameters to trade some recall for higher throughput.
To add or remove replicas, call Configure an index. This operation doesn’t require downtime, but can take up to 30 minutes to complete. In the request body, set the following fields:

Example

Configuration change limits:
  • You can make one configuration change every ten minutes, but you can batch multiple changes (node type, shards, and replicas) in a single request.
  • A new configuration change can only be initiated after the previous configuration change has completed.
  • Each configuration change can take up to 30 minutes to complete.
  • Read and write operations continue normally during configuration changes.

Add or remove shards

Index fullness reflects data volume. Writes are blocked once the index reaches capacity, while reads continue normally.
Add shards when index fullness reaches 70-80%, especially if you expect continued growth. Adding shards reduces storage fullness (index data is spread across shards, so each stores less) and memory fullness (with less data per shard, there’s less to cache in memory), helping you avoid write failures.
To check the current value, see Monitor index fullness. To add or remove shards, call Configure an index. This operation doesn’t require downtime, but can take up to 30 minutes to complete. In the request body, set the following fields:

Example

Configuration change limits:
  • You can make one configuration change every ten minutes, but you can batch multiple changes (node type, shards, and replicas) in a single request.
  • A new configuration change can only be initiated after the previous configuration change has completed.
  • Each configuration change can take up to 30 minutes to complete.
  • Read and write operations continue normally during configuration changes.