Announcement - Major update of API Performance Test Tooling

[shamasis]

Hello,

We are shipping a major upgrade to Postman’s API Performance Testing — an overhaul of the load-generation engine itself.

For context: the earlier engine comfortably handled ~500 Virtual Users on standard hardware. The new one scales to 5,000–10,000 VUs under similar conditions, while behaving far more predictably in terms of memory and resource usage.

This was a genuinely interesting problem to solve.

Postman’s load engine is built on Postman Runtime — battle-tested for over a decade for endurance, compatibility, and correctness. That foundation is what lets performance tests inherit the same robustness as Collection Runs. Scaling that foundation to sustain thousands of concurrent requests required targeted changes across critical runtime paths, and a hybrid disk + memory–backed streaming analytics layer to manage egress data efficiently at scale.

With this overhaul we can now process much more information during a performance run — and we leaned into that by shipping the second most-requested capability: capturing and analysing test results while load is being generated. You can now validate correctness and behaviour under stress, not just raw throughput.

We’re rolling this out gradually over the coming weeks.

As it lands for you, we’re excited to see the kinds of load-integrity guarantees you start asserting with it. We enjoyed tweaking our OS limits to test the load generation capacity. Do share how far your system can push these capabilities.

Performance testing is now available in the Postman CLI, enabling you to run load and correctness checks in CI using their existing Collections. This capability is being released as an open beta, giving you a chance to try it out and share feedback as we continue to refine the experience. Full documentation will be published soon; in the meantime, you can explore available options and learn more about how it works by running postman performance run --help in the Postman CLI.

Below, @scriptonist, @saialekhya-001 and @vinayakparashar go deeper — how it works, what changed, and how to start using it.

PS: We still have a few rough edges to iron out and I am looking forward to know what works and what breaks!

[shamasis]

[saialekhya-001]

Here is what it feels like when you use it,

The workflow is intentionally familiar: same Collections, same requests, same environments, same scripts. You do not need to relearn or rewrite anything to get a performance test running.

The first material difference is load configuration. The old concurrency ceiling is gone. You can now set the concurrency you actually want to test, instead of reshaping scenarios to fit a hard limit.

Local resource limits still apply. Very high concurrency will stress your machine. Postman monitors CPU and memory during runs, surfaces warnings as limits are approached, and automatically stops a run if thresholds are exceeded. This protects result integrity and keeps the machine responsive.

Results handling is also different. Metrics are streamed continuously through a disk-backed pipeline rather than accumulating in memory. This keeps metrics stable as load increases and makes trends visible during the run, not only after it finishes.

On first use, the streaming engine core is downloaded once. Subsequent runs reuse it and stay fast.

In performance run test results, the biggest shift is visibility. Alongside latency and error rates, correctness is now observed under load. Existing collection tests run at scale, so script runtime errors and assertion failures are surfaced directly as concurrency increases. You can see what started failing, when it started failing, and how failure rates change as concurrency is varied.

The interface is unchanged. But you will see higher load without an artificial ceiling, stable metrics under stress, and correctness signals that are attributable instead of inferred.

[scriptonist]

Building on what @saialekhya-001 has put forth, the change really shows up in how you interpret performance results.

A test can stay green under load simply because requests keep returning 200 OK — even when the API is no longer behaving correctly. This gap has come up repeatedly from users, including in issues like #11985.

With assertions running during performance tests, you can see when correctness starts breaking as concurrency increases — not just whether the system stays fast.

Some checks remain stable under load. Others degrade gradually. A few fail consistently beyond a specific virtual-user threshold. That gives you a concrete boundary instead of a vague sense that something becomes flaky “at scale”.

This carries cleanly into CI. When Collections run under load, the same checks are evaluated automatically — allowing you to gate not just on latency or error rates, but on correctness holding up as concurrency increases.

Same Collections. Same assertions. Just exercised under more pressure.

Once this runs end-to-end in pipelines, performance tests start answering a different question: how much load your system can handle before behavior, not just speed, breaks down.