Data appendix

Cold vs warm distribution

Each dot is one invocation (the dense body is down-sampled, but every tail outlier at or above P98 is kept); ticks mark each series' cold and warm medians, computed from the full data. Selecting a memory tier rescales the x-axis, since latency ranges differ widely across memory.

Full percentiles, by scenario

Exact warm and cold percentiles (min / P10 / P50 / P90 / P99 / P99.9 / max, R-7 linear interpolation) for every measured series × memory cell in the current selection, with the sample count (n) behind each phase. How to read the cells:
  • Coverage. A cell absent because that scenario has a memory floor (e.g. batch, cache) is skipped. Rust is shown for opt-level=3 only (the o3-vs-oz A/B is on the Rust page). The two Smithy scenarios list Java, Java SnapStart, Node, and Rust only; Python and Go skip them.
  • What "cold" is. Cold = init (or restore) + first-request duration, both taken from the fields the Lambda REPORT line records. It excludes the code download + execution-environment provisioning that happens before init and appears in no function metric (measured separately on Cold Start Anatomy).
  • The cold tail is P90. Cold n is one sample per cold cycle and varies by scenario (see the per-cell n column). Even the fullest cold cell is too few for a stable P99/P99.9, so those cold cells read —; P90 is the cold tail to read, and max the worst observed.
  • Warm tail gates. The warm tail carries a P99 where the raw sample count reaches , and a P99.9 where it reaches ; below those floors the cell is blank.
  • The warm P99/P99.9 is a cross-cell comparison, not an i.i.d.-robust point estimate. Warm samples within one cold cycle share a sandbox, so they are correlated: the effective number of independent observations behind a warm tail is closer to that cell's cold n (its cold-cycle count) than to the much larger warm n, so a large gap is best confirmed with re-runs.

Disclaimer

This is an independent personal project. It is not affiliated with, endorsed, sponsored, or reviewed by Amazon Web Services or any of the companies whose products it measures (programming-language vendors, runtime maintainers, or anyone else). No company has tested, certified, or approved it, and nothing here should be read as an official statement from any of them. All trademarks belong to their respective owners.

The site is provided as-is, with no warranty of any kind. The numbers are best-effort measurements from a specific setup at a specific time: they can be wrong, misconfigured, skewed by the measurement harness, or simply out of date as runtimes, SDKs, and the platform change. No claim is made that any figure here is factually correct. Nothing on this site is advice; do not make production or purchasing decisions based on it. If a result matters to you, reproduce and verify it against your own testing in your own environment.