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 thepinecone_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:
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.
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.
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.