# Prove your PostgreSQL restore before a Kubernetes migration | Percona Community

**URL:** <https://forums.percona.com/t/prove-your-postgresql-restore-before-a-kubernetes-migration-percona-community/41359>\
**Category:** Community website\
**Created:** [October 20, 2026, 5:11pm UTC](https://forums.percona.com/t/prove-your-postgresql-restore-before-a-kubernetes-migration-percona-community/41359 "2026-10-20T17:11:08Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![daniil.bazhenov](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/daniil.bazhenov/32/62_2.png) [@daniil.bazhenov](https://forums.percona.com/u/daniil.bazhenov)\
**Post date:** [October 20, 2026, 5:11pm UTC](https://forums.percona.com/t/prove-your-postgresql-restore-before-a-kubernetes-migration-percona-community/41359/1 "2026-10-20T17:11:08Z")

</div>

A migration plan can name every component and still leave the useful question unanswered: if the move fails, can the application work again? A dump file is not that answer. A restore into a new database, followed by the checks the application actually needs, is.

* * *
This is a companion discussion topic for the original entry at [https://percona.community/blog/2026/10/20/prove-postgresql-restore-before-kubernetes-migration/](https://percona.community/blog/2026/10/20/prove-postgresql-restore-before-kubernetes-migration/)

---

<div class="post-metadata">

**Author:** ![Screen\_White](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/screen_white/32/24383_2.png) [@Screen\_White](https://forums.percona.com/u/Screen_White)\
**Post date:** [October 22, 2026, 5:01pm UTC](https://forums.percona.com/t/prove-your-postgresql-restore-before-a-kubernetes-migration-percona-community/41359/2 "2026-10-22T17:01:19Z")

</div>

The missing-role example is a good reminder that a successful dump isn’t the same as a usable recovery. I’m also curious how you’d handle schema changes during the migration. A database might restore perfectly, but if the application has already moved to a newer schema version, the restore could still leave it unable to run. Would you include an application-version compatibility check in the recovery test?

---

<div class="post-metadata">

**Author:** ![Agustin\_G](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/agustin_g/32/14111_2.png) [@Agustin\_G](https://forums.percona.com/u/Agustin_G)\
**Post date:** [November 9, 2026, 8:34pm UTC](https://forums.percona.com/t/prove-your-postgresql-restore-before-a-kubernetes-migration-percona-community/41359/3 "2026-11-09T20:34:09Z")

</div>

Hi @Screen_White,

I am of the opinion that there should be a code freeze during migration procedures, so even if you would allow application-side writes, they shouldn’t write DDLs. Schema changes should not happen during the migration. Try to reduce complexity as much as possible.

I am not the blog author, so my opinions may not reflect that of the author 🙂