Request a Demo
Home   >   mailing lists

Re: Approach for DB migration - Mailing list pgsql-general

From Ron Johnson
Subject Re: Approach for DB migration
Date
Msg-id CANzqJaDkJJrzYfkBtKzXnSUxgccMkKOJB-sOPJWVd4f8foet7w@mail.gmail.com
Whole thread Raw
In response to Re: Approach for DB migration  (Siraj G <tosiraj.g@gmail.com>)
List pgsql-general
Tree view
On Thu, Aug 7, 2025 at 12:21 AM Siraj G <tosiraj.g@gmail.com> wrote:
Yes Ron, database migration service. But it works better if we have to migrate all the DBs in one shot

Is that really a problem?

But if there's a problem with DMS, then logical replication should do the trick.
 
since it converts the target DB into a read replica during the migration.

Regards
Siraj

On Thu, Aug 7, 2025 at 9:33 AM Ron Johnson <ronljohnsonjr@gmail.com> wrote:
On Wed, Aug 6, 2025 at 9:30 PM Siraj G <tosiraj.g@gmail.com> wrote:
Hello Experts!

I have this environment with 100+ DBs and would like to migrate to GCP's cloud SQL for Postgres. 

Primary: 48 CPUs, 48GB memory
Secondary/Read Replica: 80 CPUs, 128GB memory
PG version: 12.22 (we have already started the upgrade process)
OS: Ubuntu

I would like to migrate 2 DBs first and a few more later. I was thinking of logical replication, but wanted to take recommendations if there are better approaches available. We cannot afford breaking the read replica due to our read intensive app connects to this node.

GCP haa a migration service.  Have you investigated it?

--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!


--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!

pgsql-general by date:

Previous
From: Siraj G
Date:
Subject: Re: Approach for DB migration
Next
From: Dominique Devienne
Date:
Subject: Re: CALL and named parameters