Because Apex runs in a multitenant environment, the Apex runtime engine strictly enforces a number of limits to ensure that runaway scripts do not monopolize shared resources. These limits, or governors, track and enforce the statistics outlined in the following table. If a script ever exceeds a limit, the associated governor issues a runtime exception that cannot be handled.
Governor limits are applied based on the entry point of your code. For example, if you have an anonymous block call a trigger, the limits that Apex runtime engine uses are the limits for the anonymous block, not for the trigger.
Governor limits apply to an entire organization, as well as to specific, certified namespaces. For example, if you install a certified managed package from Force.com AppExchange, (that is, an app that has been marked AppExchange Certified) the components in the package belong to a namespace unique from other components in your organization. Consequently, any Apex scripts in that package can issue up to 20 DML statements while executing. In addition, any Apex script that is native to your organization can also issue up to 20 DML statements, meaning more than 20 DML statements might execute during a single transaction if scripts from the certified managed package and your native organization both execute. Conversely, if you install a package from AppExchange that is not marked AppExchange Certified, the scripts from that package do not have their own separate governor limit count. Any resources they use count against the total for your organization. Cumulative resource messages and warning emails are also generated based on certified managed package namespaces as well. For more information on AppExchange Certified packages, see the Force.com AppExchange online help.
| Limit | Trigger | Anonymous Block, Visualforce Controller, or WSDL Method | RunTests1 |
|---|---|---|---|
| Total number of SOQL queries issued2 | 20 | 1008 | 100 |
| Total number of records retrieved by SOQL queries | 1,0006 | 10,0008 | 500 |
| Total number of SOSL queries issued | 0 | 208 | 20 |
| Total number of records retrieved by a single SOSL query | 0 | 2008 | 200 |
| Total number of DML statements issued (insert, update, upsert, merge, or delete) | 20 | 1008 | 100 |
| Total number of records processed as a result of DML statements | 1006 | 10,0008 | 500 |
| Total number of executed script statements | 10,00046 | 200,000 | 20,000 |
| Total heap size3 | 200,000 bytes3 | 2,000,000 bytes3 | 1,000,000 bytes3 |
| Total stack depth for any Apex invocation that recursively fires triggers due to insert, update, or delete statements5 | 16 | 168 | 16 |
| Total number of characters for a single String | 100,000 | 100,000 | 500,000 |
| For loop list batch size | n/a | 200 | n/a |
| Total number of elements in a single List | 1,0003 | 1,0003 | 1,0003 |
| Total number of elements in a single Set | 1,0003 | 1,0003 | 1,0003 |
| Total number of elements in a single Map | 1,0003 | 1,0003 | 1,0003 |
| Total number of Savepoint variables that can be set | 5 | 58 | 5 |
| Total number of rollback methods allowed | 20 | 208 | 20 |
| Total number of Web service methods allowed | 10 | 10 | 10 |
| Total number of callouts (HTTP requests or Web services calls) in a transaction | 10 | 10 | 10 |
| Total request time for one callout (HTTP request or Web services call) | 60 seconds | 60 seconds | 60 seconds |
| Total request time for all callouts (HTTP requests or Web services calls) in a transaction | 120 seconds | 120 seconds | 120 seconds |
| Total number of methods with the future annotation allowed per Apex invocation7 | 10 | 10 | 10 |
| Maximum size of WSDL if converted to Apex | 1 MB | 1 MB | 1 MB |
| Maximum size of SOAP response to a callout (Web services call) | 1 MB | 1 MB | 1 MB |
| Total number of runAs calls when specifying a user allowed | 20 | 20 | 20 |
| Total number of sendEmail methods allowed | 10 | 10 | 10 |
| Total number of ChildRelationship, RecordTypeInfo and PicklistEntry objects allowed | 10 | 10 | 10 |
| Total number of fields calls allowed | 10 | 10 | 10 |
| Total number of items (such as ideas) returned by the findSimilar method | 5 | 5 | 5 |
| Total number of findSimilar calls allowed | 10 | 10 | 10 |
1 RunTests limits apply individually to each testMethod.
2 In a SOQL query with parent-child relationship sub-queries, each parent-child relationship counts as an additional query. These types of queries have a limit of three times the number for top-level queries. The row counts from these relationship queries contribute to the row counts of the overall script execution.
4 Trigger context is 10,000 statements plus 200 times the number of records in the top level call. For example, a DML statement that processes 200 records is subject to a limit of 10,000 + 200*200, which equals 50,000 statements. For a call with the future annotation, the limit is 10,000 statements.
5 Recursive Apex that does not fire any triggers with insert, update, or delete statements exists in a single invocation, with a single stack. Conversely, recursive Apex that fires a trigger spawns the trigger in a new Apex invocation, separate from the invocation of the code that caused it to fire. Because spawning a new invocation of Apex is a more expensive operation than a recursive call in a single invocation, there are tighter restrictions on the stack depth of these types of recursive calls.
6 These limits scale with trigger batch size. The limit is multiplied by the number of records submitted. For example, if your batch process contains 200 records, your script may retrieve as many as 20,000 records.
7 Salesforce also imposes an organization-wide limit of 200 method calls with the future annotation per license per 24 hours.
8 These limits are set to 0 for Visualforce controllers associated with custom components because those controllers cannot execute SOQL, SOSL, or DML statements. For more information, see "Custom Component Controllers" in the Visualforce Developer's Guide at www.salesforce.com/us/developer/docs/pages/index_CSH.htm#pages_comp_cust_elements_controllers.htm.
Use the Limits methods to determine the script execution limits for your code while it is running. For example, you can use the getDMLStatements method to determine the number of DML statements that have already been called by your program, or the getLimitDMLStatements method to determine the total number of DML statements available to your code in that context.
For more information, see Limits Methods.
In addition to the execution governor limits, Apex has the following limits: