Viewing the IDs, we need to swap the volume d9c855a8-f918-4d73-a15a-90f2b84b09f6 for the a75b751e-adbf-47bc-bc54-c6a0b9e70998. The volume with the ID d437b901-f365-462d-bb1c-ff1b256c192d actually doesn't exist?

This also is preventing backups from being restored

I tried to create a new postgres service, then set the volume it to and then change the connection string, but it stills fails to do the swap in new postgres services

Did you unmount volumes associated with both services first?

I could not find a button to do it

Nevermind. You need to delete the service to unmount the volume, as the service requires a volume.

I think I fixed btw

Creating a new postgres service and drag and dropping the volume to it seems to work

But using the button doesn't

nvm, did't work

(You might get password errors)

Which part didn't work?

you were right btw

Try this:

1. Disable all public networking on the database if you have any, as the following steps will disable user authentication
2. SSH into your database service (right click your service and select Copy SSH Command)
3. Run this command: sed -i 's/host all all all scram-sha-256/host all all ::\/0 trust/' /var/lib/postgresql/data/pgdata/pg_hba.conf (This will bypass user authentication)
4. Redeploy your database
5. SSH again, and run the command psql
6. Run ALTER USER postgres with password ''; where `` is the value of the variable PGPASSWORD in your Railway dashboard
7. Type exit
8. Run sed -i 's/host all all ::\/0 trust/host all all all scram-sha-256/' /var/lib/postgresql/data/pgdata/pg_hba.conf (This will re-enable user authentication)
9. Redeploy your database

That work and now the new service actually works

Now it should be just changing the env vars

Well, everything is now working. Thank you very much and God bless :3

I will not delete the original database and volume if some railway admin wants to check them later, may find the root of the issue

np