@roti_WMDE it seems that configuring mariadb is contained enough in itself via the mariadb server and our devops user know how to work with it. Overriding mariadb config from the WBS seems like a step that can come with more pitfalls than gains:

1. the maintenance of such code requires time and effort - If mariadb makes changes in how to manage their config, or names or anything related we need to be aware of it all and change our code too
2. documentation needs to be well maintained as well and will need as much love as the code in the above bullet point

What is driving your wish to make this happen? am I missing sth here?

This is true. Maybe one of the underlying questions is "How much of a convenience layer do we want to add in WBS Deploy?". There is definitely room for discussion and research here.

I thought it might make sense when we made LocalSettings.php and php.ini accessible in deploy/config. I guess the vision was kind of deploy/config containing all the relevant config files for the user, such as MediaWiki, PHP, Maria, WDQS, etc.

One could argue that MariaDB appears to be quite a stable piece of software, so changes in config handling are rather unlikely. Exposing the config file does not add much documentation requirements besides "here is your config file, check mariadb docs for options". At the same time we would have a place for config suggestions here.

I am happy to close it for now though. There are definitely more interesting discussions to have.

thanks a lot for the reply, @roti_WMDE ! I definitely see your point. I do agree as well, that we have right now other bigger broccolis to fry. Ultimately, I still see this as a product decision since it is sth that would be a change in the approach that our users have to wikibase suite, hence, affect them directly. Pinging @jon_amar-WMDE :)

If the topic is scaling issues, then I think the most valuable contribution for the Wikibase Suite right now would be writing, testing, and updating documentation about scaling Wikibase itself as wikis grow, applicable across all deployment methods, not just Wikibase Deploy.
Scaling of these other things that have existing communities, such as mysql, are as pointed out in the description already documented.
If Wikibase deploy has made achieving such modifications to the msyql config harder thats unfortunate, but I'd like to think still that its easily possible for the user to do by using their own container? (I'm not sure how much magic has been built around the containers as part of deploy these days)

Given the recent discussions in the Telegram group about the broader scope of the Suite, I believe it’s even more important for the team to focus on Wikibase-(suite)-specific scaling challenges—where external communities and resources are lacking—rather than investing heavily in scaling general infrastructure that others already cover well.