A database migration (moving a service between hosts) does not delete or replace the data on a volume, so the data loss came from an action taken against the database itself, such as a destructive migration, a schema reset on startup, or a write from application code or tooling. We're not able to recover data after actions like these. To protect against this going forward, upgrading to the Pro plan unlocks native volume backups and point-in-time recovery, which you can enable from the service's Backups tab.

Okay well neither of those things happened as I haven't made a code change, schema change, etc within the last 24 hours. I was able to see my users just fine a day prior. I also have a screenshot detailing that railway was "upgrading" my service and they had a backup. But the backup was either not attached or never fully recovered.

To correct our earlier message, a pre-patch snapshot of your volume was taken automatically before the security update and is visible in your Postgres service's Backups tab, retained for 30 days. That snapshot is a point-in-time copy of the volume as it stood immediately before the patch, not a restore that was performed for you. The security patch itself restarts the container against the same volume and does not delete or replace data. Restoring the snapshot requires upgrading to Pro, which unlocks self-serve restore from the Backups tab.