back to microsandbox

benchmarks

the numbers come with the harness.

every figure here names the release it measured and the machine it ran on, and links the raw runs. rerun them yourself. that is the point.

01

cold starts you don't have to hide behind a warm pool

cold start / 320 ms

measured release: microsandbox 0.4.5. the release is inferred from benchmark chronology because the raw artifact does not record the binary version; the benchmark owner still needs to confirm it.

  • median of 10 measured runs after 2 warmups; end-to-end wall time from cli invocation to process exit; pre-pulled alpine userspace.
  • bare-metal linux x86_64 on a gcp c3-standard-192-metal host: intel sapphire rapids, ubuntu 24.04, /dev/kvm.
  • the same harness measured docker at 463 ms and firecracker at 808 ms. firecracker used the same alpine userspace; this does not use firecracker's narrower kernel-to-userspace boundary.
full harness and raw results

02

the filesystem should not be the slow part.

filesystem / 47.18×

measured releases: microsandbox v0.4 versus v0.3.14. geometric mean across fourteen mixed guest-visible filesystem workloads.

  • the suite ran three times against both versions on the same python image with fresh state between runs.
  • the v0.4 path replaced the v0.3 userspace filesystem with erofs and overlayfs inside the guest kernel. the result is a version-to-version microsandbox comparison, not a claim against another runtime.
methodology, implementation, and reproduction steps

03

fleet numbers ship when the harness does.

we run large concurrent fleets in production. our scale and idle density have moved a lot since the last full run, so we are holding those figures until the new benchmarks publish with their harness, held to the same standard as the numbers above. rather than post a stale number, we would rather post one you can reproduce.

read the harness, then run it.

open sandbox-bench