e it can automatically use free memory and won't require this level of tuning.

* I thought it was fair to disable query cache though :)

~~~
bhauer
Actually, mostly in an informal matter, we have in fact received many test
implementations from maintainers of frameworks directly. If you go through the
pull requests, you may recognize some folks. I don't want to name drop though.

I had in passing asked a few if they would be willing to apply an "official"
indicator next to their rows. But the response had been uniformly "not
interested." Maybe later I'll ask again. :)

Thanks for the notes on the MySQL configuration. There are a lot of gray areas
in setting up the configuration, but we do seek recommendations such as these.
Aside from concessions we've made to the matter of running a benchmark, the
overriding goal for configuration is that "production-class" configuration is
preferred.

I'm not an expert at InnoDB tuning, so you might tell me that
"innodb_log_flush_at_trx_commit = 1" is not typical for production
environments, in which case I'd want to make a change. But if it _is_ typical
for production, I'd like to keep it as-is.

If the point is that other databases do not have something comparable, that
speaks to the point of the linked blog entry. These things are not directly
comparable, feature-by-feature. We would like Postgres and MongoDB to be
deployed in a typical "production-class" configuration, but that may or may
not be feature-identical with MySQL.

~~~
rsynnott
In many production environments where a few lost writes in the event of OS
crash aren't entirely the end of the world, innodb_log_flush_at_trx_commit is
set to 2. In some it will even be set to 0 (in that instance, data is lost in
the event of MySQL crash). If you care deeply about every write definitely
hitting disk in a recoverable manner, you set it to 1, but at that point you
may have to do other stuff (is the OS lying to you? Is your RAID controller
lying to you? Is your disk lying to you?)

> If the point is that other databases do n