Memory64: Unlocking WebAssembly’s True Potential with 16GB of In-Browser Memory

For as long as the web has existed, serious data visualization has often meant leaving the browser. If you needed to render a billion data points, inspect a multi-gigabyte signal capture, or scrub through months of high-frequency telemetry, you had to reach for a native desktop application. The browser was where you went for dashboards and summaries – not for the raw, uncompressed firehose.

That boundary is disappearing. With SciChart.js v6, now in alpha, we will be shipping a proof-of-concept for WebAssembly Memory64, which lifts the browser’s hard 4GB memory ceiling to 16GB. In practical terms for our users, that’s the difference between charting roughly 200 million data points and charting one billion datapoints in JavaScript – a figure we’ve now tested directly in Google Chrome.

This post covers what WebAssembly and Memory64 actually are, how we’ve integrated and tested Memory64 in SciChart, what it unlocks for data-intensive workloads, and the trade-offs you should weigh before turning it on.

A quick primer: what is WebAssembly?

WebAssembly (Wasm) is a low-level, binary instruction format that runs in the browser at close to native speed. Instead of shipping JavaScript that the browser interprets and JIT-compiles at runtime, you can compile code written in C, C++, or Rust down to a compact binary that executes in a fast, sandboxed virtual machine.

SciChart’s rendering and data-processing engine is written in high-performance C++ and compiled to WebAssembly. This is the reason SciChart.js can handle datasets that greatly surpass what typical HTML5 or SVG JavaScript charting can handle: the heavy lifting – data transformations, hit-testing, rendering instructions, and pushing geometry to the GPU – happens in compiled native code with hand-optimised SIMD (Single Instruction Multiple Data), not in the JavaScript event loop. WebAssembly is what makes SciChart.js feel like a native charting engine that happens to run in a browser tab.

So what is Memory64?

Pure-JavaScript applications are surprisingly constrained when it comes to large datasets. They’re bound by the V8 engine’s heap limits and by caps on individual typed-array allocations, so in practice a JS app runs into memory trouble well before it can marshal anything close to a full contiguous gigabyte of numeric data. A typical limit for a JavaScript application running in chrome is 2-4GB, effectively making web apps no better than 32-bit desktop apps, no matter how much RAM your system has.

WebAssembly already improves on this dramatically. A Wasm module gets its own dedicated linear memory – a single, contiguous area that SciChart’s C++ engine uses to store data directly, sidestepping the JavaScript heap entirely. In its original 32-bit form, Wasm can address the full 4GB, which is why SciChart.js can already handle roughly 200 million double-precision XY data points in our current generally available version.

Memory64 raises that ceiling again. By widening memory addressing from 32-bit to 64-bit integers, it lifts the 4GB wall to 16GB on the web (theoretically far higher, currently limited by the JavaScript specification). So the progression is clear: plain JavaScript gives you the least usable memory, WebAssembly’s 32-bit linear memory gives you substantially more, and Memory64 gives you 4x more again – enough for a billion-point dataset in the browser.

The POC in SciChart.js v6

Memory64 support is landing in SciChart.js v6, alongside our new WebGPU rendering backend. It’s an opt-in feature, because the trade-offs (covered below) mean it isn’t the right default for every application.

Enabling it is a two-step process.

Step 1: Opt in via SciChartDefaults.useWasm64. The default value is , so nothing changes for existing users unless they explicitly turn it on:

SciChartDefaults.useWasm64 = EUseWasm64.Auto

Setting the flag to tells SciChart to use the 64-bit Wasm binaries when the environment supports Memory64, and to fall back gracefully to 32-bit wasm otherwise.

Step 2: Serve the wasm64 binaries. Because the 64-bit build is a separate binary, you need to make it available alongside the standard ones. Here’s what that looks like in a Webpack config using :

plugins: [
    new CopyPlugin({
        patterns: [
            { from: "src/static/favicon.ico", to: "" },
            { from: "src/static/index.html", to: "" },
            { from: "../src/_wasm/scichart2d.wasm", to: "" },
            { from: "../src/_wasm/scichart2d-nosimd.wasm", to: "" },
            { from: "../src/_wasm/scichart2d-64.wasm", to: "" },
            { from: "../src/_wasm/scichart3d.wasm", to: "" } // optional, if 3D is used,
            { from: "../src/_wasm/scichart3d-nosimd.wasm", to: "" },
            { from: "../src/_wasm/scichart3d-64.wasm", to: "" }
        ]
    })
]

From there, SciChart selects the correct binary automatically based on the runtime environment:

• Default:  / when WebAssembly SIMD is available (Chrome >= 91, Safari >= 16.4, Firefox >= 89).
• No SIMD:  / when SIMD is not available.
• Memory64:  / when Memory64 is available (Chrome >= 133, Firefox >= 143).

You don’t need to write branching logic. You serve the binaries from your server, set the flag to , and SciChart picks the best available option for each user’s browser.

Browser support

Memory64 shipped as part of WebAssembly 3.0, and support has matured quickly:

• Chrome / Edge (and other Chromium browsers): fully supported from Chrome v133, no flag required. This is where we’ve done the bulk of our billion-point testing.
• Firefox: supported in recent versions >= 143; depending on the exact release, it may still sit behind a configuration flag, so we’d recommend verifying against your target Firefox version.
• Safari: support has been arriving more recently and lags the Chromium browsers; treat it as the least mature of the three today.

