Salesforce is increasing the Apex Heap Limits in the Winter ’27 release, giving developers more memory headroom when processing larger datasets and complex transactions.
The synchronous Apex heap limit increases from 6 MB to 10 MB, while the asynchronous limit increases from 12 MB to 25 MB.
For Salesforce developers working with large data volumes, integrations, JSON payloads, or memory-intensive processing, this is a meaningful improvement. But the higher limit doesn’t eliminate the need for efficient Apex design.
What Is the Apex Heap Limit?
The Apex heap limit defines how much memory an Apex transaction can use while it is executing.
Apex uses heap memory to hold data such as:
- sObjects
- Lists, Sets, and Maps
- Strings
- Custom Apex objects
- JSON data
- Serialized and deserialized data
- Other objects created during execution
When an Apex transaction consumes more memory than the permitted heap limit, Salesforce stops the transaction and throws an exception such as:
System.LimitException: Apex heap size too largeThis can become a challenge when an application processes large datasets or creates multiple in-memory data structures.
What Changed in Winter ’27?
Salesforce has increased the Apex heap limits as follows:
| Apex Execution | Previous Limit | Winter ’27 |
|---|---|---|
| Synchronous Apex | 6 MB | 10 MB |
| Asynchronous Apex | 12 MB | 25 MB |
The increase is particularly significant for asynchronous Apex, where the available heap more than doubles.
This gives developers additional capacity for workloads that legitimately require more memory during a transaction.
Why Is This Important for Salesforce Developers?
Modern Salesforce applications often do much more than simple record updates.
A single Apex transaction may retrieve Salesforce records, transform the data, create collections, build a JSON payload, and communicate with an external API.
All of that processing can contribute to heap usage.
For example:
List<Account> accounts = [
SELECT Id, Name, Industry
FROM Account
];
Map<Id, Account> accountMap = new Map<Id, Account>(accounts);Here, the records are stored in a List and then another collection is created from those records.
For small datasets, this may not be an issue. But as the amount of data increases, maintaining multiple collections can significantly increase memory consumption.
Where the Higher Heap Limit Can Help
Large Data Processing
Applications processing larger numbers of records can benefit from the additional memory available within a transaction.
This can be particularly useful for complex transformations where multiple data structures need to exist temporarily.
API Integrations
Apex integrations often work with JSON request and response payloads.
Large responses can consume considerable heap when they are stored as strings and then deserialized into Apex objects.
The increased limits give developers more flexibility when working with larger payloads.
Complex Business Logic
Some Salesforce implementations require several intermediate collections or objects while business rules are being evaluated.
The additional heap capacity can help these processes complete successfully without immediately reaching the governor limit.
Asynchronous Processing
The new 25 MB asynchronous heap limit makes asynchronous Apex even more useful for memory-intensive workloads.
Queueable Apex, Batch Apex, Future methods, and Scheduled Apex can be considered when a process is better suited to background execution.
Does the Higher Limit Mean Developers Can Ignore Heap Optimization?
No.
This is perhaps the most important point about the change.
A higher governor limit provides more capacity, but it doesn’t make inefficient code efficient.
Developers should still design Apex to use memory responsibly.
1. Query Only the Data You Need
Avoid retrieving fields that aren’t required by the business logic.
Instead of querying large amounts of unnecessary data, keep SOQL queries focused on the fields actually being used.
2. Avoid Unnecessary Duplicate Collections
Creating multiple Lists, Maps, or other structures containing the same data can increase heap usage quickly.
Before creating another collection, ask whether the additional structure is actually necessary.
3. Process Large Datasets Carefully
For large datasets, consider techniques such as SOQL for loops, Batch Apex, or other approaches that allow data to be processed in manageable portions rather than loading everything into memory at once.
4. Keep JSON Payloads Under Control
When working with integrations, request only the data required from external systems whenever possible.
Large JSON responses can consume significant heap when they are stored and deserialized.
5. Monitor Heap Usage
Apex provides the Limits class to help developers understand how much heap their transaction is consuming.
For example:
System.debug('Heap Used: ' + Limits.getHeapSize());
System.debug('Heap Limit: ' + Limits.getLimitHeapSize());This can be useful when troubleshooting transactions that are approaching the heap limit.
A Bigger Opportunity for Better Apex Architecture
The increased heap limits aren’t simply about allowing Apex to hold more data.
They also give developers more flexibility when designing solutions for complex Salesforce environments.
For example, a process that previously required significant effort to stay below the asynchronous 12 MB limit now has up to 25 MB of heap capacity.
That additional headroom can be valuable for integrations, data transformation, automation, and other resource-intensive workloads.
However, architecture still matters.
If a process consistently requires large amounts of memory, simply relying on the higher limit may only postpone the problem. Developers should evaluate whether the process can be broken into smaller transactions, moved to asynchronous processing, or redesigned to avoid unnecessary data duplication.
Conclusion
The Winter ’27 Apex Heap Limit increase is a welcome improvement for Salesforce developers.
With synchronous Apex increasing to 10 MB and asynchronous Apex increasing to 25 MB, developers have considerably more room for memory-intensive transactions.
But the best approach remains the same:
Use the additional capacity when you need it, while continuing to write efficient Apex.
Selective queries, optimized collections, controlled payload sizes, appropriate asynchronous processing, and heap monitoring will remain important for building scalable Salesforce applications.
The new limits provide more breathing room—but good Apex architecture is still the first line of defense against governor-limit issues.
