Handle Larger Datasets with Increased Apex Heap Limits (Winter '27)

Salesforce is quietly shipping one of the most impactful Apex changes in years. In Winter '27, the synchronous heap limit rises from 6 MB to 10 MB and the asynchronous limit jumps from 12 MB to 25 MB. If your org has ever swallowed a "System.LimitException: Apex heap size too large" at 2 a.m. during a batch job, this one is for you. Here is the pragmatic playbook: what the change means, how to prepare, and how to stagger the rollout so nothing surprises you.

What Actually Changes

• Synchronous heap: 6 MB → 10 MB (+66%). Applies to triggers, controllers, invocable Apex, REST/SOAP endpoints, anonymous execution.
• Asynchronous heap: 12 MB → 25 MB (+108%). Applies to Batch Apex, Queueable, Schedulable, future methods, Platform Event triggers.
• Where: Lightning Experience and Salesforce Classic, all editions that run custom or managed Apex.
• When: Automatically enabled on the Winter '27 release schedule for every org.

Confirm your org's current limit at runtime with Limits.getLimitHeapSize(). That single call tells you which regime you are in.

Why This Matters (More Than It Sounds)

The 6 MB / 12 MB cap has shaped Apex design for over a decade. Teams have accumulated:

• Micro-batching hacks, splitting an 8,000-record job into three chained Queueables because a single batch blew heap.
• Aggressive pagination in list controllers to avoid materializing large lists.
• Selective querying that drops fields (rich text, long text areas, blob-like content) purely to save heap.
• Sacrificial callouts, breaking one 5 MB payload into four smaller ones.

Doubling the asynchronous ceiling collapses a lot of that complexity. But it also unmasks bugs that were never really fixed, just hidden by early limit errors. That is the risk you plan for.

The Hidden Risk: Code That Fails Silently on the New Limit

Most orgs assume "more heap = fewer errors." Not quite. Two categories break:

1. Growing collections that used to throw early now consume 3–4× more RAM before failing, exposing downstream Too many SOQL rows or CPU time limit exceeded errors that were previously masked.
2. Managed-package assumptions. A managed package Apex class may cache more aggressively when it detects higher heap. If you sit on the boundary, the interaction with your own code can behave differently than in a Summer '26 sandbox.

How to Prepare in 4 Steps

1. Inventory Your Heap-Sensitive Code

Search your metadata for these smells:

• Any Apex class that queries and holds more than 2,000 SObjects.
• Any Batch Apex where the scope is 200 and you touch related lists.
• Any Queueable that serializes state larger than 500 KB.
• Any long-text or rich-text fields aggregated in a Map.
• Any legacy code with System.debug(JSON.serialize(...)) on large payloads.

These are the code paths whose behavior changes materially.

2. Refresh a Preview Sandbox on the Winter '27 Preview

Preview sandboxes are upgraded before production. Refresh one, run your top-10 Apex jobs, and compare execution logs against the same run in a Summer '26 sandbox. Look for:

• Longer transaction times (larger collections take longer to process).
• New CPU-time or SOQL-row errors that surface once heap stops being the first bottleneck.
• Managed-package regressions in orgs running CPQ, FSL, NPSP, or Loyalty.

3. Use the "Enforce the Summer '26 Apex heap limit" Toggle Strategically

Salesforce ships a Setup toggle: Apex Settings → Enforce the Summer '26 Apex heap limit. Enable it in nonproduction orgs when you plan to deploy code from a Winter '27 sandbox back to a Summer '26 production. This forces the older, tighter limits so you catch heap regressions before your production upgrades.

Important: the toggle disappears once every production org is on Winter '27. It is a transitional safety net, not a permanent lever.

4. Update Your Governor-Limit Reference Card

If your team keeps a one-pager of governor limits (and you should), update the heap row. But do not simply raise the ceiling. Add both values, with a note: "Sync 10 MB / Async 25 MB from Winter '27; enforce 6 MB / 12 MB in code that must remain portable to managed packages installed on older orgs." Portability matters if you ship AppExchange packages.

Rewriting Code to Take Advantage (Sparingly)

Resist the urge to rewrite Apex just because you can now hold more in memory. The safest refactors:

• Collapse chained Queueables that only existed to work around 12 MB. Single-Queueable jobs are easier to monitor and debug.
• Widen Batch scope from 200 to 500 or 1,000 for I/O-bound batches. Test CPU time first.
• Reduce SOQL round trips where you previously requeried to avoid holding a large list.

Do not rewrite pagination or lazy-loading in Lightning components. Heap was never the real constraint there, response time was.

Rollout Timeline Cheat Sheet

• Now: Inventory heap-sensitive Apex classes and jobs.
• Winter '27 preview window: Refresh a preview sandbox and rerun your top Apex jobs.
• Two weeks before your production upgrade: Deploy any code that assumes the new limits behind the Setup toggle, so nonprod behaves like the older Summer '26 production.
• Weekend of your production upgrade: Monitor Apex jobs for the first 72 hours. Compare heap usage in debug logs.
• Two weeks after upgrade: Retire the "Enforce Summer '26 Apex heap limit" toggle in sandboxes.

Regional Notes

• EU Hyperforce orgs: the change lands in the same release wave. See our GDPR guide if your Apex touches personal data.
• US & Canada: Winter '27 falls close to quarter-end. Plan a release freeze and stagger Apex deployments after the platform upgrade.

Where This Fits in the Bigger 2026 Picture

The heap increase is one entry on a longer list. See our overview of Salesforce releases in 2026: what actually matters for the full picture and our Flow migration playbook if your team is still moving off Workflow Rules and Process Builder in parallel.

Frequently Asked Questions

Do I need to change my code for the new heap limits?

No. Existing code keeps working. The limits are ceilings, not floors, and Salesforce raised the ceiling. You only need to change code if you plan to use the extra headroom, or if hidden CPU / SOQL bugs surface once heap stops throwing first.

Are managed packages affected?

Yes. Managed packages run under the same platform limits. If you author AppExchange packages, keep your test cases sized for the older 6 MB / 12 MB limits so your package installs cleanly on orgs still enforcing them.

What about Flow, Apex triggers, and Platform Events?

Apex triggers run in synchronous context, so they get the 10 MB ceiling. Platform Event triggers run asynchronously and get 25 MB. Flow itself does not consume Apex heap, but invocable Apex called from Flow does.

How do I verify the new limit is active in my org?

Run System.debug(Limits.getLimitHeapSize()); in anonymous Apex. If the returned value is 10,000,000 (sync) or 25,000,000 (async), the new limit is enforced.

Can I opt out?

Not permanently. The Setup toggle to enforce the Summer '26 limit is transitional, available only in sandboxes and only until all production orgs upgrade to Winter '27. After that, the higher limits are global.

Will my heap size errors go away?

Most, but not all. You will still hit the ceiling on truly unbounded queries or infinite recursion. The change gives you room, not immunity from bad code.

Get a Winter '27 Apex Readiness Check

Our Salesforce audit includes a per-release readiness pass on Apex jobs, Flow, and integrations, plus a prioritized action list for the Winter '27 upgrade. Book a 30-minute call and we will tell you which of your Apex classes actually change behavior.