The trees are hiding the forest. You are getting lost in the details.
My point is that Kodi uses the database in a quite inefficient way. That inefficiency resides in Kodi, not in the database engine. For instance, for many operations, the memory usage in Kodi is proportional to the number of elements in the database. This is not solved changing the database.
I can provide tons of examples. I can provide measurements. Do not ignore my warnings just because your use case is not my use case.
Check the link I posted. Understand the issue. Get the enlightenment when you get the fact that the change I propose increases performance x15. Yes, maybe in this particular case MySQL is able to do the optimization by itself, but this is only an example of MANY and most of them can be traced back to “Kodi should do better”.
I can provide more examples of performance and memory waste if interested. Choose the flavor you want, I have it.
To get a full film listing Kodi asks the database for the details of ALL the films at once. It load that response for the database in RAM (In my case ~150 MB of RAM just burn) and then Kodi iterates over that data in RAM to build 12.000 objects to display in a screen with at most 12 banners per screen.
Al least Kodi should build those 12.000 display objects (a big waste by itself) while iterating the response from the database, instead of loading all the response in RAM at once. That would save ~150MB of RAM in my current database. That simple change: instead of reading the DB response at once and then create the structs in memory, create the structs incrementally from each row fetch.
This is not dependent of the DB engine used but the way Kodi uses the engine. Changing the engine doesn’t bring back those ~150 MB wasted.
I am suffering those inefficiencies because of my database size, true, but those inefficiencies are real, they are hitting somebody real (me) and that sad soul has invested quite a few hours analyzing the issue and proposing a solution or, at least, a “hack”.
Of course, a valid answer would be “you are way out of the DB size sweet spot and we don’t care about such an extreme use case”. That would be unfortunate, but life sucks and time is short.