<story><title>Pgroll: zero-downtime, reversible schema migrations for Postgres</title><url>https://xata.io/blog/pgroll-schema-migrations-postgres</url></story><parent_chain><item><author>candiddevmike</author><text>Help me understand the value of 
undoable migrations.  I&amp;#x27;ve always operated under &amp;quot;the only path is forward&amp;quot; and you release a new version that fixes the issue or create a new migration that does some kind of partial rollback if necessary.  Once a migration is live, naively rolling things back seems like you&amp;#x27;re asking for problems.&lt;p&gt;I also only perform migrations as part of app init, not separately.</text></item></parent_chain><comment><author>exekias</author><text>I believe this is one of the reasons why migrations become scary in many cases. If something goes wrong &amp;quot;the only path is forward&amp;quot;. Also, rolling out new versions of the application means either breaking the previous versions (with some instances still running) or doing the migration in several steps.&lt;p&gt;We believe there is a better way, they way pgroll works, you can start a migration, and keep the old &amp;amp; new schemas working for as long as you need to rollout your app. If the new version of the app&amp;#x2F;schema doesn&amp;#x27;t behave as you were expecting, you only need to rollback the commit and undo the migration. pgroll guarantees that the previous version is still working during the whole process.&lt;p&gt;There is a graph in the readme depicting this concept:&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;xataio&amp;#x2F;pgroll&amp;#x2F;blob&amp;#x2F;main&amp;#x2F;docs&amp;#x2F;img&amp;#x2F;migration-flow%402x.png&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;xataio&amp;#x2F;pgroll&amp;#x2F;blob&amp;#x2F;main&amp;#x2F;docs&amp;#x2F;img&amp;#x2F;migratio...&lt;/a&gt;</text></comment>
<story><title>Pgroll: zero-downtime, reversible schema migrations for Postgres</title><url>https://xata.io/blog/pgroll-schema-migrations-postgres</url></story><parent_chain><item><author>candiddevmike</author><text>Help me understand the value of 
undoable migrations.  I&amp;#x27;ve always operated under &amp;quot;the only path is forward&amp;quot; and you release a new version that fixes the issue or create a new migration that does some kind of partial rollback if necessary.  Once a migration is live, naively rolling things back seems like you&amp;#x27;re asking for problems.&lt;p&gt;I also only perform migrations as part of app init, not separately.</text></item></parent_chain><comment><author>contravariant</author><text>I don&amp;#x27;t think &amp;#x27;undoable&amp;#x27; is the clearest description, the crux is this:&lt;p&gt;&amp;gt; Keep two versions of the schema (previous and next) accessible at the same time during the whole migration process&lt;p&gt;This has some obvious advantages. Like you said you can&amp;#x27;t easily roll back once a migration is fully live, but it helps &lt;i&gt;a lot&lt;/i&gt; if you can cancel a migration once it turns out it doesn&amp;#x27;t work.</text></comment>