october 16, 2025 · 1 min read · backend, performance, rust, go, elixir
One million requests, six backend stacks
Stress-testing Rust, Go, Node.js, Erlang and Elixir at a million concurrent requests, and what runtime design does to performance.
What happens when you throw a million concurrent requests at six different backend stacks? I found out, and the results challenged a lot of what I thought I knew about performance.
While building a product at Suprdense, I stress-tested how different backend ecosystems hold up when pushed to the edge: a million concurrent POST requests across Rust (Axum and Actix), Go, Node.js, Erlang and Elixir with Phoenix, on AWS. What I found wasn't just raw speed differences, but how runtime design fundamentally shapes performance, scalability and reliability.
The numbers
| Stack | Peak throughput | Notes |
|---|---|---|
| Rust + Actix | 214,000 RPS | Fastest, with more boilerplate |
| Rust + Axum | 189,000 RPS | Slightly slower, much easier to set up |
| Go | 140,000 RPS | Not the fastest, but steady |
| Erlang + Cowboy | 60,000 RPS | The BEAM's proven concurrency model |
| Elixir + Phoenix | n/a | Prioritised stability; solid under stress |
| Node.js | 45,000 RPS | Struggled under sustained load (single-threaded limits) |
Elixir with Phoenix prioritised stability over speed. The BEAM's actor model stayed solid under stress, proving that "let it crash" works for distributed systems.
My take, after working with all six
- Erlang and Elixir: unmatched for systems that need to stay alive. When reliability matters more than raw speed, nothing else comes close.
- Rust + Axum: modern async performance with a nice developer experience. The compiler is strict, but it catches problems before they reach production.
- Rust + Actix: slightly higher performance, but the added boilerplate feels daunting next to Axum.
- Go: the sweet spot for most production applications. It balances performance, maintainability and team productivity better than the alternatives.
- Node.js: excellent for rapid prototyping and MVPs, but needs care for high-load services.
The biggest lesson? Don't optimise for a single metric; understand the context. Your stack should align with business objectives and team capabilities, not just benchmark scores.
Originally posted on LinkedIn.