MIME-Version: 1.0
References: <CABj6V64i-YMNRMZ2gh4U=dPrLiL4=hvUQE-0n+g1EcJP0NVROg@mail.gmail.com>
In-Reply-To: <CABj6V64i-YMNRMZ2gh4U=dPrLiL4=hvUQE-0n+g1EcJP0NVROg@mail.gmail.com>
From: Adam Brusselback <adambrusselback@gmail.com>
Date: Thu, 20 Mar 2025 12:12:09 -0400
Message-ID: <CAMjNa7czQyZspsrNwQsapAqUUDq7=xXJyGwMhukc0XSMmsRPHA@mail.gmail.com>
Subject: Re: Postgres incremental database updates thru CI/CD
To: Puspendu Panda <puspendupanda@gmail.com>
Cc: pgsql-general@lists.postgresql.org
Content-Type: multipart/alternative; boundary="0000000000004c36080630c867ae"
Archived-At: <https://www.postgresql.org/message-id/CAMjNa7czQyZspsrNwQsapAqUUDq7%3DxXJyGwMhukc0XSMmsRPHA%40mail.gmail.com>
Precedence: bulk

--0000000000004c36080630c867ae
Content-Type: text/plain; charset="UTF-8"

There are no built in tools for this in Postgres.

There are other tools like the one mentioned that you can use instead. I've
used Liquibase for migrations for multiple companies now and it works well
enough.
If you have to support rollbacks for your deployments, that is a pretty
manual process for any serious migration (especially migrations requiring
data movement) in my experience. Also set up something that requires all
PRs to be able to apply update, rollback, and apply update again and still
be in the same state as if you only applied the update once.

For my current project, I have my liquibase integrated with my Spring Boot
backend, and CI/CD just deploys that artifact and on startup of the backend
the migrations are run. At my last company the liquibase portion was
standalone because we had a single database that had multiple products
interacting with it and we needed to be able to handle migrations
separately than any one specific app, so that was deployed directly through
CI/CD.

--0000000000004c36080630c867ae
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>There are no built in tools for this in Postgres=
.<br><br></div>There are other tools like the one mentioned that you can us=
e instead. I&#39;ve used Liquibase for migrations for multiple companies no=
w and it works well enough.</div><div>If you have to support rollbacks for =
your deployments, that is a pretty manual process for any serious migration=
 (especially migrations requiring data movement) in my experience. Also set=
 up something that requires all PRs to be able to apply update, rollback, a=
nd apply update again and still be in the same state as if you only applied=
 the update once.</div><div><br></div><div>For my current project, I have m=
y liquibase integrated with my Spring Boot backend, and CI/CD just deploys =
that artifact and on startup of the backend the migrations are run. At my l=
ast company the liquibase portion was standalone because we had a single da=
tabase that had multiple products interacting with it and we needed to be a=
ble to handle migrations separately than any one specific app, so that was =
deployed directly through CI/CD.</div></div>

--0000000000004c36080630c867ae--