The important point is that you don’t have to track browser support yourself. SciChart auto-detects Memory64 support at runtime. When it’s present, you get the 16GB ceiling; when it isn’t, SciChart silently falls back to the standard 32-bit binary with no code changes and no errors. Setting to Auto is therefore safe to deploy across a mixed audience – capable browsers get the upgrade, everyone else keeps working exactly as before.

What it unlocks

The headline number is memory, so let’s put it in concrete charting terms.

The browser’s traditional ~4GB-per-tab limit translates to roughly 200 million data points for a series of double-precision X and double-precision Y values (16 bytes per point, before you account for index buffers, GPU geometry, and everything else the engine needs). That’s already far beyond what most chart libraries can touch – but it’s a hard wall.

With Memory64 enabled, that ceiling rises to 16GB, and we’ve tested SciChart rendering one billion data points in-browser in Google Chrome. A billion points, interactive, in a browser tab.

Above: Proof of Concept – 1 Billion Datapoints generated and rendered in a JavaScript Chart, using SciChart.js v6 and Memory64. Test was carried out on a MacBook Pro M5 with 128GB RAM.

But just “more data points” is the wrong way to talk about the benefit of this, because it undersells what actually changes. Here’s the better case for why this matters in high-frequency, big-data visualisation apps:

Data only ever gets bigger. Sensor sampling rates climb, trading feeds get faster, genomic and scientific instruments produce ever-denser captures, and IoT fleets multiply. An application that comfortably fit under 4GB when it was built will eventually bump into that ceiling simply because the world’s data grew around it. Memory64 buys years of headroom rather than months.

It raises the ceiling of what’s possible, not just what’s bigger. The 4GB limit doesn’t just cap dataset size – it forces architectural compromises. Teams downsample on the server, stream data in windows, or throw away resolution to make things fit. Every one of those is engineering effort and a loss of fidelity. With 16GB, entire categories of workload that previously required a native desktop app – loading a full multi-gigabyte capture and scrubbing through it at native resolution – become feasible in the browser with no compromise.

It reduces the pain of memory fragmentation. WebAssembly linear memory can only grow, never shrink, and long-lived data-intensive sessions tend to fragment the heap: you may have plenty of total free memory but no single contiguous block large enough for a new allocation. Under a 4GB cap, fragmentation can trigger out-of-memory failures well before you’ve actually used 4GB. A 16GB arena gives the allocator dramatically more room to work, so real-world sessions are far more resilient and stay stable much longer.

It removes an entire class of failure modes. “The tab crashed because it ran out of memory” is one of the worst experiences you can hand a user analyzing critical data. Quadrupling the ceiling doesn’t just enable bigger datasets – it makes the applications you already ship more robust against edge cases and unexpectedly large inputs.

The caveats

We think it’s important to be upfront about the trade-offs, because Memory64 is opt-in for a reason.

• There’s a small, unavoidable performance cost. Browser engines have spent years optimizing around 32-bit pointers – tricks that let them avoid bounds checks and keep memory access tight. Those optimizations don’t all carry over to 64-bit pointers, so 64-bit Wasm carries some overhead by design. In our testing this works out to around a ~10% performance hit when wasm64 is enabled, and sometimes none at all, depending on the workload. It’s marginal, and it isn’t something we can optimize away – it’s inherent to how the browsers currently handle 64-bit memory. For the workloads that actually need this – the ones bumping against the 4GB wall – trading roughly 10% of throughput for 4x the memory ceiling is an easy call.
• Support isn’t universal yet. As covered above, Chromium browsers are solid, Firefox is close, and Safari trails. SciChart’s automatic fallback means this won’t break anything, but if your entire user base is on Safari today, you may not see the benefit until their support matures. The good news is, another feature shipping in SciChart.js v6 is WebGPU support, which is stellar on Safari. Due to Apple’s unified memory architecture, it makes the most of this newer graphics API.

Desktop-class visualization, now in the browser

Step back and look at where this leaves us. For years, the pitch for native desktop charting over web charting came down to three things: raw throughput, rendering performance, and memory capacity.

SciChart’s WebAssembly engine closes the throughput and performance gap: the C++ core and GPU-accelerated rendering already deliver frame rates and dataset sizes that outpace typical HTML5 / SVG charting, sometimes by 1-2 orders of magnitude. Memory was the last hold-out. The 4GB browser ceiling was the one argument a desktop advocate could still reach for.

With Memory64, that argument is largely gone. A billion points, interactive, at 16GB, inside a browser tab: that is genuinely desktop-class data visualization delivered over the web, with everything the web gives you for free: zero-install deployment, instant updates, cross-platform reach, and effortless sharing via a URL. Combined with the new WebGPU/WebGL backend also landing in v6, SciChart.js is now operating at parity with dedicated desktop applications across throughput, performance, and memory – the full trifecta.

What’s next

This is a proof-of-concept shipping in v6, and it’s the beginning of a longer roadmap for SciChart. As the browsers continue to optimize their 64-bit memory paths, the ~10% performance gap should narrow. As Firefox and Safari solidify their support, the fallback will fire less often and more of your users will get the upgrade automatically. And as WebAssembly 3.0 features mature across the board, the ceiling on what a browser can do will keep rising.

For now, if you’re working with genuinely large datasets – high-frequency trading, scientific and medical instrumentation, aerospace and automotive telemetry, or any domain where the data outgrew the browser years ago – Memory64 in SciChart.js v6 is worth a look. Set , serve the 64-bit binaries, and let SciChart do the rest.