We're trying out a few things right now. 1) Use a migration tool (flyway, dbmigate, etc.) 2) We try and keep scripts idempotent to minimize on migration scrip

We're trying out a few things right now. 1) Use a migration tool (flyway, dbmigate, etc.) 2) We try and keep scripts idempotent to minimize on migration script explosion. Also helps to keep changes to similar assets located within the same file: easier to see the progress of a given asset as it changes throughout the lifetime of your app. 3) We have a dedicated repository for each database/schema. A CI/CD process triggers on a push to a given branch (dev, qa, stage, prod, etc.). The CI/CD process runs the migration script (in this case AWS Code Pipeline). Having the schema in its own repository decouples our databases from the service(s) that use them. 4) We try our best to separate schema changes from feature changes: a) push database changes first maintaining backwards compatibility, b) then push feature changes, c) then remove backwards compatibility. So, try to minimize on rollback script. Local development is same as yours: docker-compose.