Understanding Execution Governors and Limits

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	Test¹
Total number of SOQL queries issued²	20	100⁸	100
Total number of records retrieved by SOQL queries	1,000⁶	10,000⁸	500
Total number of SOSL queries issued	0	20⁸	20
Total number of records retrieved by a single SOSL query	0	200⁸	200
Total number of DML statements issued (`insert`, `update`, `upsert`, `merge`, `delete`, or `database.emptyRecycleBin`)	20	100⁸	100
Total number of records processed as a result of DML statements or `database.emptyRecycleBin`	100⁶	10,000⁸	500
Total number of executed script statements³	10,000⁴⁶	200,000	20,000
Total heap size³	200,000 bytes³	2,000,000 bytes³	1,000,000 bytes³
Total stack depth for any Apex invocation that recursively fires triggers due to `insert`, `update`, or `delete` statements⁵	16	16⁸	16
For loop list batch size	n/a	200	n/a
Total number of elements in a single List	1,000³	1,000³	1,000³
Total number of elements in a single Set	1,000³	1,000³	1,000³
Total number of elements in a single Map	1,000³	1,000³	1,000³
Total number of Savepoint variables that can be set	5	5⁸	5
Total number of `rollback` methods allowed	20	20⁸	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 invocation⁷	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

¹ Test limits apply individually to each testMethod.

² 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.

³ These limits scale with trigger batch size as follows:

For 1-40 records, the normal limits apply
For 41-80 records, two times the normal limits apply
For 81-120 records, three times the normal limits apply
For 121-160 records, four times the normal limits apply
For 161 or more records, five times the normal limits apply

⁴ 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.

⁵ 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.

⁶ 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 200,000 records.

⁷ Salesforce.com also imposes an organization-wide limit of 200 method calls with the future annotation per license per 24 hours.

⁸ 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.

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 the Apex Code Developer's Guide.

Note

Static variable values are reset between API batches, but governor limits are not. Do not use static variables to track state information on API batches, because Salesforce.com may break up a batch into smaller chunks than the batch size you specify.

In addition to the execution governor limits, Apex has the following limits:

Maximum number of characters for a class: 100,000
Maximum number of characters for a trigger: 32,000
Maximum amount of code used by all Apex scripts in an organization: 1 MB
Note
This limit does not apply to certified managed packages installed from AppExchange, (that is, an app that has been marked AppExchange Certified). The code in those types of packages belong to a namespace unique from the code in your organization. For more information on AppExchange Certified packages, see the Force.comAppExchange online help.
This limit also does not apply to any code included in a class defined with the @isTest annotation. For more information, see “IsTest” in the Apex Code Developer's Guide.
A user can have up to five query cursors open at a time. If five cursors are opened when a client application, still logged in as the same user, attempts open a new one, the oldest of the five cursors is released.
Note
Cursor limits for different Force.com features are tracked separately. For example, you can have five Apex query cursors open and five batch cursors at the same time.