Gleam Erlang Target Memory Footprint for Low-Traffic Workloads

Short answer

For a low-traffic Gleam service, the compiled bytecode size is almost never the cost driver. The baseline memory footprint is dominated by the Erlang VM itself — the schedulers, atom table, ETS infrastructure, and the OTP applications you boot — not by the size of your generated .beam files. Gleam adds no runtime of its own: it compiles to ordinary Erlang modules, so a minimal Gleam process and a minimal hand-written Erlang process start from essentially the same VM floor.

Does the compiler optimize for module size?

Not as a primary goal. The Gleam compiler performs dead-code elimination for unused functions and relies on the Erlang compiler backend for the heavy lifting (inlining, instruction selection). There is no dedicated "small footprint" mode, and the generated Erlang tends to be more verbose than hand-written code for two structural reasons:

• Exhaustive pattern matching. Gleam's compiler emits explicit clauses for every constructor of a custom type, plus catch-all failure branches. Each clause costs header bytes and atom table entries.
• Type abstraction erasure with wrappers. Records become tagged tuples, and some abstractions generate helper functions that a hand-written Erlang module would skip.

The result is that a Gleam-generated module is typically somewhat larger than an equivalent hand-written Erlang module — but we are talking about kilobytes of bytecode, loaded once, shared across all processes. On a VM whose idle baseline is tens of megabytes, this difference is noise.

Expected overhead vs. native Erlang

Confirmed facts: Gleam targets BEAM directly, uses the same immutable data structures (tuples, lists, maps) with the same per-term memory costs, and starts the same OTP runtime. There is no Gleam-specific heap, GC, or scheduler.

The likely — but version-dependent — picture is:

• Runtime (heap) memory: effectively identical for equivalent logic, because the data representations are the same BEAM terms.
• Loaded code size: modestly larger for Gleam due to generated clause density; irrelevant at small scale.
• Baseline VM footprint: identical, and this is the number your infrastructure bill actually sees for a low-traffic workload.

Exact figures depend on your Erlang/OTP release, since BEAM chunk formats and allocator defaults change between versions. Treat any specific megabyte number you see quoted without an OTP version as unreliable.

What to do if footprint matters

Since the VM is the floor, optimize the VM, not the compiler output:

1. Strip unused OTP applications from your release so fewer processes start at boot.
2. Build a minimal release (e.g., via gleam build plus an Erlang release tool) rather than shipping the full OTP installation.
3. Tune scheduler and allocator settings only after measuring.

Verify it yourself

Compare a minimal Gleam module against a hand-written Erlang equivalent on your target OTP version:

gleam new footprint_test && cd footprint_test && gleam build
# Inspect generated Erlang and BEAM chunk sizes:
ls -l build/dev/erlang/*/_build/default/lib/*/ebin/*.beam
# In an Erlang shell:
beam_lib:chunks("path/to/module.beam", ["Code", "Dbgi"]).
% Runtime baseline:
erlang:memory().

Run observer:start() on both variants under identical load to compare real process and system memory. If the difference that matters to you is code size rather than runtime memory, the one missing detail that would change this recommendation is whether you are shipping an embedded/Nerves-style target — on severely storage-constrained devices, BEAM size does become worth optimizing, and the advice shifts toward aggressive release pruning.