The Cold Start Problem
In serverless computing (like AWS Lambda or Cloudflare Workers), cold start is the latency between a request arriving and the function actually beginning to execute. This delay occurs when no warm instance of the function is available and the platform must provision a new one from scratch.
- Container cold start: The runtime must pull or locate the image, set up namespaces and cgroups, start the init process, load the application runtime (e.g., Node.js, JVM), and then execute the function. This pipeline takes anywhere from 500ms to several seconds for a typical function.
- Wasm cold start: The runtime loads a small binary into an already-running process, validates it (a one-time JIT compilation step), and begins execution. This takes microseconds to single-digit milliseconds — effectively imperceptible to users.
For a user-facing API at the edge, the difference between a 2-second cold start and a 2-millisecond cold start is the difference between a frustrating experience and an invisible one.
High Density and Resource Efficiency
Because Wasm modules are tiny and share the host process, you can run thousands of isolated Wasm instances on a single server simultaneously. Each instance consumes only the memory it actually uses — there is no per-instance OS overhead.
This density advantage is transformative for edge computing, where servers are physically smaller, located in hundreds of locations worldwide (close to users), and must handle highly variable, spiky traffic. Cloudflare Workers, for example, runs hundreds of thousands of customer functions on shared infrastructure using a V8 isolate model similar in spirit to Wasm's approach.
Where Wasm Excels Today
- Edge functions: HTTP request/response handlers running close to users (Cloudflare Workers, Fastly Compute)
- Plugin systems: Safely running untrusted third-party code inside your application (Envoy proxy filters, database extensions)
- Serverless functions: Short-lived compute with near-zero cold start
- Portable CLI tools: Single binary that runs on any developer's machine regardless of OS
Where Containers Still Win
Wasm is not a universal replacement for containers. Long-running stateful services (databases, message brokers, monolithic applications), workloads requiring complex OS interactions, and anything relying on mature ecosystem tooling (Kubernetes operators, Helm charts, service meshes) are still better served by containers. The two technologies are complementary, not competitive.
A common interview question: "Would you replace all your containers with Wasm?" The correct answer is nuanced: Wasm excels at short-lived, stateless, latency-sensitive workloads where cold start and density matter. Containers remain superior for long-running stateful services, complex OS dependencies, and workloads that benefit from the mature Kubernetes ecosystem. The best architectures will use both — Wasm for edge functions and plugins, containers for core services.