Is there any interest in moving away from gorm schema auto migrations? I feel like the auto migrations give you very little control over how the migration is performed and right now it happens in-band during application startup which could result in a crash loop if migrations take too long.

thanks @clean-glass-36808 I think the auto migrations are intended to ease upgrades but it's true that sometimes is a source of delays. What would be the alternative? Maybe providing a way for users to call the migrator API on demand or? cc @bulky-gold-93144 / @high-park-82026

Alternative would be to specify a migrations folder with migrations (baseline migration would have to match what already exists carefully) and then migrating using something like: https://github.com/golang-migrate/migrate Then you'd build a separate binary to run the migrations and run that as a k8s job so its out of band, prior to rolling the pods for the new deployments

@average-finland-92144 let's put this topic for discussion at upcoming Contributors Meeting?

gorm migrations do support that though, right? we do not have to run automigrate() everytime

Yeah there are two items. 1. Perform migrations out of band (separate job / init container) 2. Move away from gorm automigrate so there is more control over how changes are done under the hood. (ie. build new indexes concurrently instead of locking the table, transforming data and moving it to another column (I realize this isn't a use case but just an example))

1. I think this is what we do... as an init container 2. makes sense..

Yeah just double checked, init-container with no liveness/readiness seems fine. With how tightly integrated the migrations are to the structs you probably do just want to block new deployments on the migrations running