Blog
Notes from building Sumimi. The stories behind the decisions, the measurements behind the numbers, and the data itself — with the method written down, so the claims can be checked.
-
Leaving Umami: one small VPS, two problems
A 1 GB box, a 20 GB disk and a handful of small sites. The disk kept filling up, the dashboard kept stuttering, and the six-month-old panels had turned into a wait. Why the fix was a storage engine and not another analytics tool.
-
Why DuckDB: 85× smaller, and why we keep no indexes
The same rows in two engines: 4 750 bytes per page view on PostgreSQL, 56 bytes on DuckDB. Where the difference actually comes from — and why the answer is not "the compression", but "no indexes on a table that is only ever appended to".
-
How much traffic can a 1 vCPU box take?
The rule used to be 68 MB plus 7.8 MB per 1 000 requests a second. After seven fixes the curve is flat, the memory promise holds with room to spare, and the CPU is what limits a small box — with the method, the traps and the numbers written down.
What goes here
- Posts — the story behind a decision, and the reasoning that did not fit in a design document.
- Case studies — a box, a site, a migration, and what the numbers looked like afterwards.
- Data — the measurements themselves, published as they are taken, including the ones that did not come out the way we expected.
Everything here is also in the repository: the architecture in AGENTS.md, the memory strategy in MEMORY.md, and the benchmark reports in benchmarks/.
Sumimi / 数咪咪 is an independent open-source project. It is an open-source alternative to Umami and implements the Umami v2 HTTP API; no Umami assets are used. Licensed under the Apache-2.0 licence. Third-party names are referenced nominatively.