Benchmarks
Every number on this page was measured by siteboss benchmark — a built-in tool
that runs on your hardware so you can verify the results yourself.
Results vary by CPU, RAM, and kernel settings. The numbers below were recorded on a 20-core / 122 GB machine running Linux 6.14. Your mileage will differ — that is the point. Run the benchmark, get your own numbers, and plan capacity from real data.
Headline Numbers
| Metric | WASM (measured) | Docker | Firecracker | smolvm |
|---|---|---|---|---|
| Startup time | ~105 µs | ~100 ms | <125 ms | <200 ms |
| Memory per instance | ~0.1 MB | ~30 MB | ~133 MB (<5 MB overhead + 128 MB guest) | Elastic (balloon); <5 MB overhead + guest |
| Max concurrent (122 GB host) | ~698,945 | ~3,657 | ~825 | ~825 (comparable to Firecracker) |
| Throughput | ~9,436 instantiations/sec | — | ~150/sec/host | — |
| Isolation model | Language sandbox (WASI) | Kernel namespaces | KVM microVM | KVM microVM |
Sources:
WASM column measured with siteboss benchmark on this host.
Docker ~100 ms startup from community benchmarks (no official figure published).
Firecracker <125 ms startup and <5 MiB overhead from
firecracker-microvm.github.io;
128 MB guest RAM from the
Firecracker design doc baseline config.
smolvm <200 ms boot from
smolmachines.com (Y Combinator W25).
Firecracker ~150 microVMs/sec from the design doc (5/core/sec, 30-core host).
Concurrent estimates = available memory / memory per instance.
What This Means for Startups
Infrastructure cost is driven by two things: how many instances you need and how much memory each one burns. WASM components flip both numbers in your favor.
Total Memory for N Instances
| Instances | WASM | Docker | WASM Advantage |
|---|---|---|---|
| 1 | ~22 MB | ~180 MB | ~8x less |
| 10 | ~23 MB | ~450 MB | ~20x less |
| 100 | ~29 MB | ~3.1 GB | ~109x less |
| 1,000 | ~90 MB | ~29.4 GB | ~334x less |
The gap widens at scale because WASM per-instance cost (~0.1 MB) is orders of magnitude lower than Docker (~30 MB). The one-time runtime overhead (~22 MB for the Wasmtime engine) is amortized almost immediately.
Cloud Cost Implications
Consider a workload that needs 500 concurrent instances:
- Docker: ~15 GB RAM required → multiple large VMs or a dedicated node pool
- WASM: ~56 MB RAM required → fits on the smallest cloud instance available
That is not a marginal saving — it is the difference between a $200/month cluster and a $5/month VPS. For startups watching burn rate, WASM components let you ship production workloads on hardware you can actually afford.
Cold Start vs. Warm Start
The benchmark measures two distinct phases:
- Cold start (~23 ms): Engine initialization + Cranelift compilation + first instantiation. This happens once when the runtime boots.
- Warm start (~105 µs): Instantiating a new component from a pre-compiled module. This is what your users experience on every request after the first.
For comparison, Docker cold start is ~90 ms and there is no equivalent "warm start" — each container launch pays the full cost.
Concurrent Capacity
On the test machine, siteboss benchmark created ~698,945 live WASM instances
before hitting the kernel vm.max_map_count limit — not a memory limit. Only 46.4 GB of
109.7 GB available RAM was used.
To unlock the full capacity of your hardware:
Run Your Own Benchmark
Install siteboss and run the benchmark on your own hardware. No account required. No network calls. Everything runs locally.
The benchmark uses a 13.7 KB embedded hello-world component. It measures real Wasmtime instantiation — no mocks, no simulations, no synthetic load generators. What you see is what you get.