WASM vs container cold starts: what runtimes say

Cold start refers to the additional latency paid by a request when the execution environment must initialize before the application code runs. On a classic edge or serverless function, this is far from being a marginal case: a platform that goes down to zero instances between two traffic peaks, or that distributes its execution across dozens of geographically dispersed edge nodes, pays this cost permanently, not just on the first deployment.

The subject has taken on an almost symbolic importance in the WASM ecosystem since a sentence from Solomon Hykes, co-founder of Docker, published on Twitter in March 2019: “If WASM+WASI existed in 2008, we wouldn’t have needed to create Docker. That’s how important it is. WebAssembly on the server is the future of computing. » This is an opinion of a recognized practitioner, not a measurement. It explains why the subject fascinates, it does not replace a sourced figure.

Aurabase offers two paths for its edge functions: the Studio editor, which runs code in the Deno runtime as documented in our Supabase migration guide, and the aura functions deployCLI, which aims for a separate path for functions written in Rust and compiled to WASM on Wasmtime. It is this second path that this article sheds light on, without giving it a cold start figure which does not yet exist.

The difference does not come from a faster runtime in absolute terms: it comes from a shorter stack of steps between the query and the application code.

Starting a container mobilizes the host kernel: creating a new process, setting up the cgroups and namespaces that isolate it, mounting the layers of the image, then starting the application runtime inside (Node.js and its V8 engine, for example, themselves have an initialization cost). Each step adds system calls and, for an image never seen locally, a network download before it even begins.

A WebAssembly module is isolated at the virtual machine language level, not at the operating system level. Instantiating a module means allocating its linear memory, binding its imports, then jumping to its entry point, all within the already started process of the host runtime. No new processes, no image layers, no default file system mounts.

The choice of compilation mode adds an additional variable. Wasmtime compiles to JIT via its Cranelift backend when the module loads, or can precompile it in advance with wasmtime compile, which produces a .cwasm file already transformed into native machine code. Early compilation (AOT) removes the compilation step from the critical path of the request: this is exactly the lever that an edge architecture sensitive to cold start must activate.

# Actual extract from Aurabase repository
# WASM Runtime
wasmtime = { version = "43", features = ["async", "cranelift"] }

This is a production dependency, not development: it confirms that Wasmtime actually runs on the CLI path of the Aurabase edge functions. However, it does not confirm any latency figures, which remains true as long as no dated benchmark is published.

In this area, the strongest source is an industry research paper, not a marketing blog post. Firecracker, the lightweight microVM technology developed by AWS and used notably for Lambda and Fargate, was presented at the USENIX NSDI 2020 conference by Agache et al. in the article “Firecracker: Lightweight Virtualization for Serverless Applications”.

This paper documents a boot time of less than 125 ms and a memory overhead of less than 5 MiB per microVM, with the ability to run thousands of microVMs on the same physical machine. This is a dated figure (2020), sourced from a peer-reviewed academic publication, and widely cited since then in the literature on serverless isolation.

A standard Docker container is generally higher: from a few hundred milliseconds to several seconds depending on the size of the image, the need to download it, and the boot time of the embedded application runtime. There is no single figure universally cited here, unlike Firecracker: the result depends too much on the image tested for a single value to achieve consensus.

Three sources, three different statuses: a historical supplier, a project under foundation governance, and a research paper.

Fastly launched Compute@Edge in 2019 on Lucet, its own pre-compiling WASM compiler and runtime. At this launch, the company documented WASM instantiation times below a millisecond, an order of magnitude that had a lasting impact on the WASM cold start discourse in the industry. In 2021, Fastly ceased autonomous development of Lucet and redirected its efforts towards Wasmtime, whose Cranelift compilation backend inherited part of these optimizations: this is one of the reasons why Wasmtime remains a reference today for this type of load.

WasmEdge, a WASM runtime under CNCF governance (originally SSVM, supported by Second State), claims in its official documentation a significantly lower startup and memory footprint than an equivalent Docker container, with an explicit positioning on edge and IoT loads. This is a figure published by the project publisher itself, to be read as such: a product claim, not an independent audit.

On the academic research side, Faasm (Shillaker & Pietzuch, USENIX ATC 2020, also available in pre-publication) builds a stateful serverless platform relying on WebAssembly isolation (via WAVM, not Wasmtime) precisely because it allows a function to be instantiated at a much lower cost than isolation by container or by VM. The paper is not specifically about Wasmtime, but it provides independent academic validation to the structural argument in the previous section.

Comparing these three runtimes only by name hides the real variable: the compilation backend chosen, which radically changes the balance between startup speed and execution performance.

Singlepass, Wasmer's fastest compilation backend, exists precisely because its team identified cold start as a distinct axis of steady-state execution performance: a module compiled in Singlepass starts faster, but runs slower during peak load than the same module compiled in LLVM. It’s an accepted compromise, not a hidden flaw.

These five lines do not read as a single classification: they come from different methodologies, dates and runtime generations. For a more in-depth methodological critique of the reliability of this type of WASM benchmark, our article on the limits of WebAssembly benchmarks goes further than the present comparison, which remains focused on what each source concretely asserts.

The cold start advantage of WASM counts most on the loads most sensitive to the latency of the first request, not on all loads equally.

It particularly weighs on very irregular edge traffic (bursts followed by silences), on isolation per request rather than per container shared between several requests, and on an infrastructure which actually goes down to zero instances between two peaks rather than keeping a hot pool permanently. On a stable and predictable load, where instances remain hot anyway, the cold start gap structurally matters less.

WebAssembly also maintains constraints distinct from cold start: access to the file system or the network goes through WASI, an interface still evolving depending on the runtimes and their versions, and a module compiled to start quickly (Singlepass on the Wasmer side, for example) is not necessarily the fastest once established under heavy load. Cold start and peak execution performance remain two distinct axes, rarely optimal simultaneously on the same compilation profile.

To evaluate a choice of edge architecture on this criterion, three concrete questions to ask any supplier, Aurabase included: which exact runtime is used, which compilation backend (JIT or AOT), and has the advanced cold start figure been measured by an independent third party or only by the runtime publisher itself.

For the database layer of this same problem, see our article on the serverless Postgres cold start.