Increased Apex Heap Limits in Winter ’27: Finally, More Room to Breathe

Every Salesforce developer has seen this error at the worst possible moment: “Apex heap size too large.” It usually hits during a batch job or data migration, right when your data volume grows past what you’d planned for , And the transaction just dies, no partial results, no warning.

Winter ’27 finally raises those limits. It’s one of the most practically useful changes in the release for anyone who writes or maintains Apex and work on large database.

Note: This feature is currently in preview and rolling out instance-by-instance. Check Trust Status for your org’s exact date before planning production work around it.

What Is Apex Heap Size?

The heap is the working memory your Apex code uses while it runs the variables, lists, maps, and any records it’s holding onto. Salesforce caps how much of it a single transaction can use if you cross that cap and the transaction is killed immediately, regardless of whether your code logic is correct. It’s a capacity limit, not a code-quality problem.

The New Limits

The async jump matters most, since that’s exactly where large data volumes tend to pile up i.e nightly syncs, mass updates, bulk callouts.

Why It Matters

• Fewer failures on data heavy jobs and large maps/nested lists
• More room for integrations pulling large JSON payloads
• Batch Apex is the biggest winner where scopes shrunk purely to avoid heap errors can go back to normal size
• Less defensive code written just to manage memory

Who and When

Applies to both Lightning Experience and Salesforce Classic, across any edition running custom or managed Apex. It rolls out automatically with your org’s Winter ’27 upgrade . Check Trust Status for your instance’s exact date.

Check Your Limit in Code

Integer maxHeap = Limits.getLimitHeapSize();
System.debug('Max heap available: ' + maxHeap);

Integer maxHeap = Limits.getLimitHeapSize();
System.debug('Max heap available: ' + maxHeap);

Important Note

If your sandbox is already on Winter ’27 but production isn’t, code can pass tests against the new 25 MB limit and then fail in production still running the old 12 MB cap. This mismatch is common right after a release starts rolling out, since sandboxes and production orgs get upgraded on different schedules . Your non-production org can be weeks ahead of the org you’re actually deploying to.

Salesforce built a specific setting to cover exactly this situation. If you’re building features in a Winter ’27 sandbox, Developer Edition, or scratch org that will eventually deploy to a production org still on Summer ’26, you can temporarily restrict that non-production org back down to the older, lower heap limits so your testing actually reflects what production will enforce.

To turn it on:

1. In your sandbox, Developer Edition, or scratch org, go to Setup.
2. In the Quick Find box, search for and select Apex Settings.
3. Enable Enforce the Summer ’26 Apex heap limit.

With this turned on, the non-production org runs under the old 6 MB / 12 MB caps instead of the new ones . So if your code passes there, you can trust it’ll also pass once it’s deployed to a production org that hasn’t upgraded yet. It’s meant to be temporary, once your production org is also on Winter ’27, this setting stops being necessary, since both environments will be running the same higher limits by default.

Real-World Example

A nightly batch job syncs order data from an external platform for example building an Order Id → line items map, cross-referencing records, writing updates back. On a normal night it’s fine. During a big sale, volume spikes 3–4x and the same job starts failing with heap errors, forcing the team to manually shrink the batch scope.

With the async limit at 25 MB, that same job now has more than double the room to handle the spike without manual intervention so now fewer emergency fixes, fewer failed syncs on the nights that matter most.

Worth Remembering

• It’s still a hard governor limit , you can’t request more
• Good memory practices (selective SOQL, clearing collections) still matter
• Check Trust Status for your upgrade date, then revisit any batch job you shrank just to survive heap limits

FAQs

What are the new Apex heap limits? Synchronous: 6 MB → 10 MB. Asynchronous (Batch, Queueable, future methods): 12 MB → 25 MB.

Do I need to change anything to get the new limits? No , they apply automatically once your org is on Winter ’27.

How do I test against the old limits before production upgrades? Enable “Enforce the Summer ’26 Apex heap limit” under Apex Settings in a sandbox or scratch org.

How do I check the limit in code? Call Limits.getLimitHeapSize() —> it returns the max heap available to the current transaction.

Want Help With Apex Interviews or Architecture

Book a mock interview, resume review, or 1:1 mentorship session with expert.

👉 Book a free session: Click here