How we measure

Every number on this site comes from our own tests on the production microVM runtime, run on 2026-10-28 and 2026-10-29. Here is exactly how, and where the tests fall short.

How was a memory floor measured?

Each service was built as an image and started at decreasing memory sizes. At each size we ran that product's own checks, such as writes, queries, crash recovery or indexing. The floor is the smallest size that passed. Below it the virtual machine failed at boot or crashed with a kernel panic ("deadlocked on memory"), or could not load.

Published sizes round the measured floor up to the next multiple of 32 MB, so a published floor can be larger than the smallest size that passed.
Most floors come from a single probe series, so a few megabytes of noise is possible.
Checks differ by product, so floors are not comparable as benchmarks.
A floor is not a sizing recommendation. Real workloads need more memory.

How were wake times measured?

With a small test image on a free-tier account. The platform reported a mean wake time of 29 ms across 24 wakeups, all in its 16 to 32 ms bucket. End to end from a laptop with a network round trip of about 240 ms, the median request after a wake took about 273 ms over 10 runs, against about 252 ms for a warm instance. A first start of a new image pulls it and took about 3.8 seconds. Wake times for each real service were not measured separately.

How was expiry tested?

A scheduled absolute delete removed a running instance at its scheduled time, and an idle-based delete removed a standby instance within 20 seconds.

What was found about isolation?

Services on the hosting platform share a flat private network and can reach each other. That is why every service requires authentication.

What is not measured?

Uptime, throughput under sustained production load and customer usage.
Real push delivery to Apple or Google services.
Behaviour under sustained production load.

Per-service results are on each service page. Definitions are in the glossary.