10 Salesforce Apex Governor Limits Every Developer Should Know

Imagine your Apex code works perfectly with 10 records.

Then someone uploads 200 records—and suddenly, the transaction fails.

What changed?

The code may not have changed at all. The volume did.

This is exactly why Salesforce developers need to understand Governor Limits.

What Are Governor Limits?

Salesforce is a multitenant platform, meaning multiple organizations share Salesforce’s infrastructure.

To ensure that one organization’s code doesn’t consume excessive shared resources, Salesforce applies limits to resources such as:

• SOQL queries
• DML operations
• CPU time
• Memory
• Database records
• Callouts
• Asynchronous processing

If an Apex transaction exceeds an applicable limit, Salesforce can stop the transaction and throw a LimitException.

So Governor Limits aren’t just restrictions—they are an important part of building scalable Salesforce applications.

10 Governor Limits You Should Know

1. SOQL Queries

100 queries are allowed in a synchronous transaction, while 200 are commonly allowed in asynchronous Apex.

This is why developers should avoid repeatedly querying Salesforce data.

Remember: Don’t think record-by-record. Think in bulk.

2. DML Statements

A transaction can perform up to 150 DML statements.

DML includes:

• Insert
• Update
• Delete
• Undelete
• Upsert
• Merge

The goal is to perform database operations efficiently rather than unnecessarily repeating them.

3. SOQL Query Rows

A transaction can retrieve up to 50,000 records through SOQL.

If you’re working with large amounts of data, querying everything at once may not be the right approach.

For larger workloads, consider appropriate asynchronous or batch-processing strategies.

4. DML Rows

A transaction can process up to 10,000 records through DML.

This becomes especially important when handling large data loads or automation that updates many related records.

5. CPU Time

Common limits are:

• 10,000 ms for synchronous Apex
• 60,000 ms for asynchronous Apex

CPU time measures the processing performed by your transaction.

Complex logic, inefficient loops, and excessive automation can consume CPU quickly.

6. Heap Size

Heap is the memory available during Apex execution.

Common limits are:

• 6 MB for synchronous Apex
• 12 MB for asynchronous Apex

Loading unnecessary records or large amounts of data into memory can cause heap-size problems.

Best practice: Work only with the data your process actually needs.

7. Callouts

Apex commonly allows up to 100 callouts per transaction.

Callouts are used when Salesforce communicates with external systems such as:

• Payment gateways
• ERP systems
• External APIs
• Third-party applications

Integration design therefore needs to consider Salesforce limits as well as the external system’s behavior.

8. SOSL Queries

Apex commonly allows 20 SOSL queries per transaction.

SOSL is particularly useful when searching across multiple Salesforce objects.

A simple way to remember the difference:

SOQL → Query specific Salesforce data

SOSL → Search across multiple objects

9. Queueable Jobs

In a synchronous transaction, up to 50 Queueable jobs can commonly be added to the queue.

Queueable Apex is useful for processing work asynchronously, but it still has its own execution limits.

Asynchronous doesn’t mean unlimited.

10. Future Calls

A synchronous transaction can commonly make up to 50 future method calls.

Future Apex is used for asynchronous processing, although Queueable Apex is often considered for newer asynchronous designs because it provides more flexibility.

The Golden Rule: Think in Bulk

One of the biggest mistakes Salesforce developers make is designing automation for a single record.

For example:

1 record → Works

200 records → Limit exceeded

Salesforce triggers can process multiple records in the same transaction, so your solution should be designed accordingly.

This is known as bulkification.

A bulkified solution generally:

• Avoids unnecessary queries
• Avoids unnecessary DML operations
• Uses collections effectively
• Processes records together
• Considers large data volumes

Quick Cheat Sheet

Final Thoughts

Governor Limits teach Salesforce developers one very important lesson:

Don’t build only for today. Build for scale.

Your Apex may work perfectly with a handful of records, but production environments can involve thousands or millions of records and complex automation.

So the next time you write Apex, don’t ask only:

“Does it work?”

Ask:

“Will it still work when the data grows?”

Because production-ready Salesforce development isn’t just about writing code that works.

It’s about writing solutions that continue to work at scale.