with db migrations the database structure changes. it's not possible to do db schema migrations without downtime unless the application has been built with that in mind and the application is able to run with a partially upgraded schema.
you asked why it happens so often, I provided a possible explanation.
just yesterday we had a similar case where a usb ethernet adapter wouldn't work on a locked device due to a similar issue, even if that one may be more logical.
especially when you have to follow an outdated password policy where people have to change their passwords at regular intervals you'll have such cases more frequently than when they only need to set it once until a suspected compromise.
I'm indeed talking about spinning up full vps. with untrusted workloads I'd rather have the best isolation reasonably possible. effectively, this is similar to how Github hosted runners work. my gitlab is currently primarily working by spinning up Hetzner cloud vps on demand, but I've also used this with proxmox before.
if I have very sensitive secrets accessible to my ci pipeline I want to minimize the risk of leakage through compromise of CI environments to a minimum.
I've been considering moving away from gitlab for a long time, but so far, as far as I know, it's still the only service that supports ephemeral self hosted runners. with gitlab it can utilize docker-machine to spin up vps on demand and ensure only a single job runs on each vps before it gets destroyed again.
you can't delete comments from modlog, except for admins purging then, and then there is a purge modlog entry. purging also only applies to the local instance. the reason that you don't see it in modlog is that banning a user while selecting to also remove their content is only going to put the ban in modlog currently, so the comment removal was never there in the first place.
someone should tell them, can't be much longer until it hits