You deleted a Railway volume, or a redeploy lost your Postgres data.

What happened

When a volume is deleted, Railway queues it for deletion and permanently deletes it within 48 hours. During that window the volume can still be restored; after it, deletion is permanent and the volume cannot be brought back.

Railway's own guidance on backups is direct about the limits: volume backups are for recovering from bad deploys or data mistakes, and wiping a volume deletes all of its backups. Backups protect against data mistakes, not against deleting the volume itself. In Railway's words, only off-site logical dumps survive that.

What to do right now

• Under 48 hours since the delete: contact Railway support immediately and ask for the volume to be restored, giving the project, environment and service names. Do not redeploy the database service in the meantime.
• The volume still exists but the data looks missing: check that the Postgres service actually has the volume mounted at the data directory. A database image deployed without its volume starts empty and looks like data loss; attaching the original volume and redeploying brings the tables back.
• More than 48 hours: the volume and its backups are gone. What remains is whatever you dumped elsewhere: a local pg_dump, a migration export, a development copy.

So it does not happen again

Keep the volume backups if your plan has them, and add the layer Railway itself recommends: a logical dump stored outside the project. Dumpling connects to the database's public TCP proxy address on a schedule, runs pg_dump or mysqldump, verifies the output, and streams it into a bucket you own. It works the same for Railway MySQL.

# restoring into a new Railway Postgres service
createdb -h <proxy host> -p <proxy port> -U postgres restored_db
pg_restore --no-owner --no-acl -h <proxy host> -p <proxy port> -U postgres -d restored_db railway.dump