Muon vs Umami Benchmark
An internal benchmark on the same Umami-compatible /api/send endpoint, identical PostgreSQL setup and realistic traffic.
How much faster is Muon than Umami?
In an internal benchmark on identical hardware and Postgres, Muon reached ~6.4× higher peak throughput, ~7× lower p99 latency, ~20× lower idle memory and ~70× faster warmup. It is an internal benchmark; results vary by hardware, Postgres config and traffic shape.
Same endpoint, same Postgres, isolated databases.
Both systems received the identical event workload through the same Umami-compatible tracking endpoint shape, each backed by its own PostgreSQL database on the same host.
Higher throughput, lower latency, a fraction of the footprint.
Headline numbers from the run, then the full metric-by-metric comparison.
| Metric | Muon | Umami | Difference |
|---|---|---|---|
| Peak throughput | ~5,800 rps | ~900 rps | 6.4× higher |
| p99 latency | 15 ms | 111 ms | 7× lower |
| Idle memory | ~12 MB | ~275 MB | 20× lower |
| Load memory | ~29 MB | ~605 MB | 20× lower |
| Image size | 160 MB | 1.28 GB | 8.2× smaller |
| Warmup | 0.16 s | 11.2 s | 70× faster |
Where each system hits its limit.
Under this workload, Muon becomes PostgreSQL-bound while Umami remains application-runtime-bound. Muon's Rust core spends so little time per event that the database becomes the ceiling; Umami spends most of its budget inside the Node/Next.js application runtime before a query is ever issued.
This matters because a Postgres bottleneck can be addressed with batching, indexing, partitioning, read replicas or future analytical storage. An application-runtime bottleneck is harder to scale efficiently — you are paying overhead on every event regardless of how the database is tuned.
Run the benchmark yourself.
The harness and methodology ship in the repository, so you can reproduce the run on your own hardware and Postgres configuration.
# clone, then run the benchmark harness
git clone https://github.com/runmuon/muon && cd muon && ./bench/run.sh
Read this before quoting the numbers.
- This is an internal benchmark run by the Muon team, not an independent third-party evaluation.
- Results may differ by hardware, PostgreSQL configuration and traffic shape.
- Hot-row visitor behavior — many events concentrated on the same visitor rows — narrows the gap, and is an active optimization target.
Questions, answered directly.
Is this an independent benchmark?
What was the workload?
Why does Muon use so much less memory?
Will I see the same numbers?
See it for yourself.
Deploy Muon with Docker in minutes, or read how it compares to Umami feature by feature.