Same contract
Each stack exposed ping, users, projects, events, search, and mixed-flow endpoints against PostgreSQL-backed application data.
Benchmark evidence
Nidus Framework Benchmark
Bounded homelab run comparing Rust/Nidus, FastAPI, Spring Boot, and Express with the same endpoint contract, PostgreSQL persistence, one replica, and a matched application deployment envelope.
Method
Bounded homelab run, not a max-throughput or capacity ceiling.
Same envelope
Each app used one Kubernetes replica, ClusterIP service exposure, and the same application deployment shape.
Paced profile
The k6 harness used constant VUs and a short sleep per iteration to protect shared homelab workloads, so throughput is intentionally bounded.
Results
Latency stayed low across every application-shaped profile.
Rust/Nidus was the latency leader or effectively tied across the run. The mixed profile is close enough to treat as a tie with Java rather than a broad superiority claim.
| Profile | Stack | req/s | avg latency | p95 latency | failed | checks |
|---|---|---|---|---|---|---|
| ping | rust-nidus |
156.890883/s | 423.72us | 659.57us | 0.00% | 100.00% |
| ping | python-fastapi |
148.264889/s | 3.35ms | 4.22ms | 0.00% | 100.00% |
| ping | java-spring |
154.820432/s | 1.13ms | 1.88ms | 0.00% | 100.00% |
| ping | node-express |
155.442129/s | 1.08ms | 1.78ms | 0.00% | 100.00% |
| users | rust-nidus |
297.482161/s | 1.59ms | 3.45ms | 0.00% | 100.00% |
| users | python-fastapi |
278.858057/s | 3.32ms | 6.01ms | 0.00% | 100.00% |
| users | java-spring |
292.89576/s | 1.97ms | 3.82ms | 0.00% | 100.00% |
| users | node-express |
291.549083/s | 2.11ms | 4.31ms | 0.00% | 100.00% |
| projects | rust-nidus |
423.939646/s | 1.95ms | 3.46ms | 0.00% | 100.00% |
| projects | python-fastapi |
380.644823/s | 4.03ms | 7.17ms | 0.00% | 100.00% |
| projects | java-spring |
417.118223/s | 2.26ms | 4.17ms | 0.00% | 100.00% |
| projects | node-express |
414.234335/s | 2.37ms | 4.24ms | 0.00% | 100.00% |
| events | rust-nidus |
282.357362/s | 2.97ms | 4.07ms | 0.00% | 100.00% |
| events | python-fastapi |
267.55211/s | 4.5ms | 6.86ms | 0.00% | 100.00% |
| events | java-spring |
281.790144/s | 3.03ms | 4.22ms | 0.00% | 100.00% |
| events | node-express |
279.668233/s | 3.23ms | 4.65ms | 0.00% | 100.00% |
| mixed | rust-nidus |
232.594368/s | 2.72ms | 7.05ms | 0.00% | 100.00% |
| mixed | python-fastapi |
223.820298/s | 4.01ms | 8.35ms | 0.00% | 100.00% |
| mixed | java-spring |
232.940412/s | 2.7ms | 6.84ms | 0.00% | 100.00% |
| mixed | node-express |
230.302808/s | 3.03ms | 7.3ms | 0.00% | 100.00% |
Interpretation
What this proves, and what it does not.
Supported claim
Under this conservative Kubernetes workload, Nidus completed the shared contract with zero request failures and consistently low latency.
Bounded claim
The req/s values are end-to-end paced workload results. They should not be presented as absolute capacity numbers.
Next proof layer
A capacity study would remove pacing, run longer windows, repeat samples, and isolate bottlenecks with continuous profiling.