Salesforce Governor Limits: What They Are and Why They Matter?

Salesforce is a robust cloud platform, used by millions of people and thousands of companies around the world. It’s remarkable because of the way customers can customise and extend functionality with Apex code, declarative automation, integrations and more. Still, there are challenges to executing custom logic in a shared, multi-tenant environment, and those challenges are addressed by the Salesforce Governor Limits.

Governor limits are rules enforced by the Salesforce platform to prevent individual transactions from consuming excessive resources on shared servers. They provide fairness in diligence and performance stability to be shared among all tenants. Although some of these limits can be surprising at first, knowing the reasons behind the limits and how to work around them is key to developing scalable, robust solutions on Salesforce.

In this blog, the concept of governor limits is explained, along with why Salesforce enforces them, the key types of limits most commonly encountered, and best practices for designing solutions that stay within these limits.

In essence, governor limits are system resource limits that determine how many resources, such as CPU usage, memory consumption, etc., one execution of Salesforce code can consume. This applies whether you’re executing Apex code, running flows, or processing triggers.

If your logic consumes too many resources, like too many database queries or DML operations, Salesforce stops the transaction with an error, preventing further processing. These limits aren’t arbitrary; they are a key part of Salesforce’s multi-tenant architecture.

Imagine an apartment building with shared water pressure. If one tenant opens every tap at full blast while another runs a washing machine and someone else showers, the system can fail. Governor limits prevent this kind of resource monopolization across tenants in Salesforce.

These limits apply to a single execution context of Apex code (such as a trigger or batch chunk). For example:

• Maximum number of SOQL queries
• Maximum number of SOSL queries
• Maximum number of DML statements
• Maximum number of records retrieved
• Maximum heap size (memory)

These limits reset for each transaction. If any limit is exceeded mid-execution, the entire transaction fails

Some governor limits are enforced at the platform level rather than per transaction. These include limits such as:

• Up to 100 SOQL queries per synchronous transaction
• Up to 200 SOQL queries for asynchronous transactions

This means if you run a SOQL query inside a loop, a classic anti-pattern, you can easily hit the limit and cause an uncatchable runtime exception.

• 150 DML operations per transaction

• synchronous heap size is limited (e.g., 6 MB)
• Asynchronous processes often have larger limits

• Use WHERE clauses to limit returned rows.
• Only retrieve the fields you need.
• Consider indexed fields for filters to speed up queries.

Salesforce governor limits are in place due to the shared multi-tenant platform architecture to guarantee fair usage of system resources, such as CPU, memory, database queries, and API calls, across all orgs. While these constraints may seem overly limiting at first, they are necessary for keeping the platform stable, providing predictable performance, and preventing one tenant from adversely impacting others due to inefficient or runaway code.

Rather than being obstacles, Salesforce governor limits encourage developers to design scalable and efficient solutions. Teams can develop scalable applications capable of handling expanding data volumes through the use of bulkification of logic, optimisation of SOQL queries, efficient use of collections, and asynchronous processing. Understanding and designing around governor limits is a fundamental skill that separates basic Salesforce implementations from truly enterprise-ready solutions.