@tomasv @ascherbaum nothing special: dockerized environment, official docker image. I’ve deployed one of the services with pg18 but used default mount path to data. So I was unplesantly surprised to find empty database after 18.2 to 18.3 image upgrade. Old container was gc’ed because both pg and app healthchecks passed. Which is technically correct: app rolled bootstrap migration and went up in blank state and pg was indeed available. But data is gone. It was expected that there could be issues with 18, so it was first deployment with not that important data. Another another lesson that observability as useful as your risk assessment. Also lesson in trust in vendors: no matter how consistent in their changes they were in past, they absolutelly will do stupid things. That on me. I could’ve paid more attention that’s also on me. But doing change of this magnitude so careless and without any proper discussion of what can go wrong for downstream users is on the people who made this damn pull request merged. Worst part this change is purely about aesthetics and addresses exactly zero issues: pg sill gives no shit about operational complexity of major version upgrades. While I respect people around pg, database itself is an example of software that is plan hostile to users. It’s never joy, it always different from of pain.