| Tweet |
Introduction
The Winter '27 release of Salesforce gave us an unexpected uplift in the Apex heap limit. Synchronous Apex gets 10Mb, an increase of 4Mb or 66% over the previous 6Mb, while asynchronous Apex gets a whopping 25Mb, an increase of 13Mb or 108% over the previous 12Mb. Given that all the memory in the world is currently being consumed by AI data centres, this is not something I was expected.
There's also a really nice touch in Apex Settings while we're in the release transition period - we can ask non-production Winter '27 orgs to apply the Summer '26 heap limit, so we don't inadvertently release code that relies on a 10Mb heap limit to orgs that max out at 6Mb.
I've previously messed with heap limits when trying out Zip Handling in Apex back in February 2025. I was able to briefly push the 6Mb limit to 25Mb when processing a large zip file, so I was keen to see what could be achieved with 10Mb.
After spinning up a Winter '27 preview scratch org and deploying the Zip Handler sample code, I set about pushing the limit. A zip file of 28Mb presented no problem, but also didn't push the heap much further than my original tests in Spring '25. The non-linear nature of compression algorithms I guess. A zip file of 100Mb blew up pretty much immediately when retrieving the file body. Much as I expected, but it would have been cool if it had worked. Splitting the difference to 75Mb suffered the same fate.
Cutting the zip file down to 51Mb hit the sweet spot, as my LWC confirmed:
The CPU is low because there are only a couple of files in there, and they are MOV files which are already compressed. The heap size is impressive though - Apex has (briefly) allowed me to consume 5 times the documented limit. Obviously relying on this in any production scenario would likely be a career-limiting choice - it's all fun and games until the runtime notices, kills my transaction, and leaves me with a file that I've accepted but can't actually process.
Bigger isn't Always Better
The increased heap limit is, of course, very welcome. That said, there's a couple of things I think it's important to bear in mind:
- Heap isn't throughput. The gating factor on your automated process may have been heap, but just because you have more heap doesn't mean you can process as many records as you can stuff into a transaction. The other limits remain in place, and retrieving more records to process will likely push your CPU consumption higher. Code that scales poorly will simply have more room to consume resources before it fails, so it's important to understand how your code behaves as the inputs grow. (Growth Testing is something I cover in my new book, Software Testing on the Salesforce Platform).
- Just because you can retrieve tons of data, doesn't mean you should deliver it. A larger heap means more information can be sent back to the user, but always consider the user experience. Thousands of records dumped in a table that a user has to scroll through can quickly get overwhelming, and they'll be treated to a longer wait while all that information makes its way through the layers. Sending a limited set of results back to the user with the ability to filter is often better received than sending everything because nothing was stopping you. Similarly, increased volumes of data returned from an API call might overwhelm a downstream system,
Yesterday's Best Practice is Still the Right Approach
Writing Apex code to conserve limits and break large workloads into separate transactions is still the way to do it. Just because there is more heap to work with doesn't mean we can start retrieving all fields regardless of whether we need them, or leave copies of everything hanging around. The increased heap limit allows us to handle legitimately larger workloads, but we shouldn't view it as a target to be hit on every transaction, or stop caring about heap consumption.
More Information
- Winter '27 Release Notes for this feature
- Zip Handling in Apex in Spring '25
- Zip Handler Github Repository
No comments:
Post a Comment