Also, you, I’m pointing a finger right at you matomo devs out there, constantly tout that you have tuned your queries for MySQL as a reason for no being able to support PostgreSQL, except you can’t even support datawarehousing 100k requests per month without this horrible hack which seems to be extremely difficult to get configured.
PostgreSQL is perfect for this kind of work of continuously writing rows into a single table, but I have had to use the QueuedTracking plugin to store requests into Redis when we get a spike in requests because MySQL can’t cope with the influx (I also can’t run the archival process during the daytime because it causes the DB performance to fall apart.)
Basically, it’s apparent that MySQL isn’t suitable for our use case with Matomo but we have no other options, I’ve got to support MySQL just for this project (we use another PHP app, you might of heard of it, it’s Icinga2 but that supports PostgreSQL.)
It all comes back to you falling back onto this method of updating the database in MySQL for “high load” situations when you have been ripped apart for the insecurity of using this option in the github issues, and steadfastly refusing to consider probably the best high performing database alternative.
Given that the performance of your MySQL queries are already so poor I don’t think that moving over to an multi DB ORM is going to hurt things too much whilst coming with a benefit of allowing people to move to another DB.