Secondary index scan limitations under strong consistency quorum

Short answer

No. Aerospike does not provide a namespace-level configuration that forces secondary index scans to obey the same read quorum used for strong-consistency key operations. Namespace read/write quorum settings such as all or majority apply to direct key accesses; they are not inherited by the secondary index scan path. The only available control is the client-supplied query policy, typically a read-consistency-level setting such as one, quorum, or all, depending on your SDK.

This assumes your server and client SDK expose namespace strong consistency and query read-consistency-level. Older or limited clients may not expose the policy.

Confirmed behavior vs. likely explanation

The likely explanation is architectural: a secondary index query is not a direct key read, so the server does not apply the namespace quorum coordinator in the same way. The confirmed practical consequence is that a scan can return stale or inconsistent results when a replica is behind, even if the namespace is configured for strong consistency. Treat the exact internal path as version-dependent and verify it in your deployment.

When a scan encounters a replica that is behind the required quorum, the system does not wait for that replica or fail the scan on namespace-quorum grounds. It may use the available replicas. Setting the client read-consistency-level policy to quorum or all can approximate a stronger guarantee, but that is not the same as enforcing namespace quorum for the scan. It can also increase latency and may fail when enough replicas are unreachable.

What to do for this case

1. Confirm the namespace settings and server version with your admin tool in read-only mode. Record the exact read/write quorum values.
2. Inspect the client code that runs the secondary index query. Verify whether the query policy sets read-consistency-level. If it does not, set it to quorum or all in a staging test and compare latency and result sets.
3. Create or observe controlled replica lag, then run the same query with one versus quorum or all. Check whether the result set changes and whether the stricter policy fails or returns stale rows.
4. If the application requires linearizable results, do not rely on the scan alone. Use the scan to identify candidate keys, then perform direct key reads under the namespace quorum, or use an explicitly verified client policy.

One missing detail

Tell me the client SDK and version you are using. That changes whether the query policy is exposed and how to scope it; without it, the recommendation remains to avoid treating secondary index scans as strongly consistent.

Because this behavior is version-sensitive, treat the above as a verification plan rather than a final guarantee.