Memory64 in 2026: Breaking the 4GB Ceiling in Browsers and Servers

Your Wasm module just crashed with Cannot grow memory: out of memory — and you know you're only using 3.2 GB. Welcome to the 4 GB ceiling. WebAssembly's MVP defined linear memory as a flat byte array addressed by 32-bit pointers, capping any single module at roughly 4 GB. For most code that's fine. For DuckDB-style analytical queries, gigapixel image stacks, large ML model weights, and geospatial tilesets, it's a hard wall. Memory64 removes that wall by switching memory addressing to 64 bits. In 2026, after years of "almost there," Memory64 is finally usable in production.

The 4 GB Ceiling, and Why It Existed

Wasm's design prioritized a minimal, fast, deterministic execution model. A 32-bit memory index lets engines emit tight bounds-checked code without 64-bit address math. The trade-off: a single module could never hold more than 2^32 bytes of memory. The Core Spec shipped that way in 2017 and the ecosystem has lived within it ever since.

For most workloads 4 GB is plenty. The problem is the category right above the line: in-browser dataframes holding hundreds of millions of rows, gigapixel imaging pipelines, ML weights for 7B+ parameter LLMs, and multi-GB geospatial tilesets — workloads the 32-bit ceiling has actively blocked.

Memory64 keeps the same flat memory model but switches the index to 64 bits, raising the cap to 2^64 bytes (in practice limited by host memory, not the spec). Critically, Memory64 is not "64-bit WebAssembly" — code still runs on a 32-bit instruction set with 32-bit locals. Only the memory addressing becomes 64-bit. This keeps engines simple, binaries small, and the deterministic execution guarantees intact.

Ship Status: Where Memory64 Works in 2026

Ship Status: Where Memory64 Works in 2026

Browsers. Chrome 133 shipped Memory64 in February 2025 and it's been on-by-default since. Safari Technology Preview has it in recent builds; Firefox tracks the proposal in nightly. Browser invocation is identical to a classic memory import — only the memory64 flag on the memory type changes.

Wasmtime has supported Memory64 for years and is production-ready as of v45.0.0 (2026-05-21). Modules are first-class — no feature flag, no special API path.

WasmEdge v0.17.0 (2026-05-18) added full Memory64 support in interpreter and AOT/JIT modes — the first non-Wasmtime runtime with a production-grade Memory64 story.

Wasmer has had Memory64 support for several releases; the 7.0 line (2026-01) makes it part of the default surface.

wazero (the Go-only embeddable runtime) tracks the WebAssembly 3.0 spec line, but Memory64 is not yet shipped as of v1.12.0 (2026-05-29). If you need Memory64 from a Go embed, use Wasmtime's Go binding (wasmtime-go).

Jco v1.24.1 (2026-06-16) handles Memory64 components transparently when transpiling a WASI 0.2 component for Node.js or the browser.

WASI 0.3, ratified on 2026-06-11, formalizes Memory64 in component-model hosts — the spec is explicit that components can declare 64-bit memories and hosts must honor them.

What Memory64 Is — and What It Isn't

Memory64 is not 64-bit pointer Wasm. Instructions still operate on i32/i64/f32/f64 locals; only the memory index is 64-bit. Memory64 is also not automatically faster — it adds a small amount of address-calculation overhead in the hot path of every memory access. If your module only ever uses 100 MB, Memory64 is pure overhead. And Memory64 is not a 64-bit address space in the host. Memory64 raises the Wasm-side limit, not the host's.

The Rust Path: wasm-bindgen 0.2.120 + wasm-pack 0.15.0

wasm-bindgen 0.2.120 (April 2026) added support for the wasm64-unknown-unknown target; usize/isize and raw pointers now use an f64 JS-number ABI on wasm64. The 0.2.123 patch fixed bin crates that targeted wasm64 silently never running main. The current line is 0.2.125 (2026-06-12).

wasm-pack v0.15.0 (2026-05-15) added the target parameterization needed to build a wasm64-unknown-unknown artifact, passing --enable-memory64 to wasm-opt and constructing CARGO_TARGET_*_RUNNER automatically.

In practice the change is a single flag on the build command:

rustup target add wasm64-unknown-unknown
wasm-pack build --target web \
  -- --target wasm64-unknown-unknown

On the JS side, instantiating a 64-bit memory is identical to a 32-bit one except for the index: 'i64' flag:

const memory = new WebAssembly.Memory({
  initial: 256,    // pages (each 64 KiB)
  maximum: 65536,  // raise as needed
  index: 'i64',    // Memory64!
});
 
const { instance } = await WebAssembly.instantiateStreaming(
  fetch('/pkg/my_module_bg.wasm'),
  { env: { memory } }
);

Everything else — imports, exports, function calls — is identical to a 32-bit module.

Real-World Use Cases in 2026

In-browser analytical queries. DuckDB Wasm is the canonical example. A 1 GB Parquet file fits in 32-bit memory; a 6 GB one does not. With Memory64, a browser tab can load a Parquet file that would otherwise need a server round-trip. The same applies to Polars Wasm.

Image stacks. A gigapixel pathology slide can be 10–50 GB decompressed. With Memory64, the full stack stays resident and can be panned and zoomed without re-fetching.

LLM inference. A quantized 7B-parameter model in q4_k is about 4.5 GB — right at the 32-bit ceiling. Memory64 lets the entire model fit in a single linear memory.

Geospatial data. A global DEM at 30 m resolution is tens of gigabytes decompressed. Memory64 doesn't make the whole planet fit in a tab, but it does let the active tile set comfortably exceed 4 GB.

DuckDB Wasm builds are already running Memory64 in Chrome 133+; the other workloads are at the proof-of-concept stage as of mid-2026.

Status in Other Toolchains

• Zig has a wasm64-wasi target, but it's still Tier 3 per the Zig 0.15.1 release notes.
• AssemblyScript, Pyodide, .NET/Blazor, Go (gc + TinyGo), SwiftWasm — no Memory64 support; each is stuck on 32-bit linear memory.
• Jco transparently handles Memory64 components; a Rust wasm64-unknown-unknown component run through jco transpile works in Node and the browser.

The pattern: Memory64 is real and working in Rust and the major runtimes. The language toolchain story is "Rust is ready, everything else is still on 32-bit linear memory."

What's Next

Memory64 in 2026 is in the same place Wasm GC was in 2023: shipped in one or two major browsers, supported in all production runtimes, and ready for a specific category of workloads. The work still ahead: Firefox and Safari GA (Firefox has it in nightly, Safari in Technology Preview), the Zig Tier-3 target needs a Tier-2 promotion, and most bundlers still assume 32-bit memory.

Memory64 isn't exciting in the way the Component Model or WASI 0.3 async is. It's a single line in a memory descriptor, and once you've turned it on, the rest of your code looks the same. But for the workload category that needs it — stalled at the 4 GB wall for a decade — it unlocks new categories of browser and edge applications. If you've been waiting for in-browser dataframes, multi-GB image stacks, or 7B+ LLMs to fit in a single Wasm module, the wait is over.