In practice, this is rarely a problem unless you're a cloud vendor with a DBaaS product; the most common concern there tends to be bugs that cause server crashes. But even that is fairly rare, and those platforms (AWS, GCP, Azure, Alibaba, etc) generally maintain custom patch sets anyway.

As far as I can recall, the vast majority of modern MySQL CVEs have been low severity and/or require the attacker to already be in your private network.

For sake of comparison -- does Postgres backport every security patch to every major.minor tree? And aren't HA Postgres upgrades generally more difficult than MySQL ones since logical replication is less widespread in the PG landscape?

> For sake of comparison -- does Postgres backport every security patch to every major.minor tree?

Unless the security fix in question is not applicable to some branch, yes.

https://www.postgresql.org/support/security/ https://www.postgresql.org/support/versioning/

> Is there another level of patches below point releases for backported security patches

No, because its unecessary (in my experience)

> or are your options to upgrade to something that adds new features and may be backwards incompatible

It won't be backwards incompatible, otherwise they would leave the change for a new minor release.

Why would you not want a new feature (e.g. the new "clone plugin") if it gives you value now without any migration required (because of incompatibilities that may arise if all new features are left for minor versions which are reserved for incompatibilities)?

> No, because its unecessary (in my experience)

Assuming that is true, this sounds like a normalcy bias to me (https://en.wikipedia.org/wiki/Normalcy_bias).

> Why would you not want a new feature (e.g. the new "clone plugin")

Because features can introduce bugs or performance regressions. Sure you can say that's rare, but I still might not want to take that risk with some of the most critical infrastructure in my app.