Unfortunately, we do not offer data recovery for database services, as they are unmanaged and we do not maintain internal snapshots, WAL archives, or point-in-time recovery unless you explicitly enable it. Both your Postgres services show successful deployments with the volume still attached, so the data on the volume was likely overwritten when Postgres reinitialized into what it saw as an empty data directory. Going forward, we strongly recommend enabling volume backups on your Postgres service (available on Hobby) and considering Point-in-Time Recovery so you can self-restore in the future.

Hi, thank you for the quick response.

I understand that data recovery isn't part of your standard offering. However, since the volume is still attached and was never deleted, is there truly no way to inspect its contents at a lower level? Even a read-only mount or a raw snapshot of the volume would help — I could attempt recovery myself if given access to the underlying data.

If that's definitively not possible, I'll accept the loss and move forward. Just want to make sure I've exhausted every option before rebuilding from scratch.

Thanks again for your time.

There is no way to inspect volume contents outside of the mounted service, and we don't offer read-only mounts, raw snapshots, or any form of volume-level data recovery. The only access path to a volume is through the service it's attached to, so if Postgres reinitialized over the existing data directory, that data is no longer recoverable. Going forward, you can enable volume backups from the Backups tab on your Postgres service to protect against this in the future.