r/node • u/iam_bigzak • 2d ago
pboss vs pm2 on Node: cluster mode is a blowout, and the fork-mode "losses" are noise
We ran pboss 1.8.0 against pm2 5.4.3 on Node 24. Same server.mjs, same binary, same machine, same autocannon profile (10/100/500 connections, 60s, 5 repeats). Cold start of the whole manager stack every run, manager order alternating, CPU and RAM sampled across the entire process tree. The numbers below measure the cost of managing a server, not Node's raw HTTP performance.
Cluster mode: pboss wins almost every row
Both managers cluster Node apps natively through node:cluster, same worker count, same sharing mechanism. The only variable is the manager itself. And under that fair fight pboss pulls away at every load level.
100 connections, 2 workers:
| Metric | pm2 | pboss |
|---|---|---|
| req/sec | 55,954 | 58,539 (+4.6%) |
| latency (mean) | 1.25 ms | 1.18 ms (-5.6%) |
| p90 latency | 4 ms | 3 ms (-25%) |
| RPS stdev | 1,355 | 660 (-51%) |
| CPU (tree) | 76.0% | 75.3% |
| cold start | 624 ms | 427 ms (-32%) |
At 10 connections pboss is still ahead: median RPS +5.6%, p99 latency 2ms vs 3ms. At 500 connections it holds: +1.7% mean RPS, better latency at p50/p90, steadier RPS. Not one row of lost throughput. Plus lower CPU across the board.
Crash recovery and restart storms, where "production ready" actually gets decided
- SIGKILL the whole fork-mode server: pboss brings
/healthback to 200 in 68ms median vs 128ms for pm2. Worst case across all runs: 70ms vs 194ms. - SIGKILL one of two cluster workers: pboss respawns it in 93ms vs 151ms, worst case 103ms vs 199ms.
/healthnever dropped on either, as it shouldn't with a survivor holding the port. - 50-restart storm, fork: median restart 181ms vs 376ms (52% faster). Zero failures, zero orphans on both sides. But the app RSS after the storm: 58MB for pboss vs 71MB for pm2, and pboss's memory shrank 0.3MB over the storm while pm2's grew.
- 50-restart storm, cluster: 300ms vs 498ms (40% faster), workers' RSS around 20% lower, growth of -0.1MB vs +1.6MB. Again zero failures, zero orphans.
Faster recovery, tighter memory, no leaks under punishment. Fifty restarts later the tree is clean.
Startup time deserves its own section honestly
| Metric | pm2 | pboss |
|---|---|---|
| cold, fork | 520 ms | 396 ms |
| warm, fork | 270 ms | 174 ms |
| cold, cluster | 637 ms | 419 ms |
| warm, cluster | 422 ms | 242 ms |
Warm cluster restarts are 43% faster. For anyone doing rolling deploys or watch-mode dev, that adds up all day.
Fork mode: mostly pboss, and here's the scoreboard
Fork mode at 100 connections, one managed process:
| Metric | pm2 | pboss |
|---|---|---|
| Median req/sec | 56,278 | 57,517 (+2.2%) |
| Mean req/sec | 57,512 | 57,519 (tie) |
| RPS stdev | 2,696 | 1,180 (-56%) |
| latency (mean) | 1.44 ms | 1.40 ms (-2.8%) |
| p50 latency | 1.00 ms | 1.00 ms (tie) |
| p90 latency | 1.00 ms | 1.00 ms (tie) |
| p99 latency | 26.00 ms | 26.00 ms (tie) |
| CPU avg (tree) | 73.9% | 74.0% (+0.1%) |
| CPU peak (tree) | 79.6% | 78.8% (-1.0%) |
| memory avg (tree) | 179.1 MB | 168.3 MB (-6.0%) |
| memory median (tree) | 184.3 MB | 174.2 MB (-5.5%) |
| cold start | 520 ms | 395 ms (-24%) |
| errors / timeouts / non-2xx | 0 / 0 / 0 | 0 / 0 / 0 |
Clean sweep where it counts: tied throughput at the mean, +2.2% at the median, RPS stdev cut in half, 6% less memory, 24% faster cold start. The only row pm2 takes is average CPU by 0.1%, which is a tie wearing a mustache.
Across the other load levels it's the same story: pboss uses 2 to 8% less tree memory and starts 23 to 26% faster at every one.
Where pm2 actually beat us
Two-ish rows, and they're small:
- At 10 connections (a nearly idle server) pm2's median RPS was 1.5% higher and its RPS spread was tighter. On a box where the load generator shares the CPUs, that's inside the noise.
- At 500 connections, fork mode, pm2's median RPS was 1.2% higher and mean latency 1.9% better (8.58ms vs 8.74ms). Mixed row, tiny margins both ways.
- Cluster mode tree memory is 11% higher under pboss. This one is real and it's architectural: pboss runs a supervised wrapper primary above the workers, so there's one more small process in the tree. You buy it back in startup speed (30 to 35% faster) and respawn speed (38 to 48% faster). Idle daemon memory is actually 5% lower than pm2's.
That's the honest list. Everything else across the whole report goes to pboss.
Everything around it
Health checks, cron restarts, log rotation with gzip, web dashboard, Prometheus /metrics, namespaces, dependency-ordered startup, replace-first rolling reloads. Built directly on node:child_process, node:http, node:fs. Open source, GPLv3.
Don't take our word for it. Every number traces to a raw file in results/raw/, the load generator shared CPUs with the servers so compare the columns rather than quoting absolutes, and the benchmark script is three commands:
cd benchmarks/node && npm install
bash scripts/benchmark.sh
Rerun it on your own hardware and tell us what changes.
2
u/drgreenx 1d ago
Wait people use this stuff for prod deployments?
1
u/iam_bigzak 1d ago
Yes, we have fixed and closed about 33+ issues from people using it in real production environment, pboss cloud has about 12 users using it in production
3
u/jiminycrix1 2d ago
Ok this piqued my interest and honest take here:
The latest version of PM2 also supports bun and deno and has removed tons of bloat. I would like to see the benchmarks updated to compare to the new versions. It's core is also extremely battle tested, hardened, and easy to follow when looking at the code. PM2 has also proven its commitment to long term maintenance.
This on the other hand seems very AI assisted and the code is difficult to follow. It appears to have a ton of features, which may seem attractive, but I am not sure I can trust the tests and reliability of this project. It is not super compelling for me to switch.
OTOH, as far as AI driven projects go, this one is 7 months old and does appear to have care when it comes to the architecture and honesty in the bench marks, which I appreciate. While I am intrigued and feel we could use more competition in this space to PM2. I don't think I would use this package.
Perhaps if I could see some testimonials and could avoid the bloat of features I don't need somehow and had a few more compelling things that make it different than PM2, I would be willing to test it out more.
Good luck to you though!