Comment by pacmansyyu | Hacker News Reader

Comment by pacmansyyu | Hacker News Reader

We recently migrated from Matomo to Umami at work after hitting scaling issues with Matomo, even after implementing various MySQL optimizations and archiving reports through cron at a decent interval. Even the most basic tasks like loading the dashboard was painfully slow (before you comment on the resource usage, our instances were quite huge and the load was alright).

Surprisingly, Umami has been handling our traffic volume without breaking a sweat on much smaller instances. I suspect PostgreSQL's superior handling of concurrent writes plays a big role here compared to MySQL/MariaDB. Except for the team/user management, everything feels much nicer on Umami.

Shameless plug: As part of the migration, I also took the opportunity to learn some Rust by writing a small utility that uses the Umami API to generate daily/weekly analytics reports and sends them via email[1]. Pretty happy with how it turned out, though I'm still learning Rust so any feedback or suggestions for improvement are welcome!

[1]: https://github.com/Thunderbottom/umami-alerts

I am also curious about the traffic amount and server specs.

In my experience, MySQL still runs very well until you have 10-20m rows (on a single machine, like 8vCPU and 32GB RAM), after it gets trickier to get instant responses.

We had huge servers, with the database and the application itself running on separate instances. IIRC, we had a 32 core, 64GB instance just for the DB itself which we doubled when we started adding more sites to our configuration and it still wasn’t enough. As for the numbers, our site(s) get heavy traffic everyday, in millions daily, since we are a stock broker.

You’re right about MySQL performing alright for 10-20m rows, but from our perspective those numbers are not that big for a company this size.

> our site(s) get heavy traffic everyday, in millions daily

Yeah, it's hard to run aggregate queries on MySQL once you are talking about hundreds of millions of rows, or billions. Even though, if the server has modern CPU, enough RAM to store the entire DB and NVMe storage, it's still okish with the right indexes and if the queries are optimized.

Thanks for sharing!

Could you describe a bit the load and the server/db specs? I’m using Plaisible right now and I wonder how it would handle with similar specs

We had separate database and app instances, the DB instance had 32 cores and 64GB memory, which we doubled to keep up with our requirements. We have tens of millions of visits daily, and our database was close to ~300GB within the first few months.

For plausible I believe that since it runs on Postgres, scaling should not be a problem as long as you scale the resources with it.

For my platform, I found those optimization tips to work quite well: https://docs.uxwizz.com/installation/optimization-tips/mysql...

In all honesty, these optimizations are quite basic. We already used MariaDB instead of MySQL itself. Other things listed in the post are something that we have standard across all our databases, well, except for deleting the data to speed up the database.

Have you also considered Percona MySQL server? I think they say they have the best performance (but I haven't tested their implementation yet).

No, unfortunately our company’s and external regulatory compliance policies require us to host all data within the country itself, alongside it being required to be run on an infrastructure that is easily auditable. So as a policy within the company, all our internal services are open source and self hosted.

Umami also support MySQL as well and I do t remember having much different between Postgres or MySQl as backend.

Things would hopefully be even better once clickhouse support lands.

Reply on news.ycombinator.com