The “Apex heap size too large” error has a particular way of showing up in production and nowhere else — dev orgs carry less data, so the code that builds a large in-memory collection passes every test and then fails during a real batch run. Winter ‘27 gives that class of failure more room: the Apex heap limit rises to 10MB for synchronous transactions and 25MB for asynchronous ones.
The new numbers
- Synchronous (triggers, controller actions, synchronous callouts): 6MB → 10MB
- Asynchronous (Batch Apex, Queueable, future methods, scheduled Apex): 12MB → 25MB
The asynchronous jump is the significant one — more than double the previous ceiling. If you have shrunk batch scopes or added paging logic purely to stay under 12MB, that pressure eases considerably.
The setting that keeps sandbox deploys honest
The increase is enforced globally — there is no flag to turn it on. But Salesforce added a separate opt-in, “Enforce the Summer ‘26 Apex heap limit,” for a specific transition problem: a Winter ‘27 sandbox gets the new 25MB ceiling immediately, while a production org on the prior release still enforces the old one. Code written and tested against 25MB in the sandbox could then fail on deploy.
The setting lets a developer hold their sandbox to the old limit so sandbox behaviour matches what production will actually enforce. Per Salesforce’s Apex product team, it exists to make the transition controlled and is entirely at the developer’s discretion — it does not change the global enforcement, only your development environment’s ceiling.
Confirm your org’s limit at runtime
Do not assume the ceiling — read it. Limits.getLimitHeapSize() returns the maximum heap for the current transaction context in bytes:
System.debug('Heap ceiling (bytes): ' + Limits.getLimitHeapSize());
System.debug('Heap used (bytes): ' + Limits.getHeapSize());Running this in a synchronous context versus a batch context is the quickest way to confirm which limit applies where.
What this does not change
More heap removes one failure mode; it does not remove the discipline. Heap is one governor limit among several, and SOQL row counts, query limits, and CPU time are untouched. A batch job that streams records and holds only what it needs is still better engineering than one that loads everything because it now can. The same efficient-query instincts covered in SOQL for loops and heap management still decide whether a large job succeeds — the higher ceiling just widens the margin before it doesn’t. If you are processing genuinely large volumes, the patterns in handling large data volumes in Apex matter more than the raw heap number.
For most orgs the practical effect is simple: fewer emergency interventions on batch jobs during volume spikes, and fewer workarounds written solely to manage memory.