GSI index partitioning changes in Couchbase Server 7.x: concurrent N1QL latency when partition count exceeds Index node cores

Affected feature

Global Secondary Index partitioning for N1QL query execution on Couchbase Server 7.x.

Precise goal

Identify whether a documented partition-count configuration change, rather than a general cluster resource issue, explains latency that appears only when many concurrent N1QL SELECT statements hit the same bucket and index.

Constraints and uncertainty

The uncertainty is bounded by two commonly observed cautions: concentrating concurrent scans on one index partition can create head-of-line blocking, while over-provisioning partitions can add result-aggregation overhead. The Index Scan phase is the likely contributor, but the exact boundary where partition count stops matching Index node CPU capacity is not established here. SDK request timeout settings are separate and do not resolve server-side index latency. This is a design question, not an incident report; the behavior should be confirmed under concurrent load for the exact Couchbase Server minor version and index storage settings.

Questions

• For Couchbase Server 7.x with GSI, what partition-count-to-core relationship is expected to avoid concurrent Index Scan latency spikes?
• Does the latency pattern change when the index is partitioned versus unpartitioned under identical concurrent read load?
• Which query-plan signals distinguish head-of-line blocking from cross-partition aggregation overhead?