SOQL Query Performance: Selectivity Patterns for Large Salesforce Data Volumes

A SOQL query can be syntactically correct and still be a poor production query.

The difference becomes visible as data volume grows.

Retrieve Only the Fields You Need

For a stable integration, prefer:

SELECT Id, External_Id__c, Status__c, SystemModstamp
FROM Order__c

over retrieving every available field simply because FIELDS(ALL) exists.

Smaller projections reduce payload size and make the data contract explicit.

Start with Selective Filters

A broad query such as:

SELECT Id, Name
FROM Account
WHERE Name LIKE '%Cloud%'

can be expensive on a very large object. A leading wildcard makes the search inherently broad.

When the business process permits it, filter using selective criteria such as IDs, appropriate indexed fields, or narrow date/checkpoint ranges.

Integration Checkpoints

Incremental integrations should avoid repeatedly scanning historical data:

SELECT Id, External_Id__c, SystemModstamp
FROM Account
WHERE SystemModstamp > 2026-08-23T12:00:00Z
ORDER BY SystemModstamp, Id

A robust integration must also handle checkpoint boundaries, retries, duplicate delivery, and idempotency. Query efficiency and processing correctness are separate concerns.

Use Aggregate Queries for Aggregate Questions

If you need a count:

SELECT COUNT(Id)
FROM Case
WHERE IsClosed = false

Do not retrieve all matching Case IDs merely to count them in MuleSoft, Apex, Java, or another consumer.

Relationship Queries Can Multiply Data

Parent-to-child subqueries are convenient, but retrieving a large parent set with large child collections can create heavy responses. Ask whether you need the entire graph or whether separate bounded queries, Bulk API, or another data-access pattern is more appropriate.

Use the Query Plan

For high-volume queries, use Salesforce's Query Plan tooling to understand the optimizer's chosen approach and relative cost rather than guessing from syntax alone.

SOQL Is Not the Only Extraction Tool

For large asynchronous extracts, Bulk API may be more appropriate. For changes over time, Change Data Capture can avoid constant polling. For text search, SOSL may fit better than broad multi-field LIKE logic.

Architecture starts by choosing the right access pattern, then optimizing the query inside that pattern.