Governor Limits Overview – Salesforce Platform Developer I
Governor Limits Overview
Why Are Governor Limits Important?
Salesforce is a multi-tenant platform, meaning thousands of organizations share the same underlying infrastructure — compute resources, database, and memory. Governor limits exist to ensure that no single tenant can monopolize shared resources and degrade the experience for others. As a Salesforce developer, understanding governor limits is not optional; it is foundational. Every line of Apex code you write, every SOQL query you craft, and every DML statement you execute is subject to these limits. Violating them causes runtime exceptions that can break business-critical processes. For the Platform Developer I exam, governor limits are one of the most heavily tested topics because they directly influence how you design, write, and optimize code.
What Are Governor Limits?
Governor limits are runtime restrictions enforced by the Salesforce platform on the amount of resources your code can consume during a single transaction. A transaction is a set of operations that execute as a single unit — for example, a trigger firing in response to a record insert, or a Visualforce page controller action.
Key governor limits you must know include:
1. SOQL Query Limits
- Synchronous context: 100 SOQL queries per transaction
- Asynchronous context: 200 SOQL queries per transaction
- Total number of records retrieved by SOQL queries: 50,000
2. DML Statement Limits
- 150 DML statements per transaction (insert, update, delete, undelete, merge, upsert)
- Total number of records processed by DML: 10,000
3. SOSL Query Limits
- 20 SOSL queries per transaction
- Each SOSL query can return up to 2,000 records
4. Heap Size
- Synchronous: 6 MB
- Asynchronous: 12 MB
5. CPU Time
- Synchronous: 10,000 milliseconds (10 seconds)
- Asynchronous: 60,000 milliseconds (60 seconds)
6. Callout Limits
- 100 callouts per transaction
- Maximum timeout for a single callout: 120 seconds
- Maximum total callout time: 120 seconds
7. Future Method Limits
- 50 @future calls per transaction
8. Queueable Jobs
- 50 queueable jobs added per transaction
9. Email Invocations
- 10 sendEmail invocations per transaction
10. Describe Calls
- 100 describe calls per transaction
How Do Governor Limits Work?
Governor limits are tracked per execution context (transaction). When a trigger fires, for example, Salesforce initializes counters for every limit category. As your code runs, each SOQL query, DML statement, callout, or other operation increments the appropriate counter. If any counter exceeds the defined limit, Salesforce throws a System.LimitException which cannot be caught with a try-catch block. The entire transaction is rolled back.
Key concepts to understand:
Bulkification: Because triggers fire on batches of records (up to 200 at a time), placing SOQL queries or DML statements inside a loop quickly exhausts limits. The solution is to bulkify your code — collect records in lists or maps and perform queries/DML outside of loops.
Synchronous vs. Asynchronous: Asynchronous contexts (Batch Apex, Queueable, Future methods, Scheduled Apex) generally have higher limits (e.g., 200 SOQL queries, 12 MB heap). This is because they run in a separate execution context and do not directly impact the user experience.
Limits Class: Salesforce provides the Limits class with static methods such as:
- Limits.getQueries() — number of SOQL queries issued so far
- Limits.getLimitQueries() — maximum allowed SOQL queries
- Limits.getDMLStatements() — number of DML statements issued
- Limits.getLimitDMLStatements() — maximum allowed DML statements
- Limits.getHeapSize() and Limits.getLimitHeapSize()
- Limits.getCpuTime() and Limits.getLimitCpuTime()
These methods are invaluable for debugging and proactively managing resource consumption.
Common Patterns That Hit Governor Limits:
SOQL inside a loop (Query in a loop):
This is the number one anti-pattern. If you query inside a for loop that iterates over 200 records, you will hit the 100 SOQL query limit. Always move queries before the loop and use collections (Maps, Sets, Lists) to organize data.
DML inside a loop:
Similar to the above. Collect records into a list and perform a single DML operation after the loop.
Unbounded queries:
Queries without WHERE clauses or with very broad filters can return more than 50,000 records, hitting the total records retrieved limit.
Recursive triggers:
Without proper recursion control (e.g., using a static Boolean variable), triggers can re-fire repeatedly, consuming SOQL, DML, and CPU time limits.
Best Practices to Avoid Hitting Governor Limits:
- Always bulkify your code: no SOQL or DML inside loops
- Use collections (Maps, Sets, Lists) for efficient data handling
- Use selective SOQL queries with indexed filters
- Implement recursion guards in triggers
- Move heavy processing to asynchronous Apex (Batch, Queueable, Future)
- Use the Limits class to monitor consumption during development
- Leverage SOQL for-loops for processing large data sets (they retrieve records in batches of 200)
- Aggregate queries (COUNT, SUM, etc.) to reduce the number of records returned
How Governor Limits Relate to Other Topics:
Governor limits intersect with almost every developer topic: Triggers, Apex Classes, Batch Apex, Integration (Callouts), Visualforce/Lightning controllers, and Test Classes. Understanding limits helps you make architectural decisions — for example, choosing Batch Apex for processing millions of records instead of a synchronous trigger.
Exam Tips: Answering Questions on Governor Limits Overview1. Memorize the key numbers. The exam frequently tests specific limits: 100 SOQL (sync), 200 SOQL (async), 150 DML statements, 50,000 records retrieved, 10,000 records processed by DML, 6 MB heap (sync), 12 MB heap (async), 10 seconds CPU (sync), 60 seconds CPU (async), 100 callouts, and 50 future calls. These numbers appear directly in questions.
2. Recognize anti-patterns immediately. Many questions present code snippets with SOQL or DML inside loops. If you see a query or DML statement inside a for loop, that is almost always the wrong answer or the source of the problem described in the question.
3. Understand the difference between synchronous and asynchronous limits. Questions may ask which context provides higher limits or which approach to use when processing large data volumes.
4. Know that LimitException cannot be caught. If a question asks what happens when a governor limit is exceeded, the answer is that the transaction fails with an uncatchable System.LimitException and all changes are rolled back.
5. Understand the Limits class methods. Questions may ask how to programmatically check how many resources have been consumed. Know the pattern:
Limits.getQueries() returns current usage,
Limits.getLimitQueries() returns the maximum.
6. Think about trigger context. When a question involves triggers and bulk operations (e.g., a Data Loader inserting 400 records), remember that triggers fire in batches of 200 records. Two batches means two separate transactions, each with its own set of limits.
7. Look for the bulkified solution. When multiple answer choices are presented, the correct one is almost always the one that queries and performs DML outside of loops, uses collections, and follows the one-query/one-DML pattern.
8. Remember per-transaction vs. per-org limits. Most governor limits are per-transaction. However, some limits like the daily API request limit, daily async Apex executions, and daily email limits are per-24-hour-period org-wide limits. The exam may test your ability to distinguish between these.
9. Pay attention to the scenario context. If a question says code is running in a Batch Apex execute method, apply asynchronous limits. If it says the code is in a trigger or a Visualforce controller action, apply synchronous limits.
10. Elimination strategy: If you are unsure, eliminate answers that contain obvious anti-patterns (queries in loops, DML in loops, hardcoded IDs, or no error handling). The remaining answer that follows Salesforce best practices is most likely correct.
Mastering governor limits is essential not just for passing the exam, but for writing production-quality Apex code that performs reliably at scale on the Salesforce platform.