Volume backups capture the entire contents of the volume, not just the logical database size. Your 80MB is likely the logical data size, but PostgreSQL's on-disk footprint includes WAL segments, indexes, TOAST tables, and other internal structures that are significantly larger. The 1.33GB backup reflects the actual disk usage of the full PostgreSQL data directory on the volume, which you can confirm by checking the volume's used size in the service settings.

I have checked whole volume size and it's only 260mb

Hello

the dashboard backup captures the whole volume not just your database. try pg_dump instead it will back up only your actual data and will be much closer to your 80mb:

pg_dump $DATABASE_URL > backup.sql

Hope this help you :)

It's not the backup I'm concerned about so as much as using up storage with backups that are bloated for some reason. I have other projects with much larger databases which backup without this bloat. I don't know why this particular project's postgres volume backup is so large. I could drop the volume and recreate to see if that fixes but want to first check if others have had similar issues. 1.3GB for a 80mb db and 260mb total volume seems wrong to me.

I did restore a backup to the volume (multiple times) and wonder whether that somehow created a false set of data that is being backed up? But then why is the volume still smallish?

the 260mb in railway's volume metrics might not reflect the actual on-disk postgres footprint , postgres keeps WAL files, transaction logs and other internal data beyond your actual tables. try running this inside your container to see what's really on disk:

du -sh /var/lib/postgresql/data/pgdata/

that real number might explain the gap

Thanks, but that says 281 MB so still doesn't explain where the 1.33GB is coming from.