You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Lambda][Node.js] Pointer compression / memory-optimized runtime option for large bundles and source maps #90
We hit a practical memory wall with Node.js Lambda and wanted to ask if pointer compression (or an equivalent runtime-level memory optimization) is on the roadmap for managed Node runtimes.
Our use case is a backend Lambda with a single-file minified bundle. Normal artifact size is ~7.6 MB. If we enable source maps for debugging (NODE_OPTIONS=--enable-source-maps), artifact size jumps to ~31.7 MB (index.mjs + index.mjs.map).
What we observed in real traffic tests:
Runtime: Node.js 24.x
Arch: arm64
Memory: 256 MB
Without source maps: cold starts are acceptable for our use case
With source maps enabled: cold start increases, and we started seeing Runtime.OutOfMemory at 256 MB in the editor/debug environment
We can work around this by disabling source maps or increasing memory, but this is a tough tradeoff:
disabling source maps hurts debuggability
increasing memory increases cost for workloads that are otherwise lightweight
Request:
Could Lambda provide either:
managed Node runtimes with V8 pointer compression enabled, or
another runtime-level memory optimization path for Node workloads with large bundles/maps?
Even an experimental/runtime flag path would already help for debugging-heavy environments.
We'd like to understand why you can't simply increase the Lambda memory size to address this situation? If your use case is debugging, traffic should be low and any additional costs should be minimal. Or, do you have a use case to deploy source maps in a high-traffic production environment?
We host lambda for users, and we want them to be able to debug in certain of their environment. Increasing RAM for testing env would cost at least twice as much, and we are trying to stay competitive with our pricing
Activity
jtuliani commentedon Mar 9, 2026
Hi @leo91000 and thank you for the suggestion.
We'd like to understand why you can't simply increase the Lambda memory size to address this situation? If your use case is debugging, traffic should be low and any additional costs should be minimal. Or, do you have a use case to deploy source maps in a high-traffic production environment?
Thanks for your feedback.
leo91000 commentedon Mar 12, 2026
We host lambda for users, and we want them to be able to debug in certain of their environment. Increasing RAM for testing env would cost at least twice as much, and we are trying to stay competitive with our pricing