1. pg_dump the old database 2. pg_restore to the new database 3. setup replication between the two databases 4. redeploy your service. Usually, deployments a

1. pg_dump the old database 2. pg_restore to the new database 3. setup replication between the two databases 4. redeploy your service. Usually, deployments are hot swapped so you continue ingesting into your old database, replicating to the new one, until the deployment is complete. If you use sequential identifiers, I don't think it's possible to do this without dropping a few records due to duplication, unfortunately. If duplication is something you cannot handle, you should deploy two instances of your application in parallel, take the original instance down, wait for replication to complete, and then switch to the new one. This will probably be <10s downtime. I did something similar recently, but I switched both application hosts and database providers. End user DNS replication would theoretically take some time, but for me consumption dropped to zero within a minute or so https://shottr.cc/s/1ngg/SCR-20240407-hoa.png https://shottr.cc/s/1ngg/SCR-20240407-hoa.png