Skip to content

[Lambda][Node.js] Pointer compression / memory-optimized runtime option for large bundles and source maps #90

Open

Description

@leo91000

Hi Lambda team,

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:

  1. managed Node runtimes with V8 pointer compression enabled, or
  2. 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.

Thanks for considering this.

Activity

  1. jtuliani commented on Mar 9, 2026

    @jtuliani

    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.

  2. leo91000 commented on Mar 12, 2026

    @leo91000
    Author

    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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions