public inbox for [email protected]  
help / color / mirror / Atom feed
From: Adrian Klaver <[email protected]>
To: veem v <[email protected]>
To: Peter J. Holzer <[email protected]>
Cc: pgsql-general <[email protected]>
Subject: Re: How to have a smooth migration
Date: Thu, 15 May 2025 10:02:59 -0700
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAB+=1TV7J-ORtH8EtbuqbheLdSRsw4YBh+Cw38X5cfRbQsTUnQ@mail.gmail.com>
References: <CAB+=1TUU2rgjNzz6T05RPwCi1xjKr=9cwhX=Jdyo4zPiakH-zQ@mail.gmail.com>
	<[email protected]>
	<CAB+=1TV7J-ORtH8EtbuqbheLdSRsw4YBh+Cw38X5cfRbQsTUnQ@mail.gmail.com>

On 5/15/25 09:29, veem v wrote:
> 
> 
>     This is what Sqitch(https://sqitch.org/ <https://sqitch.org/;) was
>     designed for.
> 
>     The biggest issue is that the data will be incrementing while you do
>     the
>     structural changes. How you handle that is going to depend on the
>     question raised by Peter J. Holzer:
>     Is thisĀ  being done in place on one Postgres instance or between
>     separate Postgres instances?
> 
> 
> 
> Thank you. Yes, these tables are going to be part of the same database. 
> Never use sqitch though , but was wondering if we can do it with the 
> stored simple proc as the number of table is very small <20 and also the 
> max size of table in <50MB. Also , missed to add , this is a cloud RDS 
> database and so not sure we can have this tool there.
> 

1) For Postgres Sqitch uses psql as the client for making the changes. 
Therefore you only need access to psql. Also the deployments can be run 
from a machine that is not in the Cloud, as long as you have remote 
access to the Postgres instance.

2) With Sqitch you have:

a) Deploy/verify/revert actions. The verify helps keep out erroneous 
deployments and revert can take you back to a known prior state. Caveat 
the actions are based on SQL/psql scripts you create, they are only 
useful to the extent you make them so.

b) Targets, which are different instances of Postgres you can 
deploy/verify/revert against independently of each other. Useful to try 
your changes against a dev instance before deploying to production.

3) I would strongly suggest:

a) Breaking the changes down into smaller portions, probably best around 
tables having relationships.

b) Create a dev/test Postgres instance to trial changes and test them.

Sqitch is not the only database changes management system out there, it 
is just the one I found to be useful for my needs.




-- 
Adrian Klaver
[email protected]







view thread (5+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: How to have a smooth migration
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox