What are Apex Governor Limits?<\/h2>\n\n\n\n
Apex Governor Limits are hard limits that Salesforce enforces on every Apex transaction. A transaction is everything that runs from one start event, such as a button click or a record save, until the work finishes. If code goes over a limit, Salesforce stops it with a LimitException and rolls back the whole transaction.<\/p>\n\n\n\n
Think of an apartment building with one shared water tank. Each flat gets a fair daily share, so one family cannot empty the tank for everyone. Salesforce servers are that shared tank, and governor limits are each tenant’s fair share.<\/p>\n\n\n\n
Why Apex Governor Limits Matter<\/h2>\n\n\n\n
Salesforce runs many customers on the same servers, which we call multi-tenancy. Apex Governor Limits stop one org’s slow code from hurting everyone else. Here is why Apex Governor Limits matter at Bright Path Tutors.<\/p>\n\n\n\n
- \n
- First, a data load of 200 enrolments runs every trigger with 200 records at once.<\/li>\n\n
- Also, a query inside a loop works with 5 records but fails with 200.<\/li>\n\n
- Next, a large report job can run out of memory without warning.<\/li>\n\n
- An integration that calls outside systems must respect callout limits.<\/li>\n\n
- Finally, a LimitException cannot be caught, so the whole save fails.<\/li>\n<\/ul>\n\n\n\n
So code that ignores limits works in testing and breaks in production.<\/p>\n\n\n\n
How Apex Governor Limits Work<\/h2>\n\n\n\n
Apex Governor Limits work per transaction. First, a transaction starts, for example when a user saves a record. Next, Salesforce starts counters for queries, DML, CPU time and other resources. Then each query, DML statement and loop adds to those counters. After that, if any counter passes its limit, Salesforce throws a LimitException. Finally, the whole transaction rolls back, and the user sees an error.<\/p>\n\n\n\n
![\"Apex](\"https:\/\/swapnilzambare.com\/blog\/wp-content\/uploads\/2026\/11\/apex-governor-limits-explained-diagram-1-1024x640.png\")
How Salesforce counts resources in every transaction.<\/figcaption><\/figure>\n\n\n\n Per-Transaction Limits<\/h3>\n\n\n\n
Most limits apply to one transaction, such as 100 SOQL queries in synchronous code. They reset when the next transaction starts.<\/p>\n\n\n\n
Synchronous vs Asynchronous Limits<\/h3>\n\n\n\n
Asynchronous Apex, such as Batch Apex and Queueable jobs, gets higher limits for some resources. For example, it gets 200 SOQL queries instead of 100 and more heap memory.<\/p>\n\n\n\n
Per-Org Limits<\/h3>\n\n\n\n
Some limits apply to the whole org over 24 hours, such as the number of asynchronous Apex executions. These matter for large orgs with many background jobs.<\/p>\n\n\n\n
The Limits Class<\/h3>\n\n\n\n
The Limits class tells you how much of each resource your code has used so far. For example, Limits.getQueries() returns the queries used, and Limits.getLimitQueries() returns the maximum.<\/p>\n\n\n\n
The Most Common Apex Governor Limits<\/h2>\n\n\n\n
The table below lists the per-transaction limits developers hit most often.<\/p>\n\n\n\n
Resource<\/th> Synchronous limit<\/th> Asynchronous limit<\/th><\/tr><\/thead> SOQL queries<\/td> 100<\/td> 200<\/td><\/tr> Records returned by SOQL<\/td> 50,000<\/td> 50,000<\/td><\/tr> DML statements<\/td> 150<\/td> 150<\/td><\/tr> Records processed by DML<\/td> 10,000<\/td> 10,000<\/td><\/tr> SOSL searches<\/td> 20<\/td> 20<\/td><\/tr> CPU time<\/td> 10,000 ms<\/td> 60,000 ms<\/td><\/tr> Heap size<\/td> 6 MB<\/td> 12 MB<\/td><\/tr> Callouts<\/td> 100<\/td> 100<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Unsafe Code vs Limit-Safe Code<\/h2>\n\n\n\n
The table below compares code that hits limits with code that stays safe.<\/p>\n\n\n\n
Feature<\/th> Unsafe pattern<\/th> Limit-safe pattern<\/th><\/tr><\/thead> Queries<\/td> SOQL inside a loop<\/td> One query before the loop<\/td><\/tr> DML<\/td> insert inside a loop<\/td> One insert on a list<\/td><\/tr> Lookups<\/td> Query per record<\/td> Map built from one query<\/td><\/tr> Large data<\/td> Load everything in memory<\/td> SOQL for loop or Batch Apex<\/td><\/tr> Records handled<\/td> Works for 1 record<\/td> Works for 200 records<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n When to use which is simple. Always write the limit-safe version, because triggers can receive up to 200 records at a time.<\/p>\n\n\n\n
![\"Apex](\"https:\/\/swapnilzambare.com\/blog\/wp-content\/uploads\/2026\/11\/apex-governor-limits-explained-diagram-2-1024x640.png\")
Unsafe code vs limit-safe code.<\/figcaption><\/figure>\n\n\n\n A Real Apex Governor Limits Example<\/h2>\n\n\n\n
Let’s fix a real problem with Apex Governor Limits at Bright Path Tutors. A trigger on Enrolment__c needs each course’s fee. The first version queries inside a loop.<\/p>\n\n\n\n
Step 1: The Code That Breaks<\/h3>\n\n\n\n
\/\/ BAD: one query per enrolment\nfor (Enrolment__c e : Trigger.new) {\n Course__c c = [SELECT Fee__c FROM Course__c WHERE Id = :e.Course__c];\n e.Amount_Due__c = c.Fee__c;\n}<\/code><\/pre>\n\n\n\nWith 5 enrolments, this runs 5 queries. However, a Data Loader batch of 200 enrolments needs 200 queries. That passes the limit of 100, so the whole load fails with “Too many SOQL queries: 101”.<\/p>\n\n\n\n
Step 2: The Limit-Safe Version<\/h3>\n\n\n\n
\/\/ GOOD: one query for all enrolments\nSet<Id> courseIds = new Set<Id>();\nfor (Enrolment__c e : Trigger.new) {\n courseIds.add(e.Course__c);\n}\n\nMap<Id, Course__c> courses = new Map<Id, Course__c>(\n [SELECT Id, Fee__c FROM Course__c WHERE Id IN :courseIds]\n);\n\nfor (Enrolment__c e : Trigger.new) {\n Course__c c = courses.get(e.Course__c);\n if (c != null) {\n e.Amount_Due__c = c.Fee__c;\n }\n}<\/code><\/pre>\n\n\n\nFirst, we collect every course Id into a set. Next, one query loads all those courses into a map. Then the second loop reads each fee from the map, with no more queries. As a result, 200 enrolments use one query instead of 200.<\/p>\n\n\n\n
Step 3: Check Usage with the Limits Class<\/h3>\n\n\n\n
System.debug('SOQL used: ' + Limits.getQueries() + ' \/ ' + Limits.getLimitQueries());\nSystem.debug('DML used: ' + Limits.getDmlStatements() + ' \/ ' + Limits.getLimitDmlStatements());\nSystem.debug('CPU used: ' + Limits.getCpuTime() + ' ms \/ ' + Limits.getLimitCpuTime() + ' ms');\nSystem.debug('Heap used: ' + Limits.getHeapSize() + ' \/ ' + Limits.getLimitHeapSize());<\/code><\/pre>\n\n\n\nEach pair shows the amount used and the maximum. Add these lines while testing to see how close your code gets to each limit.<\/p>\n\n\n\n
Step 4: Read the Output<\/h3>\n\n\n\n
Here is an example of the debug log for the safe version with 200 enrolments.<\/p>\n\n\n\n
USER_DEBUG [1]|DEBUG|SOQL used: 1 \/ 100\nUSER_DEBUG [2]|DEBUG|DML used: 0 \/ 150\nUSER_DEBUG [3]|DEBUG|CPU used: 38 ms \/ 10000 ms\nUSER_DEBUG [4]|DEBUG|Heap used: 51234 \/ 6000000<\/code><\/pre>\n\n\n\nApex Governor Limits in the Debug Log<\/h2>\n\n\n\n
The debug log also prints a summary of Apex Governor Limits usage at the end of each transaction. Look for the section called “LIMIT_USAGE_FOR_NS”. It lists every limit with the amount used, which helps you find the most expensive part of your code.<\/p>\n\n\n\n
CPU Time and Heap Size<\/h2>\n\n\n\n
CPU time counts the time your Apex code and some automation spend running, not time waiting for the database. Long nested loops are the usual cause of CPU limit errors. Heap size is the memory your variables use. Large lists and big strings fill the heap, so use SOQL for loops and clear lists you no longer need.<\/p>\n\n\n\n
Common Mistakes with Apex Governor Limits<\/h2>\n\n\n\n
- \n
- Writing SOQL or DML inside loops.<\/li>\n\n
- Testing with one record instead of 200.<\/li>\n\n
- Trying to catch a LimitException, which is not possible.<\/li>\n\n
- Building large strings or lists in memory without need.<\/li>\n\n
- Using nested loops over two big lists instead of a map.<\/li>\n<\/ul>\n\n\n\n
Best Practices for Apex Governor Limits<\/h2>\n\n\n\n
- \n
- Query once and use maps for lookups.<\/li>\n\n
- Use one DML statement per object per transaction where possible.<\/li>\n\n
- Test every trigger with 200 records.<\/li>\n\n
- Move heavy work to Batch Apex or Queueable jobs.<\/li>\n\n
- Check the Limits class and debug log summary during testing.<\/li>\n<\/ul>\n\n\n\n
Practice Task<\/h2>\n\n\n\n
Write a trigger-style loop that sets each enrolment’s Course Name field from its parent course, using one query. Then check Limits.getQueries() after running it with 200 test records. Hint: reuse the set and map pattern from Step 2.<\/p>\n\n\n\n
Most Asked Interview Questions on Apex Governor Limits<\/h2>\n\n\n\n
Apex Governor Limits come up in every Salesforce developer interview, at every level. Here are the 21 questions asked most, with short answers.<\/p>\n\n\n\n
Basic Questions on Apex Governor Limits<\/h3>\n\n\n\n
Q1: What are governor limits?<\/strong><\/p>\n\n\n\n
They are limits Salesforce enforces on each Apex transaction, such as the number of queries and DML statements.<\/p>\n\n\n\n
Q2: Why does Salesforce have governor limits?<\/strong><\/p>\n\n\n\n
Because many customers share the same servers. So limits stop one org’s code from slowing down everyone else.<\/p>\n\n\n\n
Q3: What is a transaction in Apex?<\/strong><\/p>\n\n\n\n
It is all the work that runs from one starting event, such as a record save, until it finishes.<\/p>\n\n\n\n
Q4: How many SOQL queries can a synchronous transaction run?<\/strong><\/p>\n\n\n\n
100 queries. Asynchronous Apex gets 200.<\/p>\n\n\n\n
Q5: How many DML statements are allowed?<\/strong><\/p>\n\n\n\n
150 DML statements per transaction.<\/p>\n\n\n\n
Q6: How many records can DML process in one transaction?<\/strong><\/p>\n\n\n\n
10,000 records in total.<\/p>\n\n\n\n
Q7: What is the CPU time limit?<\/strong><\/p>\n\n\n\n
10,000 milliseconds for synchronous Apex and 60,000 milliseconds for asynchronous Apex.<\/p>\n\n\n\n
Code and Scenario Questions on Apex Governor Limits<\/h3>\n\n\n\n
Q8: What error do you get when you run too many queries?<\/strong><\/p>\n\n\n\n
System.LimitException: Too many SOQL queries: 101.<\/p>\n\n\n\n
Q9: Can you catch a LimitException?<\/strong><\/p>\n\n\n\n
No. It cannot be caught, so the transaction fails and rolls back.<\/p>\n\n\n\n
Q10: How do you avoid the SOQL limit in triggers?<\/strong><\/p>\n\n\n\n
Collect Ids in a set, run one query outside the loop and store the results in a map.<\/p>\n\n\n\n
Q11: How do you check how many queries your code used?<\/strong><\/p>\n\n\n\n
Use Limits.getQueries() and compare it with Limits.getLimitQueries().<\/p>\n\n\n\n
Q12: What is the heap size limit?<\/strong><\/p>\n\n\n\n
6 MB for synchronous Apex and 12 MB for asynchronous Apex.<\/p>\n\n\n\n
Q13: How many records can SOQL return in one transaction?<\/strong><\/p>\n\n\n\n
50,000 records across all queries.<\/p>\n\n\n\n
Q14: Why test triggers with 200 records?<\/strong><\/p>\n\n\n\n
Because Data Loader and the API send up to 200 records to a trigger at once. So that is the real-world worst case.<\/p>\n\n\n\n
Advanced Questions on Apex Governor Limits<\/h3>\n\n\n\n
Q15: How does asynchronous Apex help with limits?<\/strong><\/p>\n\n\n\n
It runs in a separate transaction with higher limits for queries, CPU and heap.<\/p>\n\n\n\n
Q16: What usually causes CPU time limit errors?<\/strong><\/p>\n\n\n\n
Nested loops over large lists, complex calculations and too much automation on one save.<\/p>\n\n\n\n
Q17: How do you reduce heap usage?<\/strong><\/p>\n\n\n\n
Use SOQL for loops, select only needed fields and clear large collections when you are done.<\/p>\n\n\n\n
Q18: Do managed packages share your limits?<\/strong><\/p>\n\n\n\n
Certified managed packages get their own limits for many resources, but some limits, such as CPU time, are shared across the transaction.<\/p>\n\n\n\n
Q19: What is the callout limit?<\/strong><\/p>\n\n\n\n
100 callouts per transaction, with a total timeout of 120 seconds.<\/p>\n\n\n\n
Q20: Where can you see limit usage after a transaction?<\/strong><\/p>\n\n\n\n
In the debug log, in the limit usage summary at the end of the transaction.<\/p>\n\n\n\n
Q21: How would you process 1 million records?<\/strong><\/p>\n\n\n\n
Use Batch Apex, which splits the work into many small transactions, each with its own limits.<\/p>\n\n\n\n
Official Resources<\/h2>\n\n\n\n